Open KlausVii opened 1 year ago
Hi @KlausVii - thanks for raising this
This is a performance feature of Chrome (and Safari & FF) called Back/forward cache
When you click the Back button, Chrome loads the previous page seemingly in an instant, because the entire page is restored from memory - there's not much the SDK can do, but you can disable bfcache on your browser if you don't want the feature.
Ah thank you for the explanation @adamjmcgrath
Should we do something like this event listener to force a reload?
Thanks for sharing that link @KlausVii - you can certainly do that on your application if you want.
I can't think of a good reason why we wouldn't add something like that to the Spa SDK (at least behind a config option) - let me discuss it with the team.
Hi @KlausVii - I'm just doing some more investigation into this
login logout press back find yourself logged in again.
Are you able to share a link where I can reproduce this behaviour?
Also, did you try adding the event listener and did it resolve your issue?
@adamjmcgrath Sorry our application is not open to the public, so cannot really share a link.
I have not tried the event listener as of now, we parked this kind of hoping your fix would resolve it 😅
I'll let you know if/when I find time to test this.
np, thanks @KlausVii
I only ask because I'm investigating this and can't reproduce it on localhost or another domain and I'm wondering how bfcache works with redirects (cross domain or otherwise)
If you test it lmk if it works also, if you can share a HAR file (with secrets redacted) that demonstrates the issue I'd also be interested in looking at it.
Also looking to get this addressed. The event listener workaround is not working for me as the cookie still seems to exist on back tap, or at least in the time that the code checks it. I even tried an interval to check it in case it was a timing issue where the cookies were not cleared by the auth0 client logout call yet.
Alternatively we could always reload on pageshow persisted=true check but that is a burden on the user.
Thanks everyone for the patience here.
For now, we have been unable to reproduce this, but believe we have a bit of missing information.
Can someone provide some information for us to help reproduce this, in order for us to consider how to address this?
To avoid any confusion, it would help if someone could share an exact reproduction of a client application that allows to reproduce the behavior.
@zebapy I am asking the above because I noticed the information you shared with our team through different channels indicates the use of auth0.js
(e.g. it's set as the Auth0Client header on the call to /authorize
), and you mention lock. Which I am trying to understand how they fit in the story here.
Additionally, I think there may be other factors at play here that are important to get some information on:
Hi @frederikprijck ,
Im having similiar issues.
Currently using: @auth0/auth0-react": "2.2.4". Not using auth0.js. Not using lock
Currently this only occurs in Firefox and only with the built app, it does not occur when the dev server is running. After logging out, once Auth0 has redirected back to our app, if the user clicks the back button it looks like it is loading the page from cache (I assume this is the bfcache as I dont see any network requests other than icons in the network tab). I also noticed that here:
https://github.com/auth0/auth0-react/blob/main/src/auth0-provider.tsx#L202
It only dispatches the "LOGOUT" action if you specify an openURL, ie. if you let auth0 do the redirect back to the client app it doesnt dispatch the action and and doesnt set isAutheticated to false. I assume this is done as its going to load a new copy of the client after the redirect anyway where the isAuthenticated status will be setup fresh anyway. But if the user clicks the back button and the browser uses the bfcache then the page will be repopulated with the Auth0Provider still having isAuthenticated set to true. The app is then accessible for a bit, I assume until something checks the authenticated cookies which were correctly removed on logout.
In browsers where it doesn't rerender the pages on clicking back like chrome I see that on clicking back I get the logout url appearing in the network tab so Im assuming it isnt loading the page from the bfcache.
Im probably barking up the wrong tree but would it help if the client dispatched the logout action even if the user hasn't provided an openUrl in the logout options?
Alternatively is there something that is meant to prevent the browser using the bfcache when clicking back after logout?
p.s. - I have used the listener/event mentioned above to force a reload if the page is reloaded from the bfcache as a workaround.
Thanks for your time
Michael
Checklist
Description
After calling
logout
the user is redirect back to our login page, but if they go back with their browser they can get back into the application and perform authenticated actions. Calling refresh at any time throws them out of the application, and the auth0 logs show a successful logout.To add more mystery to this, it does not happen consistently. For example, if the developer tools are open in the browser, the problem goes away and going back throws the user onto the login screen.
Reproduction
It seems to be mitigated by having the developer tools open, but is pretty much consistent in normal use. Also unable to replicate it on a localhost dev build.
Additional context
This is our auth provider
auth0-react version
v2.2.1
React version
17.0.2
Which browsers have you tested in?
Chrome