Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logged-in UI state inconsistencies between app & web component #1050

Open
floehopper opened this issue Jun 20, 2024 · 1 comment
Open

Logged-in UI state inconsistencies between app & web component #1050

floehopper opened this issue Jun 20, 2024 · 1 comment

Comments

@floehopper
Copy link
Contributor

If the user is logged in, but their access token in local storage has expired, it's possible for the logged-in UI state in the "outer" editor-standalone app to be different from that in the web component.

Steps to reproduce

  1. Clear all browser state / use private browser session
  2. Login
  3. Visit a "public" project, e.g. https://editor.raspberrypi.org/en/projects/blank-python-starter
  4. See that both the global nav UI and the web component "Save" button is in the logged-in state
  5. Expire/invalidate the access token in local storage by running a script in the browser console (see below)
  6. Refresh the project page
  7. See that the global nav UI is in the logged-out state, but the web component "Save" button is in the logged-in state (i.e. the button text does not say "Log in to save")
const authKey = localStorage.getItem("authKey");
const user = JSON.parse(localStorage.getItem(authKey));
const oneDayAgo = new Date().getTime() - 24 * 60 * 60 * 1000;
user.access_token = "invalid";
user.expires_at = oneDayAgo / 1000;
console.log(`expires at: ${new Date(oneDayAgo)}`);
localStorage.setItem(authKey, JSON.stringify(user));

Before access token expires

Image

After access token expires

Image

Notes

  • Step 5 simulates a user closing the browser and coming back to the site over an hour later when their token will have expired.
  • This problem is currently more significant, because the OIDC silent renewal isn't currently working.
  • However, we think it highlights some shortcomings in the web component code which could still be an issue once the silent renewal is fixed.
  • There is some useful context/info in this issue.
  • We've now realised that these earlier changes were a bit of a bodge.
  • The bodge works around the problem that if an API request is made (e.g. triggered by useProject) before the user has been set in the redux state (by localStorageUserMiddleware), it's possible that the initial API request fails because it has an out-of-date access token and the API request is not retried even once the user has been set in the redux state.
@sra405
Copy link
Contributor

sra405 commented Jun 21, 2024

I think this is caused by silent renewal not working in editor-standalone (fix here). I believe the web-component is doing its own silent renewal too (see the boolean in userManager) - potentially the cause of some of the CORP issues and it won't update because the object in localstorage isn't updating (due to the silent renewal issue) so the user object in the web-component isn't updating either
Key bits:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants