You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To sum it up, I can't rely on cross origin cookies to store a session token, because browsers allow disabling them nowadays. For that reason, I pass it to a well known location at the origin which needs the token as a get parameter. If that origin has a service worker installed, it could intercept that token. For some applications, that may be desirable, but for others, it could be problematic.
I'm still looking for a safer way to pass the token, but it would be nice to also have a way to prevent a service worker from handling requests to certain locations too.
For that reason, I propose adding a Service-Worker-Exclude header, that would have some similarities to the Service-Worker-Allowed header. I would like it to work as follows. Service-Worker-Exclude should contain a list of locations who will not be handled by the service worker and just bypass it entirely. It should be set when installing the service worker. That way, I could, for example, make sure the entire /.well-known/ directory won't be handled by a service worker.
The text was updated successfully, but these errors were encountered:
A service worker is controlled by the same origin that you’re sending the request to. What’s being imagined here, exactly? It seems considerably more shaky at a glance to me to suggest requests from a different origin should be able to choose to bypass internal aspects of that origin’s own implementation of its endpoints.
That's not what I'm proposing. I'm proposing that, when an origin installs it's worker, a Service-Worker-Exclude header can be provided to exclude certain locations on it's own origin from being handled by it.
My understanding is, that it already doesn't matter where a request came from, but only where it goes to, for which service worker is going to handle it, and that the Service-Worker-Allowed header already operates in a similar way regarding when it needs to be set.
My proposal doesn't change any of that. It just allows to make sure some locations won't be handled by a service worker.
I do have a use-case where this would be useful, by allowing me to make sure the client side of my application won't be able to intercept a request to a specific location on my applications origin. But that is just a use-case, something this would be useful for, not the proposal itself.
I'm currently developing an SSO solution, and ran into some difficulties: https://github.com/Daniel-Abrecht/dpa-sso#security-relevant-limitations
To sum it up, I can't rely on cross origin cookies to store a session token, because browsers allow disabling them nowadays. For that reason, I pass it to a well known location at the origin which needs the token as a get parameter. If that origin has a service worker installed, it could intercept that token. For some applications, that may be desirable, but for others, it could be problematic.
I'm still looking for a safer way to pass the token, but it would be nice to also have a way to prevent a service worker from handling requests to certain locations too.
For that reason, I propose adding a
Service-Worker-Exclude
header, that would have some similarities to theService-Worker-Allowed
header. I would like it to work as follows.Service-Worker-Exclude
should contain a list of locations who will not be handled by the service worker and just bypass it entirely. It should be set when installing the service worker. That way, I could, for example, make sure the entire/.well-known/
directory won't be handled by a service worker.The text was updated successfully, but these errors were encountered: