对 CloudFront 使用基于 cookie 的身份验证（未签名的 cookie）

Question

我对 CloudFront 比较陌生，我的公司正在考虑搬到那里的可能性。我们有一堆具有我们自己的基于 cookie 的身份验证机制的网站，非常简单：登录页面设置一个特殊的 cookie，所有其他请求在此 cookie 存在时提供，否则拒绝。

我们对 CloudFront 的期望如下：

1. 当对某个资源的第一个请求包含此 cookie 时，将 cookie 传递给源服务器。当没有cookie时，无论如何发送请求，在这种情况下返回拒绝访问错误是可以的。
2. 缓存返回的结果（如果成功）。
3. 对具有此 cookie 的同一资源的所有后续请求都应从缓存中获取。
4. 最好（但可选）检查 cookie 过期时间。
5. 此外，应应用基于标头的常用缓存控制规则。
6. 登录页面请求可能被缓存，也可能没有，这并不重要。

我尝试使用cookie白名单，但是不同登录的cookie内容不同，因此不同用户的相同资源请求被单独缓存，从而产生到我们源的完整流量。 重点是 - CloudFront 应考虑 cookie 名称和到期日期，但忽略其内容。

有没有办法做到这一点？

Answer 1

不，没有。原因如下：

当响应被网络缓存存储时，相应的请求也会被存储。缓存不能认为两个请求是相同的，除非它们确实是相同的个请求。

两个请求不能被认为是相同的，除非它们实际上在各个方面都是相同的，当考虑到发送到源的内容时。

在向源发送请求之前，CloudFront 会去除传入请求中它不会转发的任何内容——标头、cookie、查询字符串——以及所有剩余的...也就是说，将发送到源的所有内容......都是将在后续请求中进行比较的内容。

这样做的原因是缓存被禁止返回无效响应，除非向源发送相同的请求，否则缓存无法知道响应是否也会相同；因此，导致向源服务器发送不同内容的请求将永远不会收到源为（根据定义）不同的请求返回的缓存响应。

这就是 CloudFront 允许选择性地将标头和 cookie 列入白名单的原因：这样您就可以将实际转发的内容缩减为仅源需要查看的内容，以便做出适当的响应。白名单越少，后续请求实际上相同的可能性就越大。

例如，如果您将 User-Agent: 标头转发到源，则源服务器可能会根据应用于用户代理的启发式方法做出不同的响应（例如，为 IE 提供不同的内容，而不是为 Firefox 或 Chrome 提供不同的内容，以适应IE 的怪癖）。如果您的来源需要该信息，您必须转发它，并承担随之而来的惩罚——响应只会从缓存中提供给使用相同浏览器的另一个用户。如果您不需要用户代理字符串，则不要转发它——出于这个原因。

仅按名称评估 cookie 显然与此逻辑不符。 cookie 值不同，因为用户身份不同，并且应该合理地预期来源会做出不同的响应。 （另外，请注意，当浏览器显示 cookie 时，它​​不会显示过期时间。该信息仅在服务器设置 cookie 时出现。）

如果您需要为缓存对象提供经过身份验证的访问，您需要使用 CloudFront 的内置身份验证机制之一，而不是使用 cookie 将身份验证/授权传递到源。