具有相同名称/路径的多个Cookie的浏览器行为 [英] Browser behavior for multiple cookies with same name/path

问题描述

我对各种浏览器的行为感兴趣，当有多个Cookie具有相同的名称和路径对当前域有效。例如。浏览器存储了这两个cookie：

  key = value; path = /; domain = foo.bar.baz 
 key = value; path = /; domain = bar.baz 
  

Cookie <当用户访问 foo.bar.baz ？

RFC 2965 有这个问题：

如果多个cookie满足上面的条件，它们在
的Cookie头中排序，这样具有更特定的Path属性
的那些在具有较少特定的那些之前。关于其他
属性（例如，域）的订购未指定。

（这是IMO非常奇怪的设计选择，但这是我们有）。我想服务器端框架使用第一个值，beacause，至少有时更具体（我检查PHP，它确实这样做）。

我想要知道主要浏览器的行为：他们首先发送哪个cookie？ （换句话说，我可以依靠我的应用程序获得正确，更具体的值多少？）

解决方案

从我的POV中明显未定义的行为（标准方面）的最简单的防御是不使用 在主域上输入PHPSESSID - 子域将正常工作，因为根据标准，在这种情况下没有后备，所以cookie保留在其自己的子域上。

一个可能的问题需要选中：

在子域上运行的PHP脚本可以显式配置为在主域上设置其cookie ...如果是这样（代码看起来类似 ini_set（'session.cookie_domain'，'bar.baz'）; ）然后你需要将此配置更改为标准（通过删除显示的代码）意味着子域上的脚本只应在自己的子域上设置Cookie。

EDIT - 按照注释：
$ b

如果您无法控制其他子网域，则最终防御是将您的 PHPSESSID cookie转换为真正唯一的某个GUID（例如具有 PHPSESSID 作为前缀的GUID）或 session_start（） a> OR或在设置中进行设置 - 这样，无论子域/浏览器版本等都能避开整个问题。

I'm interested in the behavior of various browsers when there are multiple cookies with the same name and path which are valid for the current domain. E.g. the browser has stored these two cookies:

key=value; path=/; domain=foo.bar.baz
key=value; path=/; domain=bar.baz

What will be the content of the Cookie header when the user visits foo.bar.baz?

RFC 2965 has this to say about the issue:

If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified.

(which is IMO a very weird design choice, but that is what we have). I suppose server-side frameworks use the first value, beacause that is at least sometimes more specific (I checked PHP and it indeed does so).

What I would like to know is the behavior of the major browsers: which cookie would they send first? (In other words, how much can I rely on my application getting the "correct", more specific value?)

解决方案

As per comments above:

The easiest defense against this obviously "undefined behaviour (standard-wise)" from my POV is to not use PHPSESSID on the main domain bar.baz but instead on www.bar.baz - the subdomains will work fine since according to the standard there is no "fallback" in that case so the cookie stays on its own subdomain.

One possible problem needs to be checked:

PHP scripts running on a subdomain can be configured explicitly to set their cookie on the main domain... IF that is the case (code looks similar to ini_set('session.cookie_domain', 'bar.baz');) then you need to change this config to "standard" (by removing the code shown) which means that a script on a subdomain should only set cookies on its own subdomain.

EDIT - as per comments:

IF you don't have any control over some other subdomain then the "ultimate defense" is to rename your PHPSESSID cookie to something really unique (like a GUID with PHPSESSID as prefix) either by calling session_name() BEFORE session_start() OR by setting it in the config - this way you circumvent the whole problem regardless of subdomains/browser versions etc.

这篇关于具有相同名称/路径的多个Cookie的浏览器行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！