Hi!
This is a feature request to unify the behaviour between Lock and auth0.js.
To my understanding, when setting {auth: redirect: false }} for Lock, it auto-closes the popup after (a successful?) authentication. I'm wondering if this could be an opt-in behaviour for auth0.js as well?
Atm the popup.authorize() requires a redirectUri whose single purpose often is to initiate auth0 and call the popup.callback() method. For SPAs or JAM stacks, that's quite cumbersome since you'd ideally have a separate HTML page for the callback uri (since you wouldn't want to spin up a whole app for that single call), and you'd then have to figure a way to inject the client ID into the static file if it's dynamic across environments/tenants, etc.
I'm sure there's a valid reasoning behind the separate redirectUri and I'm not suggesting its removal. Just wondering if there's a way to provide a shortcut for the users?
Best,
andreas
@andreasvirkus can you try passing the owp: true option to the authorize call? Let's see if that works.
Thanks! owp: true works wonders and closes the popup instantly. Is there a reason I can't find documentation on it? Found another issue under which it's mentioned https://github.com/auth0/auth0.js/issues/596#issuecomment-376334559
and there you state that ideally the callback page is preferred. What's the reasoning there and are there any downsides to using owp: true?
I'd also like to update the docs about owp but would need a bit more background as to what it's meant for and why/when people should refrain from using it.
Edit: found this from the repo's source:
determines if Auth0 should render the relay page or not and the caller is responsible of handling the response.
https://github.com/auth0/auth0.js/blob/60f26b7fa811603633d11653843d51ce0c5b95b2/src/web-auth/popup.js#L140
Which is in the generated docs: https://auth0.github.io/auth0.js/global.html
Can I also add it to the library docs or is there a reason those docs show a subset of config params
(https://auth0.com/docs/libraries/auth0js/v9)?
Sorry about the wait. I'm checking with our team if we plan to support this in the long run. I'll let you know when they answer. Thanks!
Hey, Is there any update on this issue, we got to use owp:true to close the popup and which triggers the call back.
Code Snippet:
webAuth.popup.authorize({
redirectUri: 'http://localhost:3777/callback',
owp: true,
}, (err, res) => {
// call back
}
));
If its a right way of usage please update the docs as it is misleading when trying to implementing the popup method, since popup does not close and leaves access token on the URL.
Also, is the redirectUri necessary alongside owp: true?
Hi friends 馃憢 I forgot to give you an update.
Because owp is not part of any standard, we're looking at ways to make popup work without the need for a callback page (redirectUri). We already have a solution in place, but security is reviewing this to make sure we're not missing out on anything. This will probably be released on Q1 2019. When we do release this, rest assured docs will be updated to reflect this new behavior.
Thanks 馃憤
Most helpful comment
Hi friends 馃憢 I forgot to give you an update.
Because
owpis not part of any standard, we're looking at ways to make popup work without the need for a callback page (redirectUri). We already have a solution in place, but security is reviewing this to make sure we're not missing out on anything. This will probably be released on Q1 2019. When we do release this, rest assured docs will be updated to reflect this new behavior.