Field [sessionId] for user [xxxxx] is not stored error

Search terms you've used

Field [sessionId] for user is not stored

Impacted package

Which packages do you think might be impacted by the bug ?

• solid-client-authn-browser
• solid-client-authn-core

Bug description

In some conditions which are still unclear, we get issue with storing/retrieving the sessionId of the current user from the default storage (which is the localStorage in that case).

Probably linked to that one we described before: https://github.com/inrupt/solid-client-authn-js/issues/423#issuecomment-810895015

To Reproduce

1. User logs to the app, like https://ep-contributions.startinblox.com (strongly tied to our own iDP for now)
2. User does not log out but quit the app
3. User comes back a few days later
4. When logging-in back, he is sometimes stuck on the ?code=[code]&state=[state] step of the authentication workflow

Expected result

User should come back whenever he wishes to the app, either having triggered the logout when he closed before or not, and the new login attempt should work as expected.

Actual result

In some conditions which are still unclear, the new login attempt is triggered but stays stuck at the ?code=[code]&state=[state] step with the message in the console being:

oidc.js:422 Uncaught (in promise) Error: Field [sessionId] for user [0e5bb174de6f43318335a18d481e4d36] is not stored
    at StorageUtilityBrowser.getForUser (oidc.js:3994)
    at async AuthCodeRedirectHandler.handle (oidc.js:14154)
    at async ClientAuthentication.handleIncomingRedirect (oidc.js:13683)
    at async Session.handleIncomingRedirect (oidc.js:14566)

The only way to make it work from here is to trigger an additional reload of our app, which triggers the login again, skipping the login/password screen as the user is already authenticated, so just sending him to the authorization screen, then back to the app with a new code which actually passes.

We are using the defaultStorage for those information which is the localStorage as far as I get it.

Environment

balessan@balessan-laptop:~/workspace/sib-projects/sib-energiepartagee$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers
npx : 1 installé(s) en 1.199s

  System:
    OS: Linux 5.4 Ubuntu 18.04.6 LTS (Bionic Beaver)
    CPU: (8) x64 Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
    Memory: 1.16 GB / 15.33 GB
    Container: Yes
    Shell: 4.4.20 - /bin/bash
  Binaries:
    Node: 10.16.3 - ~/.nvm/versions/node/v10.16.3/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v10.16.3/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v10.16.3/bin/npm
  Browsers:
    Brave Browser: 95.1.31.87
    Chrome: 95.0.4638.54
    Firefox: 94.0
  npmPackages:
    browser-sync: ^2.26.13 => 2.26.13 
    chokidar: ^3.3.0 => 3.5.1 
    copyfiles: ^2.3.0 => 2.4.1 
    express: ^4.17.1 => 4.17.1 
    js-yaml: ^3.13.1 => 3.14.1 
    node-sass: ^4.14.1 => 4.14.1 
    npm-run-all: ^4.1.5 => 4.1.5 
    object-assign-deep: ^0.4.0 => 0.4.0 
    pug: ^2.0.4 => 2.0.4 
  npmGlobalPackages:
    @wordpress/scripts: 14.1.0
    moleculer-cli: 0.7.1
    npm: 6.14.5
    webpack-cli: 4.6.0
    webpack: 5.30.0
    yarn: 1.22.4

Available if needed for additional info or debugging session or context understanding.

Start by reproducing the described return-to-app flow after several days, then trace StorageUtilityBrowser.getForUser through AuthCodeRedirectHandler.handle, ClientAuthentication.handleIncomingRedirect, and Session.handleIncomingRedirect. The work is done when the sessionId is reliably available during the redirect and the login completes without requiring an additional reload.