当前位置：文江博客话题详情

在 302 重定向期间发送浏览器 cookie

发布于 2024-10-12 01:57:32 字数 106 浏览 2 评论 0原文

在 302 重定向期间发回 cookie 是否存在任何问题？例如，如果我创建一个 return-to-url cookie 并在同一响应中重定向用户，任何（现代）浏览器都会忽略该 cookie 吗？

原文

分享到QQ

分享到微博

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

发布评论

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

把梦留给海 2024-10-19 01:57:32

根据这篇博客文章： http://blog.dubbelboer.com/2012 /11/25/302-cookie.html 所有主流浏览器，IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) 均在 Windows 上和 Mac，在重定向上设置 cookie。对于 301 和 302 重定向都是如此。

正如 @Benni 指出的：

https://www.chromium。 org/administrators/policy-list-3/cookie-legacy-samesite-policies

Cookie 的 SameSite 属性指定 Cookie 是否应限制为第一方上下文或同一站点上下文。 SameSite 允许有多个值：
带有“SameSite=Strict” 的 Cookie 只会与同一站点请求一起发送。
带有“SameSite=Lax”的cookie将与同站点请求一起发送，或者使用“安全”HTTP方法进行跨站点顶级导航。
带有 “SameSite=None” 的 Cookie 将与同站点和跨站点请求一起发送。

回复收藏 0 原文

戏剧牡丹亭 2024-10-19 01:57:32

一个通知（以挽救开发人员的生命）：

当 cookie 的域为 localhost 时，IE 和 Edge 会忽略重定向响应中的 Set-Cookie。

解决方案：

使用127.0.0.1而不是localhost。

回复收藏 0 原文

江心雾 2024-10-19 01:57:32

大多数浏览器都接受 302 重定向的 cookie。我对此非常确定，但我做了一些搜索。并非所有现代浏览器。
来自现已删除/失效的 Internet 存档链接 microsoft connect Silverlight 客户端 HTTP 堆栈上的 Q/A 忽略 Set-Cookie 302 重定向响应 (2010)

我认为我们现在有了 IE6 的替代品，它就是 Windows Mobile 浏览器...

回复收藏 0 原文

阳光下的泡沫是彩色的 2024-10-19 01:57:32

我们最近（2022 年 3 月）遇到了这个问题 - Firefox 和 Chrome 都没有立即在 HTTP 302 重定向上设置 cookie。

详细信息：

我们发送了带有 Set-Cookie 标头的 HTTP 302 重定向，其中包含 "SameSite=Strict" 策略和指向同一域的不同路径的位置。
但是，浏览器没有在后续 GET 请求（重定向的位置）中发送 Cookie，即使它确实位于同一域（第一方请求）。
我们可以从浏览器存储检查选项卡中看到 Cookie，但在 302 响应之后的请求中看不到 Cookie。
当我们刷新页面（或在地址栏中按回车键）时，一切又恢复正常，因为 Cookie 在所有后续请求中都已正确发送。
我们认为这可能是一个错误/未记录的行为。就好像浏览器存储 cookie“有点太晚了”。

我们必须通过客户端重定向来提供 HTTP 200 来解决这个问题：

<!DOCTYPE html>
<html>
<head><meta http-equiv="refresh" content="0; url='REDIRECT_URL'"></head>
<body></body>
</html>

We hit this issue recently (Mar 2022) - both Firefox and Chrome didn't set the cookies immediately on HTTP 302 redirect.

Details:

We sent HTTP 302 redirect with Set-Cookie header with "SameSite=Strict" policy and Location pointing at a different path of the same domain.
However, the browser didn't send the Cookie in the subsequent GET request (the redirect's Location), even though it was indeed on the same domain (first-party request).
We could see the Cookie from the browser storage inspect tab, but not in the request immediately following the 302 response.
When we refreshed the page (or hit enter in the address bar), everything worked again, as the Cookie was sent properly in all following requests.
We think this might be a bug / undocumented behaviour. It's like the browser stored the cookie "a little too late".

We had to work around this by serving HTTP 200 with a client-side redirect instead:

<!DOCTYPE html>
<html>
<head><meta http-equiv="refresh" content="0; url='REDIRECT_URL'"></head>
<body></body>
</html>

回复收藏 0 原文

无人问我粥可暖 2024-10-19 01:57:32

这里是此问题的 Chromium 错误（Set-cookie 被忽略）对于状态为 302 的 HTTP 响应）。

回复收藏 0 原文

一抹苦笑 2024-10-19 01:57:32

我刚刚在 Firefox 和 Safari 上都遇到了这个问题，但 Chrome 没有。根据我的测试，只有当域在重定向期间发生更改时才会发生这种情况。这是 OAuth2 流程中的典型情况：

OAuth2 id 提供商（GitHub、Twitter、Google）将浏览器重定向回您的应用程序
您的应用程序的回调 URL 验证授权并设置登录 cookie，然后再次重定向到目标 URL
您的目标 URL 加载时不带任何 cookie放。

由于我尚未弄清楚的原因，请求 2 中的一些 cookie 被忽略，而其他 cookie 则未被忽略。但是，如果请求 2 返回带有 Refresh 标头（“元刷新”重定向）的 HTTP 200，则请求 3 会正确设置 cookie。

回复收藏 0 原文

你げ笑在眉眼 2024-10-19 01:57:32

这是一种非常不受欢迎的方法，但如果您确实不想依赖 30x set-cookie 浏览器行为，您可以在设置 cookie 时使用 HTML meta http-equiv="refresh" “redirect” 。例如，在 PHP 中：

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

服务器将发送带有 200 而不是正确的 300x 重定向的 Set-Cookie，因此浏览器将存储 cookie，然后执行“重定向”。链接是浏览器不执行元刷新时的后备链接。

This is a really frowned upon approach, but if you really want to not rely on 30x set-cookie browser behavior you could use an HTML meta http-equiv="refresh" "redirect" when setting the cookie. For example, in PHP:

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

Server will send Set-Cookie with a 200 instead of a proper 300x redirect, so browser will store the cookie, and then perform the "redirect". The <a> link is a fallback in case browser does not perform the meta refresh.

回复收藏 0 原文

弄潮 2024-10-19 01:57:32

在 .Net 上使用 OpenIdConnect / IdentityServer 时遇到此问题，其中单独的 API（不同的主机名）处理身份验证并重定向回主站点。

首先（对于本地主机上的开发）您需要将 CookieSecure 选项设置为 SameAsRequest 或 Never 来处理 http://localhost/ 不安全。请参阅 Michael Freidgeim 的回答。

其次，您需要将 CookieSameSite 属性设置为 Lax，否则 cookie 根本不会保存。 严格在这里不起作用！

回复收藏 0 原文

薄荷梦 2024-10-19 01:57:32

就我而言，我设置 CookieOptions.Secure=true，但在 http://localhost 上进行了测试，并且浏览器根据以下内容隐藏 cookie设置。

为了避免此类问题，您可以使cookie Secure选项匹配协议Request.IsHttps，例如

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }

In my case I set CookieOptions.Secure=true, but tested it on http://localhost., and browser hide cookies according to the setting.

To avoid such problem, you can make cookie Secure option to match protocol Request.IsHttps,e.g.

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }

回复收藏 0 原文

~没有更多了~