OpenID Microsoft登录后Safari iOS（13.5）中导航点击的PWA冻结 OpenID授权用户后PWA冻结[iOS Safari Standalone]

我为我们的安全人员建立了一个简单的PWA，允许员工点击链接并查看有关公司各种事务政策的内容。该应用程序使用Microsoft的OWIN中间件库授权我们的员工通过其企业Microsoft登录凭据访问该应用程序。当用户单击我们登录页面上的“员工登录”提示时，他们将被重定向到Microsoft域以完成登录过程。登录完成后，他们将被重定向回我们应用程序的主页

问题 当iOS用户（v13）将应用程序锁定到主屏幕，然后以独立模式启动应用程序，并且只有在用户完全终止应用程序并返回后，才会出现问题。我们已经在Chrome、Safari（非独立模式）、Firefox上测试了该应用程序，这些浏览器中没有出现这个问题。该应用程序可以无缝运行，直到用户完成Microsoft登录并被重定向回主页为止。此时，如果用户单击指向另一个页面（在应用程序内）的链接，应用程序将完全锁定，不会对进一步的按钮单击做出响应，也不会加载用户提示的页面。控制台中不会抛出任何错误

我们发现，如果用户切换到另一个应用程序（哪怕只是一秒钟），然后在它被锁定时切换回我们的PWA，就会立即让一切恢复正常。此时，用户试图导航到的页面将立即加载，无需进一步提示，应用程序在此点后100%无缝运行。只有默认页面的初始版本才会冻结

潜在原因 我目前的工作理论是，该问题是由以下因素组合而成：

• 重定向到Microsoft的登录门户。当用户被发送到Microsoft进行身份验证，然后被发送回我们的域时，可能会出现会话/cookie连续性问题
• iOS的独立模式。结合上述情况，使用第三方身份验证并短暂离开PWA域是否可能导致未来页面导航出现问题。这是由没有其他浏览器或设备有这个问题的想法支持的，我的研究表明苹果对PWAs的支持仍处于早期阶段
• 服务人员故障。我们已经进行了重要的测试，以确保在用户首次进入站点时，服务人员已正确安装和注册。我们有重新注册软件的检查，以防它在页面导航中的任何位置被删除。我们确信，当用户在身份验证后被重定向回我们的主页时，有一个活动的服务工作者处理页面获取请求。我还测试了在服务人员注册期间显式缓存可从我们的主页访问的链接页面，以查看从缓存提供页面是否会缓解问题。事实并非如此。这是sw.js中处理获取请求的代码（摘自Google的handy guide）：

我已经使用Mac在单机版上远程调试了PWA，我验证的是，当用户单击链接导航到新页面时触发的单击事件正在得到正确处理，因此问题似乎确实在于加载链接页面本身。除此之外，远程调试已确认，在尝试导航到站点上的其他页面时，根本没有触发HTTP GET错误（或任何其他错误）

---

这是我建立的第一个PWA，我是所有这些东西的新手。所以我很想知道我是否错过了什么或者我能从这里走到哪里。我浏览了所有的论坛，似乎在任何地方都找不到答案。谢谢

最近也经历过类似的情况，我们重定向到的页面（用于支付网关集成）没有web.manifest，因此重定向回我们的页面不起作用。我们通过向重定向的页面添加web.manifest（它在我们的控制下）解决了这个问题。在您的情况下，因为您无法处理Microsoft页面，您是否尝试过使用Iframe？我的PWA也遇到了同样的问题。你最终找到了什么好的解决方案/解决办法吗？

    // "cache-first" approach for requests from client. Will try to get the file from the cache.
    // If no match found, it will send the request onto the network. If both fail serve fallback page.
    self.addEventListener("fetch", function (event) {
        if (event.request.method !== "GET") return;
        event.respondWith(
            // Try the cache
            caches.match(event.request).then(function (response) {
                console.log("[service worker] attempting to fetch file from cache...");
                return response || fetch(event.request);
            }).catch(function () {
                // If both fail, show a generic fallback:
                return caches.match(offlineFallbackPage);
            })
        );
    });