What's the most common way (or the idiomatic way) of refreshing access tokens in a Solid.js SPA?
In my mind, there's two ways to refresh an access token via a refresh token - (1) check when the access token is near expiry using a timeout and (2) when we fetch a resource, we check the access token if it's valid and refresh from there (or when we encounter a 401 on initial fetch).
for scenario 2, how do we ensure that we're refreshing the token only once if there are 3 parallel requests that intend to refresh the token independently? it's also talked about here https://discord.com/channels/722131463138705510/722131463889223772/974342456990654486
for scenario 1, is there a primitive that allows us to check the validity across different tabs to avoid having multiple timers or avoid refreshing the token at the same time? sort of like shared process or a shared state. for now, i'm using the createPersisted primitive and localstorage, and have other tabs check for TOKEN_REFRESHING before refreshing. i'm wondering if there's a better way?
6 Replies
you need to put some logic in your token getter
and fetcher
getToken
1. if the token is valid(non-expired) return it
2. if the token expired, return a promise and start the refresh logic( refreshToken).
3. in the fetcher, await the getToken before fetching
4. if a response fails due to expired token
start the refresh logic.
while refreshing getToken will return the promise
( you then initiate a retry logic, which will await the getToken until the refresh process is done)
refreshToken should guard itself to only run if not already running.
I will not go with timer based solution whatsoever
one reason is that refresh logic might run more than you actually need. ( for idle application )
2nd is that timeout might not be accurate, and still need blocking logic if you don't want requests to fail.
so better to solve one problem and not 2for scenario 1, is there a primitive that allows us to check the validity across different tabs to avoid having multiple timers or avoid refreshing the token at the same time?Sounds to me you're looking for leader election, that way only one tab would be responsible for the refresh, another taking it's place should it go away. You can use the web locks API to emulate “Leader Page Election”. Example
MDN Web Docs
Web Locks API - Web APIs | MDN
The Web Locks API allows scripts running in one tab or worker to asynchronously acquire a lock, hold it while work is performed, then release it. While held, no other script executing in the same origin can acquire the same lock, which allows a web app running in multiple tabs or workers to coordinate work and the use of resources.
GitHub
GitHub - peerreynders/web-lock-leader: Nano demo of using the Web L...
Nano demo of using the Web Locks API for leader election - peerreynders/web-lock-leader
"Leader page election" seem like an over kill
a simple lock on the resource is fine
Which is exactly how it works.
- Every tab “requests to be the leader” on a common lock.
- Only one gets it, making it the leader, making it responsible for the routine “exactly one tasks”.
- The moment the leader tab is closed the lock moves to the next tab which takes over.
- Rinse and repeat until the last tab closes.
The whole point is that while at least one tab from the same site is open, exactly one tab is doing tasks that need to be done but shouldn't be duplicated.
Of course that doesn't account for potential interference from the memory and energy saver mode.
Ok cool, I know about locks but didn't know they started using this new terminology.
The idea of using web locks for lead page selection was documented here: Leader election in browser tabs, the easy way
Green Vitriol - Leader election in browser tabs, the easy way
Leader election in multi-tab browser applications with Web Locks API