我有一个用 Django 构建的 shopify 应用程序，直到最近它都运行良好。会话不会在每个请求中持续存在，因此会引发异常，因为在前一个请求中设置的给定密钥的会话不存在。 在 Shopify 之外尝试应用程序端点可以正常工作，会话在请求之间完美地持续存在，因此这绝对是 Shopify 中的一个问题。
查看我们数据库中的会话表，我们看到多个会话键具有相同的数据，这表明每个请求正在创建另一个会话。我们如何在 iframe 中跨请求保持会话？
【问题讨论】：
标签： python django shopify shopify-app
使用的 Django 版本是 2.1，现在包含一个有助于防止 CSRF 攻击的新功能。根据docs，新的 SESSION_COOKIE_SAMESITE 默认值为“Lax”，介于“Strict”和“None”之间。
此功能显然适用于独立的 Django 应用程序，但在类似于 Shopify 的 iframe 中会导致它们中断。在 settings.py 中设置 SESSION_COOKIE_SAMESITE = None 解决了这个问题。
【讨论】：
您的方法不再有效。谷歌将很快禁止 3rd 方 cookie，而 Firefox 和 Safari 已经这样做了。新应用需要实现session token authentication，因为第三方 cookie 不会很快起作用。
为应用审核提交的新应用将在 Chrome 隐身标签下进行测试，默认情况下不允许第三方 Cookie。即使您添加“Samesite”，会话 ID 也不会通过 cookie。当它无法通过时，浏览器将再次重试，以便您看到创建了多个会话。起初，我认为这是服务器端错误，因为它看起来像日志中的无限循环。
默认情况下，当您在视图函数中调用 request.session 时，Django 会创建一个存储 sessionid 的 cookie。此 cookie 仅在您使用 request.session 时创建。如果您不使用 request.session，应用程序可以毫无问题地加载。但是根本不可能不使用会话。甚至示例 shopify django 应用程序也在使用会话。
我认为可能的方法是更改会话中间件。使用the reply from Shopify developer，我知道我们可以使用有效负载中的 shop (dest) 和 user (sub) 字段来创建一个唯一的 id 并根据该 id 存储您的会话数据。只需自定义 default session middleware，删除 request.cookies 并使用此 id 作为会话密钥。应该没问题的。
就个人而言，由于工作量太大，我没有更改此中间件。完成会话令牌身份验证后，我发现在测试人员进行应用审查期间会话无法持续。如果你可以实现App Bridge，session token auth 和更新默认的django session，就可以持久化session数据。
IMO，独立应用程序可能是 Python / Django 开发人员的更好选择。如果有人有更简单的方法，请告诉我。我迫切希望在没有任何具体例子的情况下研究所有这些。
【讨论】：