当应用在离线时被重新访问时，让用户在 PWA 中进行身份验证的最佳方式是什么。
例子..
5 是我需要建议的部分，日志需要安全，因此 cookie/localstorage 中的令牌不够好。
有什么建议吗？
【问题讨论】：
标签： angular service-worker progressive-web-apps
如果您想让您的应用自动记住用户，您需要将令牌存储在某处。将其存储在本地存储中应该没问题。
如果您在 ng se 配置中设置了 dataGroups，Angular 会存储外部请求。这是基于 URI 缓存的。我现在可以看到您有两个选项：
选项 1： 在每个 API 响应中返回用户 ID，如果您使用 jwt 令牌，则将用户 ID 存储在令牌正文中。当您在基于该 ID 的 Angular 过滤器中收到 API 请求时。当你有网络连接时，这不会做任何事情，因为你只有用户可以看到的东西。但是当您离线时，您不能保证缓存的数据来自当前用户。如果用户 A 登录并获取数据，用户 B 登录但未获取该数据，则缓存的响应包含用户 A 而不是 B 的数据，并且 B 不应该看到它。这个选项的问题是用户 A 的响应仍然存储在缓存中，所以如果用户 B 要查看服务工作者缓存，那么他们会看到它。
选项 2： 手动使服务工作人员在登录或注销时为外部 api 请求存储的数据无效。这将保证您缓存的数据属于当前用户。选项 1 的优点是您不需要在响应中存储和检查用户的 ID，因为您知道它必须是用户的。此外，您不必担心其他用户查看 service worker 缓存并看到其他人的响应，因为当第一个用户注销或第二个用户登录时，这些响应将被记入。这里的缺点是您必须手动使 Service Worker 缓存无效，因为 Angular 没有适当的机制来为您处理此问题。
选项 3： 将用户 ID 添加到 URI。由于 Angular 使用 URI 作为键存储数据，因此如果您将用户 ID 添加到 URI，它将存储该用户（和其他用户）的 api 响应。这听起来可能很理想，但这意味着任何用户都可以访问服务工作者缓存并查看为登录到此 Workstation 中的应用程序的每个用户缓存的 api 响应。此外，您的 API 请求 URI 不应将用户 ID 作为其一部分；它应来自令牌正文或查询。您应该不惜一切代价避免这种选择！
我会建议 1 或 2，这取决于您是否愿意尝试使 Service Worker 缓存失效。
【讨论】：