Weird automatic log in/log out behaviour
See original GitHub issueThis might be two bugs but maybe it’s just me doing something wrong. My code for reference https://github.com/Edgeryders-Participio/realities/pull/133/files
-
If you’re in your app logged in and refresh the page (even clearing cache with ctrl-f5) you are still visibly logged in. But if you open the same link in a new tab then you look logged out. Even if you can click Log in and be immediately redirected back to the app without filling in your username/password, since you in fact actually were logged in. This might be related to me setting
autoSignIn={false}
but that’s because I don’t want the user automatically redirected to the log in page on visit (it’s a SPA, and some users shouldn’t have to log in). So I kind of want autoSignIn to be false, but I want detection of already being signed in to be more automatic. -
When I call
signOut
this module’s cache mostly seems to be cleared of the log in info. If I click Log in in the app then I’m automatically redirected back to the app since I’m technically still logged in. But I want the option of logging into another account than the one I’m currently logged into.
Any ideas how to fix either of these?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Thanks! Switching to localStorage fixed my first issue. See https://github.com/Edgeryders-Participio/realities/pull/140/files for code. However two things:
Would you accept a PR for these two changes?
And regarding my issue nr 2, that still persists and so I’m unable to properly log out of my current account and into another one. Reading the documentation a bit more closely, signOut which is what I’m using, apparently only does “Returns promise to remove from any storage the currently authenticated user.” which explains the behaviour I’m seeing, and I guess I should use signOutRedirect instead. It’s maybe a good idea to rename signOut to something else, since it can give the user the impression it does something other than what it does?
That doesn’t seem verbose to me. It looks correct.
All of those settings that you are providing are situational to your auth provider. There’s nothing left there to make generic or less verbose - those are the necessary settings for your application.
As far as the user storage mechanism, I believe the philosophy of the underlying oidc-client library is that the storage mechanism is not known by the oidc-client (or that the maintainers there feel like it’s outside the scope of their library). At least, this was the response they gave me months ago when I asked why their library doesn’t offer synchronous methods for accessing the current user, etc. They said they couldn’t be sure that the mechanism would support synchronous access. So, with that in mind, I think it’s probably best to just keep that user storage property a pass-through to their library so that oidc-react doesn’t end up cutting off available functionality to certain users. The choices are not just local storage vs session storage, basically. There may be more choices. So, a boolean switch there doesn’t make much sense to me.
I would be all for re-exporting
WebStorageStateStore
though.