Có bất kỳ vấn đề nào với việc gửi lại cookie trong quá trình chuyển hướng 302 không? Ví dụ: nếu tôi tạo một cookie trả về url và chuyển hướng người dùng theo cùng một phản hồi thì có trình duyệt (hiện đại) nào bỏ qua cookie không?
Câu trả lời:
Hầu hết các trình duyệt đang chấp nhận cookie trên chuyển hướng 302. Tôi khá chắc chắn về điều đó, nhưng tôi đã tìm kiếm một chút. Không phải tất cả các trình duyệt hiện đại . Liên kết lưu trữ Internet từ một Q / A hiện đã bị xóa / chết / kết nối microsoft trên Silverlight Client HTTP Stack bỏ qua Set-Cookie trên 302 Redirect Responses (2010)
Tôi nghĩ bây giờ chúng ta có một sự thay thế cho IE6 và đó là các trình duyệt Windows Mobile ...
Theo bài đăng trên blog này: http://blog.dubbelboer.com/2012/11/25/302-cookie.html tất cả các trình duyệt chính, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) cả trên Windows và Mac, đặt cookie trên chuyển hướng. Điều này đúng cho cả chuyển hướng 301 và 302.
Một thông báo (để cứu mạng nhà phát triển):
IE và Edge đang bỏ qua Set-Cookie trong phản hồi chuyển hướng khi miền của cookie là localhost .
Giải pháp:
Sử dụng 127.0.0.1 thay vì localhost .
Đây là lỗi Chromium cho sự cố này (Set-cookie bị bỏ qua đối với phản hồi HTTP có trạng thái 302).
Đây thực sự là một cách tiếp cận khiến bạn khó chịu, nhưng nếu bạn thực sự không muốn dựa vào hành vi của trình duyệt set-cookie 30x, bạn có thể sử dụng meta http-equiv="refresh""chuyển hướng" HTML khi đặt cookie. Ví dụ, trong 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>
Máy chủ sẽ gửi Set-Cookie với 200 thay vì chuyển hướng 300x thích hợp, vì vậy trình duyệt sẽ lưu trữ cookie và sau đó thực hiện "chuyển hướng". Các <a>liên kết là một dự phòng trong trình duyệt trường hợp không thực hiện các meta refresh.
Tôi vừa gặp sự cố này với cả Firefox và Safari, nhưng không phải Chrome. Từ thử nghiệm của tôi, điều này chỉ xảy ra khi miền thay đổi trong quá trình chuyển hướng. Đây là điều điển hình trong luồng OAuth2:
Vì lý do mà tôi chưa tìm ra, một số cookie từ yêu cầu 2 bị bỏ qua trong khi những cookie khác thì không. Tuy nhiên, nếu yêu cầu 2 trả về HTTP 200 có Refreshtiêu đề (chuyển hướng "làm mới meta"), cookie được đặt đúng theo yêu cầu 3.
samesite=strict. Đối với yêu cầu gọi lại, trình duyệt vẫn nghĩ rằng người khởi tạo là google (hoặc bất kỳ nhà cung cấp oauth nào bạn sử dụng). Do đó, nếu bạn đặt samesite = nghiêm ngặt cookie trong phản hồi 302 của mình thì trình duyệt có thể nghĩ "à ha! Đây là một yêu cầu chéo trang web đến từ Google đến trang web của bạn" và do đó không gửi cookie khi yêu cầu url được chuyển hướng. Cách khắc phục là sử dụng meta-refresh như bạn đã thực hiện, vì vậy yêu cầu của bạn đến từ chính trang web của bạn. Tôi có thể đang nói chuyện tào lao, nhưng đó là suy nghĩ hiện tại của tôi.
Đã gặp sự cố này khi sử dụng OpenIdConnect / IdentityServer trên .Net, nơi một API riêng biệt (tên máy chủ khác) xử lý xác thực và chuyển hướng trở lại trang web chính.
Đầu tiên (để phát triển trên localhost), bạn cần đặt CookieSecuretùy chọn thành SameAsRequesthoặc Neverđể đối phó với việc http://localhost/không an toàn. Hãy xem câu trả lời của Michael Freidgeim .
Thứ hai, bạn cần đặt CookieSameSitethuộc tính thành Lax, nếu không, các cookie sẽ không được lưu. Strictkhông hoạt động ở đây!
Trong trường hợp của tôi, tôi đặt CookieOptions.Secure = true, nhưng đã thử nghiệm nó trên http: // localhost ., Và trình duyệt ẩn cookie theo cài đặt.
Để tránh vấn đề như vậy, bạn có thể thực hiện tùy chọn Bảo mật cookie để phù hợp với yêu cầu giao thức.IsHttps, ví dụ:
new CookieOptions()
{
Path = "/",
HttpOnly = true,
Secure = Request.IsHttps,
Expires = expires
}
Set-Cookietiêu đề trên chuyển hướng 302.
secure=request.is_securetrong bình cầu.