Open pulsesolutionsindia opened 3 years ago
I'm afraid the video is too low-res to follow, but it looks like you are using renderEl()
.
In version 5.x of the widget, we no longer recommend using renderEl() for OIDC flows
( see https://github.com/okta/okta-signin-widget/blob/master/MIGRATING.md#using-renderel-and-setcookieandredirect-is-discouraged-for-oidc-flows and https://github.com/okta/okta-signin-widget#renderel ) and instead we recommend using showSignInToGetTokens()
for self-hosted cases like yours.
We're still updating documentation to reflect these changes, sorry for any confusion.
Whether using renderEl()
or showSignInToGetTokens()
, I recommend using the promise returned by the function rather than passing the success/error functions.
Hope that helps!
Ok, I updated this on a different page here but still doesn't redirect https://www.rwilogistics.com/test/
Interesting. I can't reproduce (failed logins are failing correctly), but this sounds similar to this issue: https://github.com/okta/okta-signin-widget/issues/1484, so I'll ask the same questions:
Application type in use on that page is "Web" though we have also tried an "SPA" on monday.
DevTools Shows an authorization is returned as is matched in Okta user logs
DevTools
Okta Time
hmmm, nothing there is informative as to why you aren't receiving the tokens.
You definitely want SPA type - "web" type is for when the communication with Okta is done on the backend. It may technically work in a front-end context under the right circumstances, but that shouldn't be relied upon.
But beyond that, I'd recommend talking with our support team at developers@okta.com - you can share more details in a non-public environment and have a better back-and-forth. They're in contact with us, so if this does turn out to be an SDK issue (as noted, we have one other similar report) we'll be able address it ASAP.
Its interesting that you should say that. During hour and half call with Okta support on Monday they instructed our developer @pulsesolutionsindia to open an issue here on Github.
During that same call we did create a SPA type app and set that up, it was getting a token response same as the browser is getting an authorize response here. However the page was still not redirecting. @pulsesolutionsindia can elaborate more on the changes made during that test window.
I'll inquire with our support team and see if they can pass on details about the reproduce case.
I am having the same issue when using showSignInToGetTokens. renderEl works and does the redirect. However I'm trying to upgrade to the latest recommended approaches since we're hitting another issue where OktaError isn't rendering when there are failures. It throws an Uncaught Promise error instead.
@jchabotamica showSignInToGetTokens
does not redirect. For redirect flows, you can use the method showSignInAndRedirect
. This method and renderEl
return a promise, this promise may reject and can be caught like this:
showSignInAndRedirect().catch(function(err) { })
Okay yes I am experimenting with that now. However, what I meant with showSignInTToGetTokens is that it's not even getting into the onSuccess.
widget .showSignInToGetTokens({el: '#okta-login-container'}) .then(function (tokens: any) { alert('success'); }) .catch(() => alert('hey'));
The network tab show that the API calls are successful:
@jchabotamica That's definitely unexpected behavior: the promise should resolve or reject. A couple questions:
The widget includes source map and is fairly straightforward to debug through. It would be very helpful to understand how far it is getting and where it is (silently?) erroring out.
@jchabotamica One more question. Does the issuer match the value returned from the "well-known" endpoint?
For example If I have an org:
https://sdk-test.trexcloud.com/
and I set my issuer to https://sdk-test.trexcloud.com/oauth2/default
it has a "well-known" endpoint:
https://sdk-test.trexcloud.com/oauth2/default/.well-known/openid-configuration
the result is a JSON file:
{"issuer":"https://sdk-test.trexcloud.com/oauth2/default",...
the value for "issuer" here should match the issuer that was configured for the widget (baseUrl + '/oauth2/default' or authParams.issuer)
i think it might have had to do with not setting the issuer in the authParams. It's getting into handleSuccess now. Now I'm hitting this issue when JWT issues occur: https://github.com/okta/okta-signin-widget/issues/1597. It just hangs on the login screen/okta widget. Doesn't resolve nor reject.
I'm submitting a
Background info
Describe your issue or request here (if necessary). We have used a default login widget here: https://www.rwilogistics.com/login/ but when we try to login we just see the spinner spinning, I do not see an error in the console, I see the network call showing the login worked but the success or call back functions were not called and neither does the redirect work
When we visit the okta dashboard we see the login worked but
Expected behavior
What should have happened? It should have logged in and redirect user to the redirect URL specified
What went wrong?
Please provide log or error messages if applicable.
Steps to reproduce
https://www.rwilogistics.com/login/ You can see the video showing the behavior: https://nimbusweb.me/s/share/5038810/imt4v83kovckt35uktdc
Your environment