क्या 302 रीडायरेक्ट के दौरान कुकी वापस भेजने के साथ कोई समस्या है? उदाहरण के लिए, यदि मैं एक रिटर्न-टू-यूरल कुकी बनाता हूं और उपयोगकर्ता को उसी प्रतिक्रिया में पुनर्निर्देशित करूंगा, तो क्या कोई (आधुनिक) ब्राउज़र कुकी को अनदेखा करेगा?
जवाबों:
अधिकांश ब्राउज़र 302 रीडायरेक्ट पर कुकीज़ स्वीकार कर रहे हैं। मुझे उस पर पूरा यकीन था, लेकिन मैंने थोड़ी खोज की। सभी आधुनिक ब्राउज़र नहीं। इंटरनेट संग्रह लिंक अब हटाए गए / मृत / Microsoft से कनेक्ट करें सिल्वरलाइट क्लाइंट पर क्यू / ए कनेक्ट करें 302 रीडायरेक्ट रिस्पॉन्स (2010) पर HTTP- स्टैक सेट-कुकी को अनदेखा करता है
मुझे लगता है कि अब हमारे पास IE6 के लिए एक प्रतिस्थापन है और यह विंडोज़ मोबाइल ब्राउज़र है ...
इस ब्लॉग पोस्ट के अनुसार: http://blog.dubbelboer.com/2012/11/25/302-cookie.html सभी प्रमुख ब्राउज़र, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), ओपेरा (12.11) दोनों विंडोज और मैक पर, रीडायरेक्ट पर कुकीज़ सेट करते हैं। यह 301 और 302 रीडायरेक्ट दोनों के लिए सही है।
एक सूचना (डेवलपर के जीवन को बचाने के लिए):
जब कुकी का डोमेन लोकलहोस्ट हो, तो IE और Edge, रेडी-रिस्पॉन्स में सेट-कुकी की अनदेखी कर रहे हैं ।
समाधान:
लोकलहोस्ट के बजाय 127.0.0.1 का उपयोग करें ।
यहाँ इस मुद्दे के लिए क्रोमियम बग है (स्थिति 302 के साथ HTTP प्रतिक्रिया के लिए सेट-कुकी को अनदेखा किया गया)।
यह वास्तव में दृष्टिकोण पर आधारित है, लेकिन अगर आप वास्तव में 30x सेट-कुकी ब्राउज़र व्यवहार पर भरोसा नहीं करना चाहते हैं तो आप कुकी सेट करते समय HTML meta http-equiv="refresh""पुनर्निर्देशन" का उपयोग कर सकते हैं । उदाहरण के लिए, 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>
सर्वर एक उचित 300x रीडायरेक्ट के बजाय 200 के साथ सेट-कुकी भेजेगा, इसलिए ब्राउज़र कुकी को स्टोर करेगा, और फिर "रीडायरेक्ट" करेगा। यह <a>लिंक एक स्थिति में है जब ब्राउज़र मेटा रिफ्रेश नहीं करता है।
मैं सिर्फ फ़ायरफ़ॉक्स और सफारी दोनों के साथ इस समस्या में भाग गया, लेकिन क्रोम नहीं। मेरे परीक्षण से, यह केवल तब होता है जब डोमेन रीडायरेक्ट के दौरान बदल जाता है। यह OAuth2 प्रवाह में विशिष्ट है:
जिन कारणों से मुझे अभी तक पता नहीं चला है, अनुरोध 2 से कुछ कुकीज़ को अनदेखा कर दिया जाता है जबकि अन्य नहीं। हालाँकि, यदि अनुरोध 2 एक HTTP 200 को Refreshहेडर ("मेटा रिफ्रेश" रीडायरेक्ट) के साथ लौटाता है, तो कुकी अनुरोध 3 से ठीक से सेट हो जाती हैं।
samesite=strict। कॉलबैक अनुरोध के लिए ब्राउज़र अभी भी सोचता है कि प्रवर्तक Google है (या जो भी आप उपयोग करते हैं प्रदाता)। इसलिए यदि आप अपनी 302 प्रतिक्रिया में एक samesite = सख्त कुकी सेट करते हैं तो ब्राउज़र शायद "आह हा! यह Google से आपकी साइट पर आने वाला एक क्रॉस-साइट अनुरोध है" और इसलिए रीडायरेक्ट किए गए url का अनुरोध करते समय कुकी नहीं भेजता है। यह ठीक है कि आपने जो किया है, वह मेटा-रिफ्रेश का उपयोग करे, इसलिए आपका अनुरोध आपकी अपनी साइट से आता है। मैं बकवास बोल सकता हूं, लेकिन यह मेरी मौजूदा सोच है।
.Net पर OpenIdConnect / IdentityServer का उपयोग करते समय इस समस्या का सामना किया, जहां एक अलग API (अलग होस्टनाम) प्रमाणीकरण को संभालता है और मुख्य साइट पर वापस रीडायरेक्ट करता है।
सबसे पहले (स्थानीय होस्ट पर विकास के लिए) आप सेट करने की जरूरत CookieSecureकरने के लिए विकल्प SameAsRequestया Neverसे निपटने के लिए http://localhost/सुरक्षित नहीं किया जा रहा। देखें माइकल फ्रीजिम का जवाब।
दूसरा, आपको CookieSameSiteविशेषता सेट करने की आवश्यकता है Lax, अन्यथा कुकीज़ बिल्कुल भी नहीं बचती हैं। Strictयहाँ काम नहीं करता है!
मेरे मामले में मैंने CookieOptions.Secure = true सेट किया है, लेकिन सेटिंग के अनुसार इसे http: // localhost । और ब्राउज़र पर कुकीज़ छिपाएँ।
ऐसी समस्या से बचने के लिए, आप प्रोटोकॉल अनुरोध मैच के लिए कुकी सुरक्षित विकल्प बना सकते हैं। उदाहरण के लिए, उदाहरण के लिए
new CookieOptions()
{
Path = "/",
HttpOnly = true,
Secure = Request.IsHttps,
Expires = expires
}
Set-Cookieहालांकि यह सभी 302 रीडायरेक्ट पर हेडर के साथ क्या करते हैं, यह ऑर्थोगोनल है ।
secure=request.is_secureफ्लास्क में उपयोग करें ।