-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Silent renew iframe is not loaded when there is no session #744
Comments
Hi @GabrielGil yes we changed the startup here. We wanted to simplify the logic, and removed all our timing issues. You can achieve the same with the following code:
Then it will work like you want. Hope this helps Damien |
Hi @damienbod. Thanks for your answer. That is not exactly precise, as it is not the same result and it has a number of side effects:
The silent renew approach seems to be the de facto method to effectively get new tokens when the client app has no session in the current tab, quite well described in this article by Dennis Stötzel (Security consultant), "How To Securely Implement Authentication in Single Page Applications". Please, let me know your thoughts/opinions. |
Hi @GabrielGil nice blog, read it. yes the redirect is for the whole application and not just the silent renew. But this could be solved using the auto login but... I think it would makes sense to add support for forceRefreshSession() as a possiblity to login, if already logged in like the code above but with prompt none and no redirect, so you can keep your URL without and requiring an auto login. The error will happen anyway, just in the silent renew, and if it fails, the session will be reset anyway. Would this work for you? |
Thanks again for reading the docs I provided. I really appreciate that @damienbod. Auto-login would get closer to the expected behaviour, but despite the redirect (and manually keep the originating url in storage), the problem with that approach is that it will add a perceivable redirect to every single user, even if that user has never authenticated in the STS. I agree with you that having this option included would perfectly cover this scenario. I understand that the error will still be there, as the loaded URL will also contain Lastly, as long as the first emission of |
@GabrielGil We will consider a new API
Should be ready in the next few days. We need to do the testing, and docs This will only work with silent renew using iframes, and never with refresh tokens. Creating a new session with refresh tokens requires consent or a refresh token, which is not possible in a new tab using session storage. Greetings Damien |
That is a really elegant solution in. my. opinion and it fits with the use case we're describing here @damienbod. I appreciate to have an approximate ETA as well. I agree with the limitations with refresh tokens, and it complies with the spec which require user consent to get refresh tokens, thus not. possible in the iframe. I want to thank you one more time for your dedication and good will. Awaiting that new release, |
@GabrielGil Added support for this in version 11.1.2 Thanks for reporting. Greetings Damien |
Thank you once again, @damienbod. I have updated and it works exactly as expected. Much appreciated. G. |
Sorry to come up with this again, however I think I found a small bug. Or maybe I have misunderstood what was achievable. The thing is that using Is this the expected behaviour? Is this something that could be improved? Here again, this is the behaviour that was in place in the old Thanks in advance again @damienbod. |
Hey @damienbod, not sure whether you saw this comment here or should I open a new issue. |
Hey guys, was there any progress in this investigation? Is there anything I can do to help with issue? (Details, plunkr etc?) |
Hi @GabrielGil I try to clean up old issues. Can you open a new issue if you still have problems here? Sorry if I close this incorrectly Greetings Damien |
Describe the bug
Silent renew, should (and it used to), be triggered when enabled, so the application can be authorised directly without redirects in case the user is already authenticated in the STS server.
To Reproduce
Steps to reproduce the behaviour:
Expected behaviour
From the previous steps, I believe the plugins should load the iframe to silently renew. This will cause the STS to give the app new tokens directly, as the app was previously authorised already.
This is the behaviour of the silent renew as per version
10.0.14
.Also, I'd like to clarify that this is not auto-login, given that auto-login will redirect the user to the STS login interaction, regardless of the current user state in the STS whereas silent renew will only get a fresh set of tokens in case the user is still correctly authenticated and the client app authorised in the STS server.
Screenshots
Desktop (please complete the following information):
Smartphone N/A:
Additional context
N/A
The text was updated successfully, but these errors were encountered: