-
Notifications
You must be signed in to change notification settings - Fork 822
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
Document / Advise on User-based caching for Authenticated Content #1354
Comments
We don't have an out-of-the-box solution. If you only need to ensure that a single user can be logged in at any given time, a simple model is storing all personalized data in a single runtime cache and then calling If you need to support multiple logged in users in a single browser session, then that leads to a few follow-up questions, like how you determine from looking at an HTTP request/response pair which user it's associated with—e.g., is there a specific header value that will remain constant, and which uniquely determines that info? |
Hi Jeff, Without getting into too much detail of the specific auth implementation (it's pretty complex in our case..), let's simplify things, and say we support 1 user at a time. I am assuming a lot of other Authenticated SPAs will have a similar scenario to the one I will outline.
Here are the suggestions/discussion points I'd make for this scenario.
|
Regarding 1), I'm personally not qualified to comment one way or another about the guarantees that the Cache Storage API offers when storing a The code that's used for writing to the runtime caches currently looks like
and if there were a need to use an "empty" await cache.put(request.url, responseToCache); Regarding 5), even if you don't use a consistent naming scheme for your runtime caches, you can synthesize some of that information by making use of const nonPrecacheCacheNames = await caches.keys()
.filter(cacheName => cacheName !== workbox.core.cacheNames.precache);
// Do something with nonPrecacheCacheNames, like delete them. One thing that I'm not sure about is how well the current Maybe the solution there is to expose a |
Just brainstorming here.. It might make sense to have a plugin / callback that enables the developer to set their custom Yes (regarding your response to 5.) this is basically how we've implemented |
Looking back at the v2 branch, we did have support for passing in an alternative cache key to use, other than the actual workbox/packages/workbox-runtime-caching/src/lib/request-wrapper.js Lines 378 to 380 in 5b97922
I think the only place we were using it was in the precaching code, and it wasn't easy to hook into a plugin event to override:
Anyway... let me break out your two suggestions into separate feature requests so that they could each be tracked. |
With those two issues created, are you cool with closing this one and following up on each independently, @josephliccini? |
Yeah will do! Thanks so much for your work and openness to suggestions. |
Library Affected:
workbox-sw
Browser & Platform:
All
Issue or Feature Request Description:
Hi again!
So we are working through handling multiple users logged in to our site. Without going into too much detail.. there are cases where 2 different users' runtime API caches could overlap, so we'd like to make sure caches are scoped by user ID.
Does workbox have a suggestion for this? It seems like a pattern not discussed in very many places. I was working through it and it seems like it can get a bit complex..
Maybe we can brainstorm a solution here?
Thanks!
Joe
When reporting bugs, please include relevant JavaScript Console logs and links to public URLs at which the issue could be reproduced.
The text was updated successfully, but these errors were encountered: