【发布时间】：2023-04-02 05:48:01
【问题描述】：
例如，
如果我的应用程序（由 GCR 自动扩展）具有针对第三方身份提供者的 OAuth 2.0 + PKCE 授权代码流，我能否保证在用户登录第三方网站并被重定向回来后，他们是重定向回同一个实例？
如果不是，它们被重定向回的新实例将不知道 code_verifier，身份验证将失败。
【问题讨论】：
标签： google-cloud-run
【发布时间】：2023-04-02 05:48:01
【问题描述】：
Cloud Run 负载平衡不保证在用户的连续请求（即粘性会话）上登陆到同一个实例。在这两个请求之间，容器可能已经崩溃、缩小并再次放大。
Cloud Run 容器旨在无状态。因此，如果您在应用程序中存储了任何多步骤身份验证或会话 ID，则应将此类状态存储在外部存储（如 Cloud Memorystore、Redis、Memcached 或数据库）中。
【讨论】：
-
是否有任何关于从 Cloud Run 部署的应用程序连接到 Memorystore 的文档？只需使用 Memorystore IP 和端口配置 redis 客户端，我就会超时。 （没想到这么简单！）我猜它与 VPC/IAM 等有关？
-
没关系 - 我刚刚看到了这个：stackoverflow.com/questions/56225375/… 在 Cloud Run 支持 VCP 连接之前，我将使用 redis 实验室。
由于Cloud Run is designed to run "stateless containers"，您不能依赖应用程序的内部状态。
您必须将信息保存到外部存储中，以便任何实例都可以访问它。
【讨论】：
身份验证和用户首选项的会话处理在 Cloud Run 或任何可扩展的环境中将无法正常工作。
因为大多数应用程序都使用基于内存的实现来执行此功能。但是，此实现不适合可以从多个实例提供服务的应用程序，因为在一个实例中记录的会话可能与其他实例不同。
因此，您必须将其存储在所有实例都引用会话信息的普通位置。
对于截至 2020 年 3 月的 Cloud Run 可用解决方案，
你可以启动Redis on Compute Engine（当然很贵！）
您可以使用来自Redis Labs的Redis实例
您可以使用 Cloud Firestore。 （便宜，但不是有效的解决方案）
注意：Cloud Firestore 是一个持久的分布式事务数据库。通常，为会话选择不同的存储解决方案（例如 Memcache 或 Redis）更合适，因为它们的设计在此用例中提供了更快的操作。
这是一个包含 Nodejs 示例的文档：https://cloud.google.com/nodejs/getting-started/session-handling-with-firestore
到目前为止，其他已知的 Cloud Run 限制。 check here
【讨论】：
您需要外部数据存储，因为 Cloud Run 是无状态的。
您可以使用Upstash（一种无服务器且持久的 Redis 服务）来保存您的会话数据。
【讨论】：