Hi, I am testing out the redirect-from-rule functionality to do a bit of housekeeping for users during login. However, I’ve hit an issue that I don’t quite understand.
The rule is pretty simple for now:
function (user, context, callback) {
if (user.email === “test@user.com”) {
console.debug(“Redirecting for admin”);
context.redirect = { url: “http://localhost:8086/redirect” };
}
return callback(null, user, context);
}
The callback endpoint (“/redirect” above) doesn’t do anything yet and redirects back to /continue?state=… after it is complete. I am not yet exchanging anything between the rule and my app.
When this rule is enabled and I authenticate from a single page app (not sure about other application types), the token exchange does not include the id_token even though I have the right scopes during login (opened, profile, email, etc). Does something get lost in the exchange? Am I supposed to return the id_token back from the callback for this to work?
Are you by chance using Auth0 Developer Keys for the Social Connection you are using?
If so, it might be causing the issue with the Rules redirect. You can set up the Social Connections using your own credentials to see if this is the cause.
We are not using any social connections or developer keys. Do I have to pass anything back to the rule for this to work? I thought it was odd that the id_token attribute was missing after the exchange as if it lost track of the scopes I passed at the beginning of the login transaction.
I just tried out redirect using rules, and I see that the user is not yet logged in when they hit the /redirect URL. I receive the id_token only after completing authentication by redirecting to /continue?state...
https://[YOUR DOMAIN OR CUSTOM DOMAIN]/continue?state=THE_ORIGINAL_STATE
Just to clarify are you not receiving the id_token after the /continue?state=... takes place?
I got to the bottom of the problem. It turns out we were customizing the scopes in a separate rule, and wound up removing requested scopes which was ok as long until the rule ran again on the callback. Skipping the rule execution when context.protocol === “redirect-callback” solved the issue. I’m sure there is still a problem with this rule, but at least its working “as expected” now with the redirect rule enabled.