使用 JS serviceWorker 作为身份代理 - 尝试检测 `access_token` 注销
我正在使用JS ServiceWorkers作为身份代理进行评估，并在fetch（）呼叫上注入access_token。
const addAuthHeader = function (event) {
destURL = new URL(event.request.url);
if (whitelistedOrigins.includes(destURL.origin) && whitelistedPathRegex.test(destURL.pathname)) {
const modifiedHeaders = new Headers(event.request.headers);
if (token) {
modifiedHeaders.append('Authorization', token) //< Injection
}
const authReq = new Request(event.request, {headers: modifiedHeaders, mode: 'cors' });
event.respondWith((async () => fetch(authReq))());
}
}
// Intercept all fetch requests and add the auth header
self.addEventListener('fetch', addAuthHeader);
令牌存储在ServiceWorker类中的闭合变量中。 单击此处以获取有关此方法的更多信息。
我遇到的一个问题是，当更新服务工人时，令牌变量被覆盖，access_token将丢失。
有没有办法检测服务工人已更新？或者，要保护令牌变量？是否有一个设计模式/标准您可以指向与我一样使用ServiceWorker作为身份代理的关系？
I am evaluating using a JS ServiceWorkers as an identity proxy, injecting the access_token on fetch() calls.
const addAuthHeader = function (event) {
destURL = new URL(event.request.url);
if (whitelistedOrigins.includes(destURL.origin) && whitelistedPathRegex.test(destURL.pathname)) {
const modifiedHeaders = new Headers(event.request.headers);
if (token) {
modifiedHeaders.append('Authorization', token) //< Injection
}
const authReq = new Request(event.request, {headers: modifiedHeaders, mode: 'cors' });
event.respondWith((async () => fetch(authReq))());
}
}
// Intercept all fetch requests and add the auth header
self.addEventListener('fetch', addAuthHeader);
The token is stored in a closure variable within the serviceWorker class. Click here for more information about this approach.
One problem I am running into is that when the serviceWorker is updated, the token variable is being overwritten and the access_token is lost.
Is there a way to detect that the serviceWorker has been updated? Or, to protect the token variable? Is there a design pattern/standard you can point me towards related to using serviceWorker as an identity proxy as I have done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议不要采用一种要求服务人员控制给定页面以处理任何与安全/身份相关的内容的方法。
首先，第一次访问您页面的用户还没有安装 Service Worker，因此它无法控制当前页面。此外，熟悉浏览器开发人员工具的用户可以随时取消注册 Service Worker，和/或使用 Shift-Reload 来访问您的页面，而无需活动 Service Worker 进行控制。所以你真的不能依赖服务人员总是在那里。
其次，Service Worker 的全局状态是短暂的，您不能依赖多个事件调用中存在的变量。有关详细信息，请参阅“事件处理程序之外的服务工作线程中的代码何时运行？”。
一般来说，您应该将 Service Worker 内部的行为视为逐步增强 Web 应用程序的核心功能，而不是将任何所需的功能移至 Service Worker。
I would advise against an approach that requires a service worker to be in control of a given page for anything security/identity related.
First off, users who visit your page for the first time will not have a service worker installed yet, so it won't be in control of the current page. Additionally, users who are familiar with the browser's developer tools can unregister a service worker at any time, and/or use shift-reload to visit your page without the active service worker in control. So you really can't rely on the service worker always being there.
Second, a service worker's global state is short-lived, and you can't rely on variables being present across multiple event invocations. There are more details about that in "When does code in a service worker outside of an event handler run?".
Generally speaking, you should consider the behavior inside of a service worker as progressively enhancing the core functionality of your web app, and not move any required functionality to the service worker.