Skip to content

Storage events can cause race conditions #2

Closed
@jeroenheijmans

Description

@jeroenheijmans

In the auth-service there is a storage event listener added. This might cause race conditions. For example:

  1. Tab A and Tab B both have the app open, not logged in yet
  2. Tab A logs in. Internally in auth-service from the library, a function will run that starts with setting the access_token in storage
  3. Tab B starts responding to that change before tab A completes with the function
  4. 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.
  5. Tab B will now throw an error because the sub from the user info endpoint doesn't match null 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 propagate OAuthEvents properly to sibling tabs

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions