एजेंट कुकी जार उन सेशन को कैसे बनाए रखते हैं जिन्हें आपने नहीं चाहा

HTTP क्लाइंट कुकी को बेअसर लगने देते हैं, क्योंकि ब्राउज़र ने हमें उनसे यही उम्मीद करना सिखाया है। स्वायत्त एजेंट के साथ इसका असर बदल जाता है। Set-Cookie वाली प्रतिक्रिया अगले अनुरोध को ऐसी अनुमति दे सकती है जिसे एजेंट ने न मांगा, न दिखाया, और मूल क्रेडेंशियल बदलने के बाद भी अपने पास रख सकता है।

कुकी जार को ट्रांसपोर्ट की बारीकी नहीं, प्रमाणीकरण स्टोर मानें। यदि किसी API को कुकी सेशन चाहिए, तो जार का नामित मालिक, कम उम्र और दिखाई देने वाली सीमा तय करें। जरूरत न हो तो इसे बंद कर दें। बहुत-सी घटना जांचों में मैंने किसी को यह कहते देखा है कि अनुरोध में कोई क्रेडेंशियल नहीं था, जबकि क्लाइंट चुपचाप Cookie हेडर में उसे भेज रहा था।

Set-Cookie हेडर दूसरा क्रेडेंशियल बन सकता है

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

टीमें इसे अक्सर इसलिए नहीं पकड़ पातीं क्योंकि उनका ध्यान उस सीक्रेट पर होता है जो उन्होंने जानबूझकर दिया था: bearer टोकन, basic-auth पासवर्ड या signed request। वे देखते हैं कि वह सीक्रेट कहां से आया और एजेंट तक पहुंचता है या नहीं। फिर HTTP लाइब्रेरी बिना ऐप्लिकेशन कोड की किसी स्पष्ट पंक्ति के सेशन कुकी स्वीकार कर लेती है। मूल Authorization हेडर हट जाने के बाद भी अगला अनुरोध सफल हो सकता है।

असल फर्क क्रेडेंशियल इंजेक्शन और सेशन जारी रखने में है। क्रेडेंशियल इंजेक्शन किसी ज्ञात सीक्रेट को एक अनुरोध के साथ जोड़ता है। सेशन जारी रखना सर्वर को नया सीक्रेट जारी करने देता है और क्लाइंट से उसे बाद में फिर भेजने को कहता है। दोनों से काम अधिकृत हो सकता है। आम तौर पर इनमें से सिर्फ एक टूल के कॉल आर्ग्युमेंट में दिखाई देता है।

RFC 6265 इस लेन-देन को स्टेट मैनेजमेंट कहता है: user agent Set-Cookie से कुकी जानकारी रखता है और लागू कुकी को Cookie में लौटाता है। भाषा जानबूझकर व्यापक है, क्योंकि वेब ब्राउज़र को इसकी जरूरत होती है। HTTP प्रोटोकॉल अनुमति देता है, सिर्फ इसलिए एजेंट क्लाइंट को ब्राउज़र की तरह स्टेट रखने की आदत नहीं अपनानी चाहिए।

कुकी असफल टोकन रोटेशन का अर्थ भी बदल देती है। मान लें कि एजेंट टोकन के साथ API को कॉल करता है, sid=... पाता है और बाद में उस टोकन तक पहुंच खो देता है। यदि API अकेली सेशन कुकी स्वीकार करता है, तो एजेंट के पास खाते तक पहुंच का रास्ता बना रहता है। रोटेशन ने ज्ञात क्रेडेंशियल तो बदल दिया, जारी सेशन खत्म नहीं किया। यह सर्वर-साइड सेशन मैनेजमेंट और क्लाइंट-साइड नियंत्रण, दोनों का सवाल है। दोनों को संभालना होगा।

छिपा हुआ स्टेट होगा या नहीं, यह क्लाइंट तय करता है

Set-Cookie अकेले कुछ नहीं करता। क्लाइंट को उसे रखने का चुनाव करना पड़ता है। यह चुनाव कई अप्रत्याशित जगहों पर छिपा हो सकता है: दोबारा इस्तेमाल होने वाला HTTP क्लाइंट, लाइब्रेरी का कुकी मैनेजर, fetch का wrapper, टेस्ट harness या redirect implementation।

कुछ सामान्य क्लाइंट तब तक कुकी नहीं रखते, जब तक आप उन्हें जार न दें। कुछ में कोड standard cookie handler जोड़ने पर वे रखी जाती हैं। फिर shared client अनजाने में shared jar बना सकता है। API दस्तावेज़ देखकर या कॉल सफल होने के आधार पर व्यवहार का अनुमान न लगाएं। क्लाइंट के निर्माण को जांचें और एक probe चलाएं।

साफ परीक्षण के लिए अपना सर्वर या हानिरहित टेस्ट endpoint लें। पहली प्रतिक्रिया में साफ नाम वाली कुकी सेट होनी चाहिए और दूसरा अनुरोध उसे मिले हेडर रिपोर्ट करे। नतीजे में दो अलग सवालों का उत्तर होना चाहिए:

1. क्या Set-Cookie मिलने के बाद क्लाइंट ने कुकी रखी?
2. क्या क्लाइंट ने बाद के योग्य अनुरोध के साथ वह कुकी भेजी?

curl के साथ स्पष्ट cookie file स्टेट को दिखाती है:

curl -i -c /tmp/agent-cookie-test.txt https://test.example/session/start
HTTP/1.1 200 OK
Set-Cookie: agent_probe=run-7f3; Path=/; Secure; HttpOnly

curl -i -b /tmp/agent-cookie-test.txt https://test.example/session/echo
HTTP/1.1 200 OK

{"received_cookie":"agent_probe=run-7f3"}

फाइल ही इस अभ्यास का मुख्य बिंदु है। पहला कमांड छिपी हुई सेशन नहीं बना सकता, जब तक कोई उसकी प्रतिक्रिया न रखे। दूसरा उसे फिर से नहीं भेज सकता, जब तक उसे फाइल न मिले। यदि आपके एजेंट टूल में इस फाइल के समकक्ष चीज का कोई नामरहित, process-global ठिकाना है, तो आपने ऐसी सेशन सीमा बना दी है जिसे समीक्षा के दौरान कोई समझ नहीं सकता।

अपने एजेंट के सटीक runtime path से फिर probe चलाएं, जिसमें request wrapper और redirect setting भी शामिल हों। सीधा curl परीक्षण curl को साबित करता है, आपके टूल को नहीं। लिखें कि जार खाली शुरू होता है या नहीं, वह कहां रहता है और उसे क्या साफ करता है।

कॉल के बीच दोबारा उपयोग और रन के बीच दोबारा उपयोग अलग हैं

एक टास्क की कुछ कॉल को एक सेशन साझा करना पड़ सकता है। बाद के टास्क में उसी सेशन का उपयोग अलग फैसला है। इन दोनों अवधियों को मिला देने पर छोटी सुविधा स्थायी अनुमति बन जाती है।

व्यवहार का आकलन करते समय तीन सीमाएं अपनाएं। पहले पूछें कि एक अनुरोध को कुकी चाहिए भी या नहीं। फिर पूछें कि एक एजेंट प्रोसेस में संबंधित कॉल को उनकी जरूरत है या नहीं। तीसरे, पूछें कि नया प्रोसेस, फिर से शुरू हुआ टास्क, दूसरा क्रेडेंशियल या दूसरा व्यक्ति उन्हें कभी विरासत में ले सकता है या नहीं। हर हां के पीछे स्पष्ट कारण होना चाहिए।

प्रोसेस के साथ गायब हो जाने वाला in-memory jar, प्रोजेक्ट डायरेक्टरी की फाइल से नियंत्रित करना आसान है। फाइल crash, retry, कॉपी किए हुए workspace या टास्क चलाने वाले व्यक्ति के बदलने के बाद भी रह सकती है। वह support archive या source-control status output में भी पहुंच सकती है। HttpOnly उस क्लाइंट से कुकी फाइल को नहीं बचाता जिसने उसे लिखा था, वह बस browser script की पहुंच सीमित करता है।

मुझे हर एजेंट रन के लिए नया जार पसंद है, तब भी जब उसी मॉडल को follow-up prompt मिले। मॉडल की बातचीत की निरंतरता HTTP अनुमति रखने का कारण नहीं है। यदि follow-up को सचमुच सेशन चाहिए, तो पिछले रन की उपयोगी सेशन चुपचाप छोड़ देने के बजाय ऑपरेटर से उसी नामित सीमा में जारी रन की मंजूरी लें।

Concurrent कॉल के लिए भी अलग फैसला चाहिए। साझा जार क्रम पर निर्भर व्यवहार पैदा कर सकता है: अनुरोध A को कुकी मिलती है, अनुरोध B कुछ क्षण बाद शुरू होता है और B को ऐसी सेशन मिल जाती है जो उसने कभी बनाई ही नहीं। इससे समस्या दोहराना बेहद कठिन होता है। जब तक API को समन्वित सेशन की जरूरत न हो और टास्क का उस पर स्पष्ट अधिकार न हो, concurrent टास्क को अलग जार दें।

कुकी की scope उतनी सुरक्षा नहीं देती जितनी लोग सोचते हैं

कुकी एट्रिब्यूट डिलीवरी सीमित करते हैं, पर सेशन को बेअसर नहीं बनाते। इन्हें सर्वर से क्लाइंट को भेजे गए रूटिंग निर्देश समझें, फिर तय करें कि क्लाइंट को इन्हें मानना भी चाहिए या नहीं।

Host-only कुकी ठीक उसी होस्ट को लौटती है जिसने उसे जारी किया था। Domain=example.com वाली कुकी api.example.com और admin.example.com जैसे योग्य subdomain को लौट सकती है। RFC 6265 यह भी कहता है कि user agent ऐसा Domain मान अस्वीकार करता है जो origin host से domain-match न हो। फिर भी बड़े corporate domain के हर subdomain पर भरोसा करने की सामान्य गलती इससे नहीं रुकती।

Path=/billing कुकी को उन अनुरोधों तक सीमित करता है जिनके path कुकी path से मेल खाते हैं। यदि सर्वर को किसी दूसरे route से वही कुकी मिलती है, तो यह उसे स्वीकार करने से नहीं रोकता और न ही authorization check का विकल्प है। डिज़ाइन चर्चा में Path को सुरक्षा सीमा न मानें। यह क्लाइंट के भेजने का नियम है।

Secure क्लाइंट से कहता है कि कुकी केवल सुरक्षित ट्रांसपोर्ट पर भेजे। HttpOnly ब्राउज़र से कहता है कि उसे script API से बाहर रखे। दोनों अच्छी सफाई के उपाय हैं, लेकिन कोई भी कुकी को रखने, टास्क के बीच साझा करने, redirect या एजेंट द्वारा उसके इस्तेमाल को सीमित नहीं करता। SameSite मुख्यतः ब्राउज़र के site context को नियंत्रित करता है। गैर-ब्राउज़र एजेंट इसे cross-site व्यवहार के सुरक्षित होने का प्रमाण न माने।

डिबगिंग के दौरान raw header लॉग करना एक और आसान गलती है। Authorization हटाकर Cookie छोड़ देने वाला redactor प्रमाणीकरण नहीं छिपाता। जरूरत हो तो कुकी की मौजूदगी, उसका नाम, घोषित Domain और Path, expiry type और nonreversible correlation identifier लॉग करें। उसका मान लॉग न करें।

Redirect कुकी परीक्षण को गंतव्य परीक्षण बना देते हैं

Redirect केवल अलग URL नहीं है। वह बदल सकता है कि अगला अनुरोध किस सर्वर को दिखेगा, क्रेडेंशियल रखे जाएंगे या नहीं और किस प्रतिक्रिया को स्टेट सेट करने का मौका मिलेगा। इसे अलग flow की तरह जांचें।

उस endpoint से शुरू करें जो कुकी सेट करने के बाद redirect लौटाता हो। फिर हर गंतव्य को अलग जांचें: वही host, अनुमत subdomain, sibling subdomain और असंबंधित host। बाहर जाते Cookie और Authorization, दोनों देखें। अलग HTTP stack अलग फैसले लेते हैं और wrapper default को बदल सकता है।

एक उपयोगी fixture ऐसा छोटा trace देता है:

request 1  GET https://api.example.test/start
response 1  302 Location: https://api.example.test/next
            Set-Cookie: probe=A; Path=/; Secure
request 2  GET https://api.example.test/next
            Cookie: probe=A
response 2  200

फिर केवल Location host बदलें। यदि api.example.test, reports.example.test पर redirect करता है, तो host-only कुकी को साथ नहीं जाना चाहिए। Domain-scoped कुकी जा सकती है। परीक्षण चलने से पहले अपेक्षित नतीजा लिखें, क्योंकि चौंकाने वाला trace ही मुख्य बात है, उसे ढक देना नहीं।

जब API अनुबंध में जरूरत न हो तो cross-origin redirect अस्वीकार करें। यदि उन्हें follow करना अनिवार्य हो, तो पुराने और नए origin की तुलना करें, स्पष्ट नियम के अनुसार अनुरोध क्रेडेंशियल हटाएं और नई प्रतिक्रिया को नया cookie state बनाने दें। व्यापक automatic redirect policy का उपयोग करके यह न मानें कि cookie scope आपको बचा लेगी।

सेशन परीक्षण को क्रेडेंशियल और प्रोसेस, दोनों पार करने चाहिए

महंगी गलती पकड़ने वाला परीक्षण request one, request two नहीं है। वह उन सीमाओं को पार करता है जिन्हें आपका operating model लागू करने का दावा करता है।

ऐसा हानिरहित endpoint बनाएं जो चुना गया credential label मिलने के बाद ही कुकी जारी करे। हर अधिकृत अनुरोध पर वह session label लौटाए। फिर यह क्रम चलाएं:

1. क्रेडेंशियल A के साथ run A शुरू करें और sid=A पाएं।
2. क्रेडेंशियल A के बिना, लेकिन उसी जार के साथ दूसरी कॉल करें।
3. क्रेडेंशियल B और खाली जार के साथ run B शुरू करें।
4. बिना क्रेडेंशियल और run A के किसी भी persisted jar के साथ run C शुरू करें।
5. क्रेडेंशियल A रद्द करें या टेस्ट सर्वर पर उसकी सेशन अमान्य करें, फिर run A के जार को दोबारा आजमाएं।

अपेक्षित आउटपुट कोई सार्वभौमिक उत्तर नहीं, नीति का निर्णय है। कुकी-आधारित API जानबूझकर run A के भीतर दूसरी कॉल को अनुमति दे सकती है। Run B को A का स्टेट नहीं दिखना चाहिए। जब तक आपने persistence की स्पष्ट मंजूरी न दी हो, run C विफल होना चाहिए। यदि आपके threat model में टोकन रोटेशन से सक्रिय पहुंच हटनी चाहिए, तो रद्द करने के बाद टेस्ट सर्वर को पुरानी सेशन अस्वीकार करनी चाहिए।

अपेक्षा को डेवलपर की याददाश्त में दफनाने के बजाय टेस्ट के पास लिखें। टेस्ट comment में छोटी तालिका काम करती है:

run A, same jar, no bearer header: allowed only if session continuation is intended
run B, fresh jar, credential B: must identify as B
run C, persisted jar, no credential: rejected
run A after session invalidation: rejected

इससे वह अंतर सामने आता है जिसे टीमें अक्सर मिला देती हैं: bootstrap क्रेडेंशियल रद्द करना और जारी सेशन रद्द करना एक ही काम नहीं है। API owner को सेशन अमान्य करनी होती है। एजेंट टूल owner को उन्हें मंजूर उम्र से आगे बचाकर रखने से रोकना होता है। कोई भी पक्ष मानकर नहीं चल सकता कि दूसरे ने यह संभाल लिया।

API को जरूरत न हो तो implicit jar बंद रखें

एजेंट HTTP कार्रवाई के लिए समझदारी भरा डिफ़ॉल्ट है: कुकी स्टोरेज नहीं और automatic Cookie हेडर नहीं। प्रतिक्रिया में फिर भी Set-Cookie हो सकता है। यदि आपका audit design अनुमति दे तो यह दर्ज करें कि ऐसा हुआ था, फिर उसे छोड़ दें। अगली कॉल में API को अपना सामान्य अनुरोध क्रेडेंशियल इस्तेमाल करना चाहिए।

यह सुझाव इसलिए अलोकप्रिय है क्योंकि कई web-adjacent API login endpoint के बाद तभी काम करते हैं जब क्लाइंट कुकी रखे। लोग shared jar की ओर जाते हैं क्योंकि उससे demo और integration test पास हो जाते हैं। जब documented API bearer token या दूसरा request-scoped तंत्र देती हो, तो यह गलत समाधान है। आप ऐसे integration path की भरपाई के लिए अदृश्य अनुमति रख रहे हैं जिसे आपको चुनना ही नहीं चाहिए था।

यदि API को सचमुच कुकी चाहिए, तो जार को स्पष्ट capability बनाएं। कॉलर रन शुरू होने पर नामित, खाली जार चुने। टूल बताए कि प्रतिक्रिया से कुकी बनी या बदली और जार अंत में गायब हो जाए। केवल हेडर लौटाकर किसी endpoint को हर एजेंट के लिए स्थायी सेशन चुनने न दें।

छोटी-सी नीति इतनी सरल हो सकती है कि उसकी समीक्षा हो सके:

cookie mode: disabled by default
allowed mode: ephemeral per agent run
persistence: prohibited
sharing: prohibited between agent processes
redirects: same-origin only unless the action definition permits another origin
logging: record cookie names and scope, never values

यह जानबूझकर rules engine से कम चतुर है। चतुर cookie policy में अपवाद बढ़ते जाते हैं, जब तक कोई यह न बता सके कि कौन-सी कार्रवाई कौन-सा स्टेट ले जा रही है। कुछ सीमित विकल्प समीक्षकों को वास्तविक उत्तर देते हैं।

सिर्फ अनुरोध नहीं, स्टेट ट्रांज़िशन का ऑडिट करें

URLs और status code की सूची वाला audit trail सबसे उपयोगी घटना छोड़ देगा: प्रतिक्रिया ने बदल दिया कि बाद की कॉल क्या कर सकती हैं। सेशन सीक्रेट रखे बिना cookie state परिवर्तन को प्रथम श्रेणी की घटना की तरह रिकॉर्ड करें।

हर HTTP कार्रवाई के रिकॉर्ड से यह पता चलना चाहिए: क्या अनुरोध ने कुकी भेजी, क्या प्रतिक्रिया ने कोई कुकी सेट या साफ की, उन्हें किस जार ने पाया, क्या जार इसी रन का था और क्या redirect हुआ। निदान के लिए कुकी का नाम और एट्रिब्यूट आम तौर पर काफी होते हैं। मान केवल तब रखें जब उन्हें सुरक्षित रखने और समाप्त करने का ठोस सुरक्षा डिज़ाइन हो, जिसकी अधिकांश एजेंट टूल को जरूरत नहीं होती।

जब एजेंट HTTP कार्रवाई के लिए Sallyport इस्तेमाल करता है, तो कार्रवाई चलने के दौरान vault कॉन्फ़िगर किया हुआ API क्रेडेंशियल एजेंट से दूर रख सकता है। यह अलगाव तभी उपयोगी है जब HTTP क्लाइंट वापस आए किसी भी session state को उसी संदेह से देखे, उसे चुपचाप दूसरे क्रेडेंशियल path में न बदल दे।

Audit record में मनुष्यों के समझने योग्य रन सीमा भी चाहिए। यदि ऑपरेटर एजेंट रन रद्द करे, तो उसे पता होना चाहिए कि इससे सिर्फ कॉन्फ़िगर किए क्रेडेंशियल के जरिए होने वाली आगे की कॉल रुकती हैं, या रन से जुड़ा session state भी साफ होता है। यदि साफ नहीं होता, तो साफ-साफ बताएं और बाकी स्टेट को बाद के प्रोसेस के लिए पहुंच से बाहर रखें।

मैं जो पहला टेस्ट जोड़ूंगा वह जानबूझकर साधारण है: एक endpoint Set-Cookie भेजता है, अगला पुष्टि करता है कि वह पहुंची या नहीं और नया एजेंट प्रोसेस कॉल दोहराता है। Retry, redirect, browser compatibility या persistent cache जोड़ने से पहले इसे चलाएं। यदि trace से उत्तर साफ नहीं है, तो आपके क्लाइंट के पास उसके interface के बताए अधिकार से अधिक अनुमति है।

API लेखक अनुमान लगाए बिना एजेंट को सुरक्षित बना सकते हैं

API लेखकों को दस्तावेज़ में बताना चाहिए कि कुकी जरूरी हैं या नहीं, उन्हें क्या बनाता है, उनकी तय उम्र क्या है और क्लाइंट उन्हें कैसे अमान्य करते हैं। जब login उस क्रेडेंशियल से लंबे समय तक रहने वाली सेशन जारी कर सकता है जिससे वह मिली थी, तो केवल इतना कहना कि "login के बाद इस endpoint का उपयोग करें" काफी नहीं है।

जहां संभव हो, request-scoped विकल्प दें। Bearer authentication, signed request या सीमित scope वाला action token अक्सर क्लाइंट व्यवहार का ऑडिट आसान बनाता है क्योंकि हर कॉल अपना अधिकार खुलकर रखती है। इससे ये तंत्र अपने आप सुरक्षित नहीं हो जाते, लेकिन क्लाइंट मेमोरी में छिपा एक अतिरिक्त replay channel नहीं बनता।

यदि आप session cookie जारी करते हैं, तो session invalidation काम करे और उसका परीक्षण करें। Session invalidation के बिना token rotation ऑपरेटर को पूरा काम हो जाने का परेशान करने वाला झूठा भरोसा देता है। यदि आप bearer token और session cookie, दोनों स्वीकार करते हैं, तो उनके असहमत होने पर कौन प्राथमिक होगा यह तय करें और diagnostic output में वह चयन दिखाएं।

एजेंट बनाने वालों को ब्राउज़र की नकल करने के लिए न कहें, जब तक आपकी सेवा सचमुच browser behavior पर निर्भर न हो। एजेंट बार-बार, बिना निगरानी कॉल करते हैं और अक्सर अलग-अलग टास्क के बीच काम करते हैं। ब्राउज़र का लंबे समय तक रहने वाला सुविधा स्टेट इस वातावरण का खराब डिफ़ॉल्ट है।

सुरक्षित डिफ़ॉल्ट है नया क्लाइंट, बिना याद रखी सेशन के

Cookie support खराब नहीं है, बिना मालिक का स्टेट खराब है। कम समय वाला, साफ तौर पर चुना गया जार कई कॉल वाले API टास्क को पूरा करने का सही तरीका हो सकता है। HTTP client दोबारा इस्तेमाल करने से पैदा हुआ जार सही retry, redirect या credential rotation का इंतजार करती दुर्घटना है।

टूल interface और audit record में session boundary साफ दिखाएं। फिर cross-run test से इसे साबित करें। अनुरोध trace देखकर समीक्षक एजेंट के हर credential path की ओर इशारा कर सके, उनमें वे path भी शामिल हों जिन्हें सर्वर वापस देने की कोशिश करता है।