我一定是忽略了饼干的一些基本特性。在localhost上,当我在服务器端设置cookie并显式地将域指定为localhost(或.localhost)时。有些浏览器似乎不接受cookie。

Firefox 3.5:我在Firebug中检查了HTTP请求。我看到的是:

Set-Cookie:
    name=value;
    domain=localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

或者(当我设置域为.localhost时):

Set-Cookie:
    name=value;
    domain=.localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

在这两种情况下,cookie都不会被存储。

IE8:我没有使用任何额外的工具,但cookie似乎没有被存储,因为它没有在后续的请求中被发送回来。

Opera 9.64: localhost和.localhost都可以工作,但是当我检查Preferences中的cookie列表时,域被设置为localhost。Local,即使它列在localhost下(在列表分组中)。

Safari 4: localhost和.localhost都可以工作,但它们总是在首选项中列出为.localhost。另一方面,一个没有显式域的cookie,它只显示为localhost(没有点)。

localhost有什么问题?由于存在如此多的不一致,必须有一些涉及localhost的特殊规则。另外,我也不完全清楚为什么域名必须以一个点作为前缀?RFC 2109明确指出:

Domain属性的值 不包含或不包含嵌入点 从一个点开始。

为什么?该文档表明它必须在安全性方面做一些事情。我必须承认我没有阅读完整的规范(可能以后会读),但它听起来有点奇怪。基于此,在本地主机上设置cookie是不可能的。


当前回答

localhost:你可以使用:domain: ".app。Localhost”,它会工作。“domain”参数需要在域名中加上一个或多个点,用于设置cookie。然后你可以让会话跨localhost子域工作,比如:api.app.localhost:3000。

其他回答

在2011年开放的Chromium上有一个问题,如果你显式地将域设置为“localhost”,你应该将它设置为false或未定义。

我只是玩玩而已。

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=localhost; Path=/

目前可以在Firefox和Chrome上运行。但是,我没有找到一种方法使它与卷曲一起工作。我试过Host-Header和——决心,没有运气,感谢任何帮助。

但是,如果我设置为,它在curl中工作

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=127.0.0.1; Path=/

代替。(Firefox不支持这个功能。)

唯一对我有用的是在cookie上设置Path=/。

此外,路径属性的默认值似乎因浏览器而异,尽管我只测试了其中两种(Firefox和Chrome)。

Chrome试图设置cookie是;如果路径属性在Set-Cookie头中被省略,那么它将不会被存储和忽略。

然而,Firefox即使没有显式的路径属性也可以存储cookie。它只是用请求的路径设置它;我的请求url是/api/v1/users,路径被自动设置为/api/v1。

不管怎样,当path被设置为/时,即使没有显式的域,即domain =localhost或其他东西,这两个浏览器都可以工作。因此,每种浏览器处理cookie的方式都有所不同。

当您使用https://<local-domain>然后使用http://<local-domain>时,似乎有一个问题。https:// site设置cookie后,http:// site不会随请求一起发送cookie。强制重载和清除缓存没有帮助。只有手动清除cookie才能工作。同样,如果我在https://页面上清除它们,那么http://页面将重新开始工作。

看起来和"严格安全cookie "有关。解释得很好。它于2017-04-19在Chrome 58中发布。

看起来Chrome确实记录了安全cookie和非安全cookie,因为当点击地址栏图标时,它会根据页面的协议显示正确的cookie。

但是开发工具>应用程序> Cookies将不会显示一个非安全cookie,当有一个安全cookie的相同名称的同一域,它也不会发送非安全cookie与任何请求。这似乎是一个Chrome错误,或者如果这种行为是预期的,应该有一些方法来查看安全cookie时,http页面和一个指示,他们正在被覆盖。

解决方法是使用不同的命名cookie,这取决于它们是用于http站点还是https站点,并根据您的应用程序具体命名它们。__Secure-前缀表明cookie应该是严格安全的,这也是一个很好的实践,因为安全和非安全不会冲突。前缀还有其他好处。

使用不同的/etc/hosts域进行https和http访问也可以,但是一次意外的https://localhost访问将阻止任何相同名称的cookie在http://localhost站点上工作-所以这不是一个好的解决方案。

我已经提交了Chrome错误报告。

我在使用127.0.0.1作为域进行本地测试时运气要好得多。我不知道为什么,但我有混合的结果与localhost和.localhost等。