如何在最初通过Safari 14/iOS 14加载的PWA中维护登录状态? [英] How to maintain login status in a PWA initially loaded via Safari 14/iOS 14?

问题描述

我们的要求是让用户通过URL登录到应用程序，并将该应用程序作为PWA添加到其主屏幕后，保持该登录状态，以便第二次登录已安装的PWA为不需要.在Android/Chrome上，这当然是可能的，PWA可以通过多种机制(包括cookie，IndexedDB，缓存)来初始存储和访问登录状态.

Our requirement is to have our users login to an app via a URL and, having added the app to their homescreen as a PWA, maintain that logged-in status, so that a second login to the installed PWA is not required. This is certainly possible under Android/Chrome where the logged-in status can be initially stored and accessed by the PWA via a variety of mechanisms (including cookie, IndexedDB, cache).

但是，现在看来，iOS 14/iPadOS 14下的PWA已被严格沙箱化，而Safari无法将登录状态传递给它. 多年以来，通过iOS的各种版本，提供了各种共享机制-在随后的版本中已过时.这些包括:

However, it now appears to us that a PWA under iOS 14/iPadOS 14 is tightly sandboxed and Safari has no way of passing logged-in status to it. Over the years, and through the various versions of iOS, a variety of sharing mechanisms have been offered - and rendered obsolete in a subsequent version. These include:

1. 通过伪造的端点访问的缓存( ref )

1. the cache, accessed via a fake endpoint (ref)
2. a session cookie (ref)

一种不依赖浏览器共享存储的机制是向URL添加服务器生成的令牌(参考)-这里的问题是它使Android/Chrome感到不安，后者在网络应用清单中使用了未经修改的start_url.

A mechanism that doesn't rely on browser-shared storage is the addition of a server-generated token to the URL (ref), (ref) - the problem here is that it upsets Android/Chrome, which uses an unmodified start_url in the web app manifest.

多年来，这是一个引发了许多SO问题的问题(上面提到了其中三个问题)，其中一些问题已经得到了显然可以在iOS早期版本中使用的解决方案的解答.我们现在想要的是一个既可以在最新版本下运行又可以在Android/Chrome下运行的解决方案.有优惠吗?

This is an issue which has provoked a number of SO questions over the years (three of them referenced above) and some of them have been answered with solutions that apparently worked under earlier versions of iOS. What we're wanting now is a solution which works under the latest version as well as it works under Android/Chrome. Any offers?

推荐答案

可以完成.这是我们成功完成的方式:

It can be done. Here's how we've succeeded in doing it:

1. 当用户最初登录浏览器中的应用程序时，我们会在服务器上生成一个UID.
2. 我们将此UID与服务器文件(access.data)中的用户名配对.
3. 我们动态生成Web应用清单.在其中，我们将start_url设置到索引页面，并附加包含UID的查询字符串，例如"start_url": "/<appname>/index.html?accessID=<UID>".
4. 我们创建一个Cookie，以验证该应用已被访问，例如access=granted.
5. 当用户以iOS PWA身份访问该应用程序时，该应用程序会查找该cookie并找不到它(运行；)-我们使用iOS缺陷之一(未在Safari和PWA之间共享cookie)来击败同样的缺陷.)
6. 缺少access cookie会告诉应用程序从查询字符串中提取UID.
7. 它将UID发送回服务器，服务器在access.data中查找匹配项.
8. 如果服务器找到匹配项，它会告知应用程序PWA用户已经登录，无需再次显示登录屏幕.任务完成了！

1. When the user initially logs in to the app in the browser, we generate a UID on the server.
2. We pair this UID with the username in a server file (access.data).
3. We generate the web app manifest dynamically. In it we set the start_url to the index page and append a query string incorporating the UID e.g. "start_url": "/<appname>/index.html?accessID=<UID>".
4. We create a cookie to verify that the app has been accessed e.g. access=granted.
5. When the user accesses the app as an iOS PWA, the app looks for this cookie and doesn't find it (cunning ;) - we use one of the iOS deficiencies (not sharing cookies between Safari and the PWA) to defeat that same deficiency).
6. The absence of the access cookie tells the app to extract the UID from the query string.
7. It sends the UID back to the server, which looks for a match in access.data.
8. If the server finds a match, it tells the app that the PWA user is already logged in and there's no need to again display the login screen. Mission accomplished!

注意:Android/Chrome只是忽略了查询字符串中的accessID-我的问题是错误的，它暗示Android/Chrome需要未修改的start_url.

Note: Android/Chrome simply ignores the accessID in the query string - I was wrong in my question to imply that Android/Chrome requires an unmodified start_url.

这篇关于如何在最初通过Safari 14/iOS 14加载的PWA中维护登录状态?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！