Closed
Description
In the auth-service
there is a storage event listener added. This might cause race conditions. For example:
- Tab A and Tab B both have the app open, not logged in yet
- Tab A logs in. Internally in auth-service from the library, a function will run that starts with setting the
access_token
in storage - Tab B starts responding to that change before tab A completes with the function
- Tab B's response is to load the user info, and upon response from the server the
sub
from the response is checked against the Identity Claims in storage, but Tab A never got to save that yet because it's thread on the CPU didn't get prio. - Tab B will now throw an error because the
sub
from the user info endpoint doesn't matchnull
from storage.
So:
- Workaround: wrap logic in
setTimeout
to make it very likely that Tab A handles everything before Tab B - Solution: don't respond to
storage
events, but make tabs propagateOAuthEvent
s properly to sibling tabs