在CloudFront中使用基于cookie的身份验证(未签名的cookie)

时间:2015-10-26 10:27:09

标签: amazon-cloudfront

我对CloudFront相对较新,我的公司正考虑转移到那里。我们有一堆网站,我们拥有自己的基于cookie的身份验证机制,非常简单:登录页面设置了一个特殊的cookie,这个cookie存在时所有其他请求都被提供,否则就被拒绝。

我们希望从CloudFront获得以下内容:

  1. 当对某个资源的第一个请求包含此cookie时,将cookie传递给源服务器。如果没有cookie,无论如何都要发送请求,在这种情况下可以返回拒绝访问的错误。
  2. 缓存返回的结果(如果成功)。
  3. 对具有此cookie的同一资源的所有后续请求都应从缓存中获取。
  4. 最佳(但可选),应检查cookie过期。
  5. 此外,应该适用基于标题的常用缓存控制规则。
  6. 登录页面请求可能会被缓存,这并不重要。
  7. 我尝试使用Cookie白名单,但不同登录的Cookie内容不同,因此不同用户的相同资源请求会单独缓存,从而为我们的来源产生完整的流量。 重点是 - CloudFront应考虑cookie名称和到期日期,但忽略其内容。

    有没有办法实现这个目标?

1 个答案:

答案 0 :(得分:2)

不,没有。原因如下:

当Web缓存存储响应时,也会存储相应的请求。除非它们确实是相同的请求,否则缓存不能认为两个请求是相同的。

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

在向源发送请求之前,CloudFront会删除任何不会转发的请求 - 标头,Cookie,查询字符串 - 以及所有仍然是...是的,将要发送到原点的所有内容......将在后续请求中进行比较。

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

这就是为什么CloudFront允许选择性地将标题和cookie列入白名单的原因:这样您就可以将实际转发的内容修剪为原始需要查看的内容,以便做出适当的响应。白名单越少,后续请求实际上相同的可能性就越大。

例如,如果您将User-Agent:标头转发到原点,则原始服务器可能会根据应用于用户代理的启发式方式做出不同的响应(例如,为IE提供不同的内容,而不是Firefox或Chrome,适应IE的怪癖)。如果您的来源需要该信息,则必须转发它并承担随附的惩罚 - 响应将仅从具有相同浏览器的其他用户的缓存提供。如果您不需要用户代理字符串,则不要转发它 - 因此。

仅按名称评估cookie显然与此逻辑不一致。 cookie值是不同的,因为用户身份是不同的,并且合理地预期原点会以不同的方式响应。 (另请注意,当浏览器显示cookie时,它不会显示到期时间。该信息仅在服务器设置cookie时出现。)

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

相关问题