G'day all,
I've been having trouble upgrading to a more recent version of the ember-simple-auth module.
In particular I seem to have two challenges:
1) the application no longer transitions to the desired route after authenticating. the configuration looks like this:
ENV['ember-simple-auth'] = {
crossOriginWhiteList: ['http://10.10.1.7:3000'],
routeAfterAuthentication: 'profile',
//store: 'simple-auth-session-store:local-storage',
//authorizer: 'simple-auth-authorizer:token',
};
but it never gets to "profile".
2) I can't get the authenticated session to stick after a reload. I had been trying to use the local-store which I believed would do the trick, but it's not. Has something changed in the implementation?
The documentation seems to indicate that the configuration strings are right, but the transition and session store don't seem to be working.
Has anyone had a similar problem?
Thanks,
Andrew
you could try adding "routeIfAlreadyAuthenticated" to ENV['ember-simple-auth'] - or you could transition manually in index route "afterModel" hook, if session is already authenticated
have you configured a session store? https://github.com/simplabs/ember-simple-auth#session-stores - the way it's configured changed in 1.0, now you can add the desired session store to app/session-stores/application.js - maybe this solves #1 too.
OK. As the comments call out, there were two problems here:
1) I had written a customer authorizer for the old version of simple-auth which didn't work with the new version, and
2) I had a typo in the adapter code, where DataAdapterMixin was DAtaAdapterMixin.
Removing (1) and fixing (2) fixed the problem.
Related
I'm trying to set up a JAX-RS-service in thorntail with JWT authentication. Everything works fine (I can inject Principal and user is correctly set), except that in case of a failed authentication, answer is still sent without any 401-HTTP-Header. What I've done is:
Added #LoginConfig(authMethod = "MP-JWT", realmName = "my-domain") to my Application-Class
Configured the security-domain
security:
security-domains:
my-domain:
jaspi-authentication:
login-module-stacks:
roles-token-stack:
login-modules:
jwt-jaspi-login-module:
code: org.wildfly.swarm.microprofile.jwtauth.deployment.auth.jaas.JWTLoginModule
flag: required
auth-modules:
http:
code: org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule
module: org.wildfly.extension.undertow
flag: required
login-module-stack-ref: roles-token-stack
Configured JWT-specific things (seem to work, so I'm skipping this here)
What else do I need to do in order for this to work properly? Do I need to add any annotations to my Endpoint? As I said, I want to return a 401 in case of a failed authentication.
What I've found out so far: JASPICAuthenticationMechanism.isMandatory needs to return true in order for this to work. If this is the case JWTAuthMechanism.sendChallenge is triggered after a failure of JWTAuthMechanism.authenticate and so a 401 is sent to the client. But i have no idea, in which cases isMandatory returns true.
Thanks for any help in this case!
One, the configuration of the security domain isn't 100% correct. Here's a fix for one part of the YAML:
roles-token-stack:
login-modules:
- login-module: jwt-jaspi-login-module
code: org.wildfly.swarm.microprofile.jwtauth.deployment.auth.jaas.JWTLoginModule
flag: required
Two, indeed you need to use the common Java EE annotations (#RolesAllowed, #DenyAll, #PermitAll) on the JAX-RS resources.
Solution (thanks to Ladicek, see comments below):
If you want to use MP JWT, don't start it with Swarm and don't forget to set flag useUberJar if starting it with thorntail:run.
I'm trying to manage the context of my Google Assistant agent (in DialogFlow), using the ApiAi class in the npm package actions-on-google.
The problem is this:
How can I reset the lifespan / delete a context using the npm package?
I can easily set the lifespan of a new context, and it works.
However:
How do I delete a context?
Setting the context to a different number does not seem to work. That is, if I set app.setContext('myContext',10) and then, 2 intents later, when the lifespan in 8, I call app.setContext('myContext',10) again, in the next intent, the lifespan is still 7. If I could answer (1) and delete a context, I'd just delete it and set it again.
I don't think there is a way to delete or overwrite the duration of a context. Instead, if you know that a certain context must not be active at a certain point, set a context that lasts for 1 or 2 turns and do this after each turn. This will also give you more control over the conversation, so you won't have contexts that last for 10 turns that you suddenly don't need anymore.
To delete a lifespan of context you just set it to ZERO or 0 like app.setContext('your_context',0)
Make sure you do this before calling the app.ask or app.tell
or
if not using client you could write a function that simply sets
this.contexts_[your_context] = {}
The first option is definitely working for me. I have not tried the second option. Try and see if you are not setting it in the Dialogflow. Also, you can remove context setting in webhook and put lifespan as 0 in Dialogflow. That will put a line (like deprecated method) over your context.
I know this question is old, at least old enough so that we now have a v2 API and library overhaul, so I'll answer anyway with today's solution :) .
1 - To delete a context, you can use conv.contexts.delete('context1'); as specified on the Node.js library reference docs.
2- If conv.contexts.set('context1', 1); doesn't change the context's lifespan then you can easily delete it and recreate it with these two calls.
My experience is that you cannot overwrite context data.
You can create a new context though:
agent.setContext({
name: contextName,
lifespan: newLifeSpan,
// Note: Parameters are not visible until the context is passed
// console.log() won't show them now.
parameters: {
// Previously saved using getContext()
param_name : paramValue,
}
});
Problem: I'm getting unexpected output from code that previously worked.
Code Problem:
sails.models.user.find().then(function (users){...});
is currently returning { id: 1 }
but should return an array of User objects like [{id:x, name:y},...]
Code Alterations:
sails.models.user.find().exec(function (err, users){...}); does not contain an error and returns the same as using .then() like above.
sails.models.user.findOne(1).then(function (users){...}); correctly returns a User like {id:x, name:y}.
sails.models.venue.find().then(function (venues){...}); returns an array of venues, just as substituting any other class besides User.
Note:
This code was previously working (it's a pretty simple line), and the only changes I made between it working and not working was running npm install (but it was previously working on heroku where which installed, so I don't think that was a problem) and changing the schema of User to add a few columns (I did this by deleting the User table in the DB, updating the Sails User model, and lifting the app in create mode, so the table exactly matches the model). Neither of these should cause a problem, but we all know how "should" and coding don't mix :P
How do I fix this? And why did this happen? Thanks :)
Realized other code was calling the package sails-mock-models which was doing its job. Totally forgot about that code. Problem solved.
I'd want to use a login page to access different firewalls, so I need to get information about the firewall I'm logging in.
In my controller I'd use
$this->container->get('security.context')->getToken()->getProviderKey()
but as an anonymous user I don't have access to getProviderKey method.
I could also parse
_security.xxx.target_path
to get xxx firewall but I'm looking for a more general solution if it exists at all.
Any idea?
As of symfony 3.2, you can now get the current firewall configuration using the following:
public function indexAction(Request $request)
{
$firewall = $this->container
->get('security.firewall.map')
->getFirewallConfig($request)
->getName();
}
Ref: http://symfony.com/blog/new-in-symfony-3-2-firewall-config-class-and-profiler
For Symfony 3.4 I wrote this to avoid referencing the non-public "security.firewall.map" service:
$firewallName = null;
if (($firewallContext = trim($request->attributes->get("_firewall_context", null))) && (false !== ($firewallContextNameSplit = strrpos($firewallContext, ".")))) {
$firewallName = substr($firewallContext, $firewallContextNameSplit + 1);
}
(Referencing "security.firewall.map" on 3.4 will throw an exception.)
Edit: This will not work in a custom exception controller function.
I was doing a little research on this myself recently so that I could send this information in an XACML request as part of the environment.
As far as I can tell from GitHub issues like this one:
https://github.com/symfony/symfony/issues/14435
There is currently no way to reliably get the information out of Symfony except the dirty compiler pass hack suggested on the linked issue. It does appear from the conversation on these issues, they are working on making this available, however, the status is still open, so we will have to be patient and wait for it to be provided.
#Adambean's answer is pretty elegant, but I'd write it as a one-liner:
$firewallName = array_slice(explode('.', trim($request->attributes->get('_firewall_context'))), -1)[0];
The difference is that $firewallName will always be a string (which may be empty).
Also, please note that this answer (like #Adambean's) doesn't work for a firewall with a dot in its name.
I am trying to use FIX::Application along with SessionSettings.
The Fix server I am trying to connect to does not see any incoming connection. From my side I see a Logon Message being formulated in toAdmin() callback(which I print out and add certain fields to.
The Question is
1. Do I need to call some form of sendTarget in toAdmin?(I tried that but get a Session not found error)
2. Is there anyway I can increase logging(start logging whats going on under the hood).
Thanks
Firstly the sendTOTarget need not be called in the toAdmin.
As far as logging goes, what i hear is passing th in FIX::LogFactory should be enough.