关于 cookie 和路径的 RFC 问题

发布于 2024-08-18 18:53:23 字数 882 浏览 9 评论 0原文

我试图在用户登录时设置一个仅限于特定路径(例如 /foo)的会话 cookie。复杂之处在于登录页面位于 / 上,但请求立即重定向到 /foo/something。像这样的东西:

请求:

POST / HTTP/1.1

username=foo&password=bar

响应:

HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo

但是,我可以找到 RFC 的相关位(rfc2109< /a> 和 rfc2965) 这样说:

为了防止可能的安全或隐私侵犯,用户代理 如果满足以下任一条件,则拒绝 cookie(不应存储其信息): 以下正确的是:

  • Path 属性的值不是请求的前缀 - URI。

...

上面描述的 cookie 设置过程似乎可以工作,但据我所知,RFC 说不应该。

我想在生产系统中使用它,但如果我以后会遇到可怕的浏览器不兼容问题,我真的不想这样做。

我是否误读了 RFC?

提前致谢!

I'm trying to set a session cookie restricted to a particular path (let's say /foo) when a user logs in. The complication being that the login page is on /, but the request immediately redirects to /foo/something. Something like this:

Request:

POST / HTTP/1.1

username=foo&password=bar

Response:

HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo

However, the relevant bits of the RFCs I could find (rfc2109 and rfc2965) say this:

To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:

  • The value for the Path attribute is not a prefix of the request-
    URI.

...

The cookie-setting process described above seems to work okay, but as far as I can tell the RFCs are saying it shouldn't.

I'd like to use this in a production system, but I really don't want to do that if I'm going to face horrible browser incompatibility problems later.

Am I misreading the RFCs?

Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

凉栀 2024-08-25 18:53:23

不要关注那些 RFC;他们与现实严重背离。

目前有一个 IETF 工作组正在记录实际的 cookie 行为;他们的文件虽然只是草稿,但却是更好的原始材料。

看:
http://datatracker.ietf.org/doc/draft-ietf-httpstate -cookie/

如果您在草稿中找不到解决您问题的文本,请向工作组提出!

Don't pay any attention to those RFCs; they diverge from reality pretty badly.

There's currently an IETF WG that's documenting actual cookie behaviour; their document, while just a draft, is much better source material.

See:
http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/

If you don't find text that addresses your question in the draft, bring it up with the Working Group!

莳間冲淡了誓言ζ 2024-08-25 18:53:23

根据你的问题,我认为你对RFC的理解是正确的。听起来您想在重定向到 '/foo/home' 后设置 cookie。我认为真正的问题是:“你如何告诉 '/foo/home' 用户已通过 '/' 正确验证em>?”

如果您必须使用 Location 标头(重定向)从 '/''/foo/home',似乎唯一的方法是在 Location 标头的值中使用查询字符串参数。

也许需要考虑的一个设计问题是:为什么用户要针对他们将安全访问的路径之外的 URL 进行身份验证?如果唯一的安全内容位于 '/foo' 下,那么为什么不 POST 到 '/foo/login' > 而不是 '/' 进行身份验证?

Based on your question, I think your understanding of the RFC is correct. It sounds like you want to set the cookie after the redirect to '/foo/home'. I think the real question is: "How do you tell '/foo/home' that the user was authenticated correctly by '/'?"

If you must use a Location header (redirect) to get from '/' to '/foo/home', it seems the only way to do this would be to use a query string parameter in the Location header's value.

Maybe a design question to consider is: why are users authenticating against a URL outside of the path they will be accessing securely? If the only secure content is under '/foo', then why not POST to '/foo/login' instead of '/' for authentication?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文