Set-Cookie पार्सर

Set-Cookie Parser

विशेषताओं का निरीक्षण करने और जोखिम भरे SameSite / Secure संयोजनों को चिह्नित करने के लिए बहु-पंक्ति Set-Cookie प्रतिक्रिया हेडर पेस्ट करें।

कुकी विशेषता कार्ड

2 Set-Cookie
#1sessionabc123
path/
httponly(फ्लैग)
secure(फ्लैग)
samesiteLax
कोई स्पष्ट विशेषता समस्या नहीं मिली
#2preview1
max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone
secure(फ्लैग)
setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

JSON पूर्वावलोकन

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

जब ब्राउज़र कुकी स्वीकार नहीं करता है, तो अक्सर यह मान गलत होने के कारण नहीं, बल्कि Set-Cookie विशेषताएँ गलत होने के कारण होता है।

संबंधित सुझाव

HTTP कुकी पार्सर

कुकी पार्सर

सिक्योरिटी हेडर चेकर

CORS निरीक्षक

Authentication Header जनरेटर

cURL से कोड जनरेटर

Set-Cookie पार्सर क्या है?

Set-Cookie पार्सर HTTP प्रतिक्रिया हेडर में `Set-Cookie` सामग्री के लिए विशेष रूप से डिज़ाइन किया गया डीबग टूल है। इसका उद्देश्य केवल अर्धविराम के आधार पर टेक्स्ट पंक्ति को अलग करना नहीं है, बल्कि डेवलपर्स को यह निर्धारित करने में मदद करना है: सर्वर से यह कुकी कॉन्फ़िगरेशन सही है या नहीं, ब्राउज़र ने इसे स्वीकार क्यों नहीं किया, कौन से विशेषता संयोजन सुरक्षा या संगतता जोखिम पैदा करते हैं, और क्या वर्तमान Set-Cookie क्रॉस-साइट, SSO, iframe, तृतीय-पक्ष कुकी या सत्र परिदृश्यों के लिए उपयुक्त है।

अनुरोध हेडर में कुकी से भिन्न, Set-Cookie सर्वर द्वारा ब्राउज़र को भेजा गया 'कॉन्फ़िगरेशन कमांड' है। इसमें केवल `name=value` नहीं होता, बल्कि SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned जैसी विशेषताएँ भी होती हैं — ये फ़ील्ड सीधे निर्धारित करती हैं कि ब्राउज़र कुकी लिखेगा या नहीं, यह कब समाप्त होगी, किन पथों और डोमेन पर यह प्रभावी होगी, और क्या इसे क्रॉस-साइट अनुरोधों में भेजा जा सकता है। इसलिए 'सत्र हानि', 'ब्राउज़र कुकी नहीं भेजता', 'क्रॉस-डोमेन परिदृश्य में काम नहीं करता' जैसी कई समस्याओं का मूल कारण स्वयं मान में नहीं, बल्कि Set-Cookie की विशेषता कॉन्फ़िगरेशन में है।

वर्तमान पृष्ठ का मूल्य इन विशेषताओं को मूल प्रतिक्रिया हेडर से संरचित रूप से निकालना है, फिर ब्राउज़र के वास्तविक नियमों के साथ स्थिर जाँच करना है। उदाहरण के लिए, SameSite=None में Secure की कमी है या नहीं, Partitioned Secure के साथ है या नहीं, __Host- उपसर्ग ने गलत तरीके से Domain सेट किया है या नहीं, Max-Age अमान्य है या 0 के बराबर है, Expires में Max-Age की कमी है या नहीं। ब्राउज़र आमतौर पर इन समस्याओं को सिंटैक्स त्रुटि की तरह सीधे प्रदर्शित नहीं करता, बल्कि चुपचाप अस्वीकार करता है या 'काम नहीं करता' के रूप में प्रकट होता है, इसलिए टूल-आधारित जाँच बहुत महत्वपूर्ण है।

यदि आप केवल यह जानना चाहते हैं कि वर्तमान में अनुरोध में कौन सी कुकी भेजी जा रही हैं, तो इस पृष्ठ पर न रुकें — कृपया 'HTTP कुकी पार्सर' पर जाएँ जो अनुरोध हेडर को अलग करने के लिए अधिक उपयुक्त है। वर्तमान पृष्ठ प्रतिक्रिया हेडर जाँच परिदृश्यों के लिए अधिक उपयुक्त है जैसे 'ब्राउज़र ने क्यों नहीं लिखा', 'क्या सर्वर से इस कुकी कॉन्फ़िगरेशन में छिपे जोखिम हैं', 'क्या क्रॉस-साइट विशेषताओं और सुरक्षा विशेषताओं का संयोजन उचित है'।

उपयोग के मामले

  • जब ब्राउज़र कुकी लिखने से इनकार करता है, तो जल्दी से निर्धारित करें कि क्या यह SameSite, Secure, HttpOnly या Path/Domain कॉन्फ़िगरेशन समस्या है
  • तृतीय-पक्ष लॉगिन, SSO, iframe एम्बेडिंग या क्रॉस-साइट अनुरोध परिदृश्यों में, जाँच करें कि SameSite=None Secure के साथ सही तरीके से जुड़ा हुआ है या नहीं
  • सुरक्षा ऑडिट के दौरान, इंटरफ़ेस द्वारा लौटाई गई कुकी की थोक में जाँच करें कि HttpOnly की कमी, SameSite की कमी या उच्च जोखिम वाले विशेषता संयोजन मौजूद हैं या नहीं
  • यह सत्यापित करें कि __Host-/__Secure- उपसर्ग कुकी ब्राउज़र के मजबूत प्रतिबंधों को पूरा करती है या नहीं, चुपचाप अनदेखा किए जाने से बचने के लिए
  • तृतीय-पक्ष विभाजित कुकी समाधान Partitioned Cookie / CHIPS डीबग करते समय, यह पुष्टि करें कि Partitioned और Secure एक साथ घोषित हैं या नहीं
  • वातावरण स्विच करने के बाद सत्र असामान्यताओं के निवारण के लिए विकास, परीक्षण और उत्पादन वातावरण के बीच Set-Cookie प्रतिक्रिया हेडर के अंतर की तुलना करें

उपयोग कैसे करें

  1. ब्राउज़र DevTools, पैकेट कैप्चर टूल या सर्वर लॉग से Set-Cookie प्रतिक्रिया हेडर सामग्री कॉपी करें (बहु-पंक्ति समर्थित)
  2. इनपुट क्षेत्र में पेस्ट करें, टूल स्वचालित रूप से `Set-Cookie:` उपसर्ग हटा देगा और पंक्ति-दर-पंक्ति विश्लेषण करेगा
  3. प्रत्येक कुकी का नाम, मान, URL डिकोड किया गया मान, विशेषता कार्ड और चेतावनी लेबल देखें
  4. मूल हेडर कॉपी करें या JSON पूर्वावलोकन देखें, परिणाम बैकएंड को भेजें, Issue में पेस्ट करें या परीक्षण स्क्रिप्ट में लिखें

विशेषताएं

  • कई Set-Cookie का स्वतंत्र विश्लेषण: प्रत्येक पंक्ति अलग कार्ड में, नाम, मूल मान, URL डिकोड किया गया मान और विशेषताएँ एक-एक करके देखें
  • 14 सामान्य समस्याओं की स्वचालित जाँच: SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, __Host-/__Secure- उपसर्ग और Partitioned जैसे लगातार जोखिम शामिल हैं
  • पूर्ण विशेषता पृथक्करण: SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned फ़ील्ड को संरचित रूप से प्रदर्शित करता है
  • मानव-पठनीय Max-Age रूपांतरण: सेकंड स्वचालित रूप से मिनट, घंटे, दिन में परिवर्तित होते हैं, मैन्युअल रूपांतरण लागत कम करता है
  • बहु-पंक्ति बल्क इनपुट: DevTools या पैकेट कैप्चर टूल से कॉपी किए गए संपूर्ण Set-Cookie प्रतिक्रिया हेडर ब्लॉक को सीधे पेस्ट कर सकते हैं
  • मूल हेडर कॉपी और JSON पूर्वावलोकन: बैकएंड को वापस भेजने के लिए सुविधाजनक, साथ ही दस्तावेज़, Issue, स्क्रिप्ट और परीक्षण केस लिखने के लिए भी सुविधाजनक
  • स्थानीय शून्य अपलोड: संवेदनशील Session, Token और लॉगिन स्थिति कुकी ब्राउज़र में विश्लेषित होती हैं, डिवाइस से बाहर नहीं जाती

Set-Cookie पार्सर कब उपयोग करें और अन्य दो पृष्ठ कब उपयोग करें?

'सर्वर ने क्या कॉन्फ़िगर किया है' और 'अनुरोध में वास्तव में क्या भेजा गया है' स्पष्ट रूप से देखना दो अलग-अलग चीजें हैं, जाँच करते समय भ्रमित न करें।

टूलउपयुक्त इनपुटसबसे उपयुक्तमुख्य लाभ
Set-Cookie पार्सर (वर्तमान पृष्ठ)Set-Cookie प्रतिक्रिया हेडरब्राउज़र कुकी क्यों स्वीकार नहीं करता, क्रॉस-साइट काम क्यों नहीं करता, सुरक्षा विशेषता कॉन्फ़िगरेशन में जोखिम क्यों है का निवारणविशेषता पृथक्करण पूर्ण है और 14 प्रकार की सामान्य कॉन्फ़िगरेशन समस्याओं की स्वचालित जाँच करता है
HTTP कुकी पार्सरकुकी अनुरोध हेडर, document.cookieयह पुष्टि करना कि अनुरोध में वास्तव में कौन सी कुकी भेजी जा रही हैं, क्या मान URL एन्कोड किए गए हैं, क्या डुप्लिकेट नाम हैंअनुरोध हेडर में नाम-मान जोड़े को अलग करने और मानकीकृत आउटपुट पर अधिक केंद्रित हैHTTP कुकी पार्सर खोलें
कुकी पार्सरकुकी स्ट्रिंग और Set-Cookie मिश्रित जाँच परिदृश्यजब आप अपने हाथ में डेटा के स्रोत के बारे में निश्चित नहीं हैं, या एक पृष्ठ पर कुकी / Set-Cookie दो मोड के बीच जल्दी से स्विच करना चाहते हैंकुकी डीबगिंग के लिए मुख्य प्रवेश द्वार की तरह है, और Netscape Cookie File निर्यात का समर्थन करता हैकुकी पार्सर खोलें

Best Practices

पहले निर्धारित करें कि समस्या 'लेखन विफल' में है या 'अनुरोध में नहीं भेजा गया' में

यदि ब्राउज़र कुकी बिल्कुल नहीं लिखता है, तो पहले वर्तमान पृष्ठ देखें; यदि ब्राउज़र ने लिख लिया है लेकिन बाद के अनुरोधों में नहीं भेजता है, तो HTTP कुकी पार्सर के साथ मिलकर जाँच करना आवश्यक है। Set-Cookie और कुकी अनुरोध हेडर दो अलग-अलग चरण हैं।

क्रॉस-साइट परिदृश्यों में पहले SameSite=None और Secure के संयोजन की जाँच करें

SSO, तृतीय-पक्ष लॉगिन, iframe एम्बेडिंग और क्रॉस-डोमेन अनुरोधों में सबसे आम जाल SameSite=None है लेकिन Secure कॉन्फ़िगर नहीं किया गया है। समस्याओं के इस समूह को पहले साफ करें, फिर सर्वर तर्क और ब्राउज़र नीतियों की जाँच करें।

केवल __Host- / __Secure- उपसर्ग वाले नाम को न देखें, प्रतिबंधों की पूर्णता की जाँच करें

कई टीम सोचती हैं कि कुकी नाम में `__Host-` या `__Secure-` उपसर्ग जोड़ने से यह पहले से ही अधिक सुरक्षित हो जाता है, लेकिन यदि Secure, Path=/, Domain जैसी साथ की शर्तें पूरी नहीं होती हैं, तो ब्राउज़र अभी भी लिखने से इनकार कर देगा।

दस्तावेज़ लिखते समय और Issue को पुन: प्रस्तुत करते समय दो सामग्री रखना प्राथमिकता दें: मूल हेडर और JSON

मूल हेडर बैकएंड और संचालन टीम के लिए वास्तविक वापसी मूल्यों की जाँच के लिए उपयुक्त हैं; JSON को Issue, परीक्षण केस और स्क्रिप्ट में आगे की प्रक्रिया के लिए पेस्ट करना उपयुक्त है। दोनों को एक साथ रखना केवल DevTools से स्क्रीनशॉट लेने की तुलना में पुनरुत्पादन और सहयोग के लिए अधिक सुविधाजनक है।

सामान्य प्रश्न

Set-Cookie पार्सर और कुकी अनुरोध हेडर पार्सर में क्या अंतर है?

Set-Cookie पार्सर सर्वर से प्रतिक्रिया हेडर के लिए है, फोकस यह देखने पर है कि 'ब्राउज़र इस कुकी को स्वीकार करेगा या नहीं, क्या विशेषताओं में कोई समस्या है'; कुकी अनुरोध हेडर पार्सर ब्राउज़र द्वारा भेजे जाने वाले अनुरोधों के लिए है, फोकस यह देखने पर है कि 'इस अनुरोध में कौन सी कुकी भेजी जा रही हैं'। यदि आप SameSite, HttpOnly, Secure, Path, Domain, Expires, Max-Age जैसी विशेषता कॉन्फ़िगरेशन समस्याओं का निवारण कर रहे हैं, तो वर्तमान पृष्ठ का प्राथमिकता से उपयोग करें।

HTTP कुकी पार्सर

ब्राउज़र को प्रतिक्रिया मिलने के बावजूद कुकी क्यों नहीं लिखी जाती?

यह वही समस्या है जिसे हल करने के लिए वर्तमान टूल सबसे उपयुक्त है। सामान्य कारणों में SameSite=None को Secure के साथ कॉन्फ़िगर नहीं करना, HTTP पेज पर Secure कुकी सेट करने का प्रयास, __Host- उपसर्ग का उल्लंघन, Partitioned में Secure की कमी, Path या Domain का अनुचित कॉन्फ़िगरेशन, अमान्य Max-Age या सीधे 0 होना, और ब्राउज़र की तृतीय-पक्ष कुकी नीति प्रतिबंध शामिल हैं।

टूल किन सामान्य Set-Cookie जोखिमों की जाँच करेगा?

वर्तमान पृष्ठ स्वचालित रूप से 14 प्रकार की लगातार होने वाली समस्याओं का पता लगाता है, जिनमें SameSite=None में Secure की कमी, अमान्य SameSite मान, Partitioned में Secure की कमी, HttpOnly की कमी, Path की कमी, SameSite की कमी, __Host- उपसर्ग में Secure की कमी, Path=/ नहीं होना, गलत Domain कॉन्फ़िगरेशन, __Secure- उपसर्ग में Secure की कमी, अमान्य Max-Age, Max-Age=0, बिंदु से शुरू होने वाला Domain और Max-Age के बिना Expires शामिल हैं।

SameSite=None को हमेशा Secure के साथ क्यों होना चाहिए?

आधुनिक ब्राउज़र आवश्यकता रखते हैं कि क्रॉस-साइट अनुरोधों में भेजी जा सकने वाली कुकी यदि `SameSite=None` घोषित करती है, तो उसमें `Secure` विशेषता भी होनी चाहिए, अन्यथा ब्राउज़र आमतौर पर सीधे लिखने से इनकार कर देगा। तृतीय-पक्ष लॉगिन, SSO, iframe एम्बेडिंग और क्रॉस-डोमेन अनुरोध डीबगिंग में इस प्रकार की समस्या बहुत आम है।

ब्राउज़र __Host- और __Secure- उपसर्ग वाली कुकी को क्यों अस्वीकार करता है?

`__Host-` और `__Secure-` मजबूत प्रतिबंधों वाले सुरक्षा उपसर्ग हैं। `__Host-` के लिए Secure होना आवश्यक है, Path=/ होना चाहिए और Domain सेट नहीं किया जाना चाहिए; `__Secure-` के लिए कम से कम Secure की आवश्यकता होती है। यदि इन नियमों का उल्लंघन होता है, तो ब्राउज़र सीधे उस कुकी को अनदेखा कर देगा।

Max-Age और Expires को कैसे देखना चाहिए?

Max-Age सेकंड में सापेक्ष समय है, आमतौर पर Expires से उच्च प्राथमिकता होती है; Expires निरपेक्ष समय बिंदु है, जो क्लाइंट की घड़ी पर निर्भर करता है। कई सर्वर Max-Age लिखे बिना केवल Expires लिखते हैं, हालांकि यह काम करता है, लेकिन डीबगिंग के दौरान समय क्षेत्र या सिस्टम समय विसंगति के कारण गलत निष्कर्ष निकालना आसान होता है।

क्या यह टूल क्रॉस-साइट कुकी और तृतीय-पक्ष कुकी समस्याओं के निवारण के लिए उपयुक्त है?

उपयुक्त है। चाहे वह तृतीय-पक्ष लॉगिन, SSO, iframe एम्बेडिंग, क्रॉस-डोमेन इंटरफ़ेस या CHIPS (Partitioned Cookie) परिदृश्य हो, यह टूल आपको SameSite, Secure और Partitioned का संयोजन उचित है या नहीं, यह जल्दी से देखने में मदद कर सकता है।

क्या विश्लेषण परिणाम कॉपी या निर्यात का समर्थन करते हैं?

समर्थन करता है। आप एक क्लिक से मूल Set-Cookie हेडर कॉपी कर सकते हैं, साथ ही संरचित JSON पूर्वावलोकन देख सकते हैं ताकि प्रत्येक कुकी का नाम, मान, विशेषताएँ और चेतावनी परिणाम Issue, दस्तावेज़, परीक्षण स्क्रिप्ट या एकीकरण परीक्षण रिकॉर्ड में पेस्ट किए जा सकें।

क्या मेरी कॉपी की गई Session और Token सर्वर पर अपलोड होंगे?

नहीं। Set-Cookie सामग्री का विश्लेषण, URL डिकोडिंग, विशेषता पृथक्करण और चेतावनी जाँच सभी ब्राउज़र में स्थानीय रूप से की जाती है, संवेदनशील प्रतिक्रिया हेडर सर्वर पर अपलोड नहीं किए जाते हैं।

शब्दकोश

Set-Cookie
HTTP प्रतिक्रिया हेडर, जिसके माध्यम से सर्वर ब्राउज़र को एक कुकी संग्रहीत करने के लिए कहता है। एक प्रतिक्रिया में कई Set-Cookie दिखाई दे सकते हैं, प्रत्येक आमतौर पर एक कुकी से मेल खाता है।
SameSite
विशेषता जो नियंत्रित करती है कि क्रॉस-साइट अनुरोधों में कुकी भेजी जाए या नहीं। सामान्य मान Strict, Lax, None हैं; जिनमें None के लिए आमतौर पर एक साथ Secure सेट करने की आवश्यकता होती है।
HttpOnly
सेट होने पर फ्रंटएंड JavaScript document.cookie के माध्यम से इस कुकी को नहीं पढ़ सकता है, मुख्य रूप से XSS के माध्यम से सत्र चोरी के जोखिम को कम करने के लिए उपयोग किया जाता है।
Secure
सेट होने पर ब्राउज़र इस कुकी को केवल HTTPS कनेक्शन (या localhost अपवाद) में भेजता है, संवेदनशील कुकी को अनएन्क्रिप्टेड HTTP में उजागर होने से बचाता है।
Max-Age
सेकंड में कुकी का सापेक्ष जीवनकाल। आमतौर पर Expires से उच्च प्राथमिकता होती है, सर्वर पर स्पष्ट रूप से सेट करने की अनुशंसा की जाती है।
Expires
कुकी का निरपेक्ष समाप्ति समय, क्लाइंट के स्थानीय समय पर निर्भर करता है। अकेले उपयोग किए जाने पर डीबगिंग लागत आमतौर पर Max-Age से अधिक होती है।
Path
URL पथ उपसर्ग को सीमित करता है जिस पर कुकी प्रभावी होती है। Path मेल नहीं खाने पर, भले ही कुकी लिखी गई हो, बाद के अनुरोधों में इसे नहीं भेजा जाएगा।
Domain
डोमेन सीमा को सीमित करता है जिस पर कुकी प्रभावी होती है। सेट नहीं होने पर आमतौर पर केवल वर्तमान होस्ट तक सीमित होती है; सेट होने पर उपडोमेन पर प्रभाव डाल सकती है।
Partitioned (CHIPS)
तृतीय-पक्ष कुकी के लिए विभाजित संग्रहण समाधान, ब्राउज़र द्वारा तृतीय-पक्ष कुकी पर नियमों को धीरे-धीरे सख्त करने के बाद वैकल्पिक मार्ग के रूप में अक्सर उपयोग किया जाता है। वर्तमान कार्यान्वयन के लिए आमतौर पर Secure के साथ होना आवश्यक है।
__Host- / __Secure- उपसर्ग
ब्राउज़र द्वारा समर्थित उच्च सुरक्षा कुकी नामकरण उपसर्ग, जिनमें मजबूत प्रतिबंध नियम होते हैं। नियमों का उल्लंघन होने पर ब्राउज़र संबंधित कुकी को स्वीकार करने से इनकार कर देगा।

तीन SameSite रणनीतियों की तुलना त्वरित संदर्भ तालिका

क्रॉस-साइट कुकी की जाँच करते समय, पहले SameSite के व्यवहार सीमाएँ देखें, फिर जाँच करें कि Secure की कमी है या नहीं।

SameSite मानक्रॉस-साइट शीर्ष नेविगेशन (GET)क्रॉस-साइट उप-संसाधन (img/iframe/script)क्रॉस-साइट POST फ़ॉर्मक्रॉस-साइट XHR/fetchक्या Secure आवश्यक है
Strictनहीं भेजा जातानहीं भेजा जातानहीं भेजा जातानहीं भेजा जातानहीं
Lax (डिफ़ॉल्ट)भेजा जाता हैनहीं भेजा जातानहीं भेजा जातानहीं भेजा जातानहीं
Noneभेजा जाता हैभेजा जाता हैभेजा जाता हैभेजा जाता हैSecure सेट करना आवश्यक है

Set-Cookie डीबगिंग लगातार समस्या तुलना तालिका

जब ब्राउज़र चुपचाप कुकी अस्वीकार करता है, तो पहले नीचे दिए गए दिशाओं के अनुसार जाँच करें, आमतौर पर प्रतिक्रिया बॉडी को देखने से तेज़ होता है।

लक्षणउच्च संभावना कारणपहले जाँच करें
ब्राउज़र कुकी बिल्कुल नहीं लिखताSameSite=None में Secure की कमी, उपसर्ग का उल्लंघन, या अमान्य विशेषता संयोजनपहले वर्तमान पृष्ठ पर चेतावनी लेबल और विशेषता कार्ड देखें
क्रॉस-साइट / iframe परिदृश्य में काम नहीं करताSameSite बहुत सख्त, Secure की कमी, या तृतीय-पक्ष नीति प्रतिबंधSameSite, Secure, Partitioned पर ध्यान केंद्रित करें
कुकी लिखते ही समाप्त हो जाती हैMax-Age=0, अमान्य Max-Age, Expires समय के साथ समस्यापहले Max-Age देखें, फिर Expires देखें
__Host- / __Secure- कुकी काम नहीं करतीSecure, Path=/ या Domain प्रतिबंध पूरे नहीं हुएजाँच करें कि उपसर्ग चेतावनी ट्रिगर हुई है या नहीं
विकास वातावरण सामान्य है, उत्पादन वातावरण असामान्यHTTPS, Domain, Path, SameSite या प्रॉक्सी स्तर पर प्रतिक्रिया अंतरमूल हेडर कॉपी करें, विभिन्न वातावरणों में Set-Cookie प्रतिक्रियाओं की तुलना करें

Privacy & Security

Set-Cookie प्रतिक्रिया हेडर का विश्लेषण, URL डिकोडिंग, विशेषता पृथक्करण और 14 प्रकार की चेतावनी जाँच सभी ब्राउज़र में पूरी तरह से स्थानीय रूप से की जाती है। पेस्ट की गई Session, Token और लॉगिन सत्र कुकी किसी भी सर्वर पर अपलोड नहीं की जाती हैं।