प्रॉम्प्ट और लागू संदर्भ
एक ऑफलाइन-फर्स्ट साइट को Service Worker में लॉगिन-कुकी परिवर्तनों को पहचानना चाहिए और अपनी कैश नीति को अपडेट करना चाहिए। सदस्यता स्कोप, इवेंट सेमेंटिक्स, रेस कंडीशन्स और असमर्थित ब्राउज़रों के लिए फॉलबैक को कवर करते हुए एक Cookie Store API दृष्टिकोण डिज़ाइन करें।
Cookie Store API एसिंक्रोनस कुकी रीड्स और राइट्स प्रदान करता है और Service Workers को संबंधित कुकी परिवर्तनों को सब्सक्राइब करने की अनुमति देता है। यह ब्लॉकिंग document.cookie का एक विकल्प है, लेकिन यह same-origin, path, Secure, HttpOnly या SameSite बाधाओं को नहीं बदलता है।
इंटरव्यूअर क्या मूल्यांकन करता है
पेज API और Service Worker सब्सक्रिप्शन API के बीच अंतर, यह तथ्य कि cookiechange केवल स्क्रिप्ट-दृश्यमान परिवर्तनों से संबंधित है, नाम और URL फ़िल्टरिंग, डुप्लिकेट सब्सक्रिप्शन, इवेंट रेस और कुकीज़ क्रॉस-कॉन्टेक्स्ट विश्वसनीय डेटाबेस क्यों नहीं हैं, इसे कवर करें।
स्पष्टीकरण के लिए प्रश्न
पुष्टि करें कि क्या कुकी HttpOnly है, क्या इसका स्कोप अलग-अलग पाथ्स को पार करता है, क्या पेज और Service Worker समान-मूल (same-origin) हैं, और किन ब्राउज़रों को काम करना चाहिए। पूछें कि क्या लॉगिन, लॉगआउट और रिफ्रेश रेस कर सकते हैं, क्या कैश परिवर्तन तत्काल होने चाहिए, और ऑफलाइन रहते हुए बासी (stale) सेशन स्थिति कब तक स्वीकार्य है।
30-सेकंड का उत्तर फ्रेमवर्क
"मैं Service Worker में आवश्यक कुकी नामों और URLs को सब्सक्राइब करूँगा, फिर cookiechange के बाद केवल प्रासंगिक कुकीज़ को दोबारा पढ़ूँगा और एक आइडेम्पोटेंट सेशन स्टेट मशीन या मोनोटोनिक कैश संस्करण को आगे बढ़ाऊँगा। Cookie Store एसिंक्रोनस है, इवेंट्स केवल स्क्रिप्ट-दृश्यमान परिवर्तनों को कवर करते हैं, और वे कोई ट्रांजेक्शन या ग्लोबल ऑर्डर प्रदान नहीं करते हैं, इसलिए हैंडलर को डुप्लीकेट हटाना होगा और वर्तमान स्थिति को फिर से पढ़ना होगा। असमर्थित ब्राउज़र सर्वर-साइड कुकी चेक और स्पष्ट पेज सिंक्रोनाइज़ेशन बनाए रखते हैं; बासी कैश कभी भी प्रमाणीकरण का प्रमाण नहीं होता है।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: API सीमा को परिभाषित करें
पेज window.cookieStore के माध्यम से एसिंक्रोनस रूप से पढ़ और लिख सकते हैं; एक Service Worker registration.cookies के माध्यम से सब्सक्रिप्शन प्रबंधित करता है और cookiechange प्राप्त करता है। दोनों कुकी नीति के अधीन रहते हैं और HttpOnly मान को नहीं पढ़ सकते हैं।
चरण 2: सबसे छोटा सब्सक्रिप्शन बनाएं
केवल आवश्यक कुकी नामों को सब्सक्राइब करें और आवश्यकता पड़ने पर URL को प्रतिबंधित करें। अलग-अलग पाथ्स पर समान नाम वाली कुकीज़ सह-अस्तित्व में रह सकती हैं, इसलिए हैंडलर को केवल नाम से अनुमान लगाने के बजाय लक्ष्य की पहचान करने के लिए इवेंट जानकारी और वर्तमान URL का उपयोग करना चाहिए।
self.addEventListener("activate", (event) => {
event.waitUntil(
self.registration.cookies.subscribe([
{ name: "session", url: self.registration.scope },
]),
);
});चरण 3: इवेंट्स को सूचनाओं के रूप में मानें, स्नैपशॉट के रूप में नहीं
इवेंट कुकी परिवर्तनों का वर्णन करता है, लेकिन एसिंक्रोनस हैंडलिंग चलने से पहले कोई अन्य परिवर्तन हो सकता है। get() या getAll() के साथ वर्तमान स्थिति को फिर से पढ़ें, और प्रोसेसिंग को आइडेम्पोटेंट बनाएं। इवेंट ऑब्जेक्ट को ट्रांजेक्शन लॉग या अंतिम सत्य के रूप में न मानें।
चरण 4: स्क्रिप्ट-दृश्यमान और HttpOnly परिवर्तनों को अलग करें
विनिर्देश के लिए केवल स्क्रिप्ट-दृश्यमान कुकी परिवर्तनों के लिए सूचनाओं की आवश्यकता होती है। एक सर्वर Service Worker को अपना मान बताए बिना HttpOnly कुकी सेट या डिलीट कर सकता है। प्रमाणीकरण निष्कर्ष अभी भी सर्वर प्रतिक्रियाओं से आते हैं, किसी छूटे हुए इवेंट से नहीं।
चरण 5: सेशन को स्पष्ट रूप से मॉडल करें
अज्ञात (unknown), सत्यापित (verified), लॉग आउट (logged out) और समाप्त (expired) जैसी स्थितियों का उपयोग करें, और प्रतिक्रिया संस्करणों, समाप्ति समय या पुनर्मूल्यांकन परिणामों से उन्हें आगे बढ़ाएं। एक कुकी परिवर्तन एक चेक को ट्रिगर करता है; यह स्वयं लॉगिन या लॉगआउट साबित नहीं करता है।
चरण 6: कई टैब्स में रेस कंडीशन्स को संभालें
कई पेज एक साथ कुकी को रिफ्रेश या डिलीट कर सकते हैं। छोटे अंतरालों को संयोजित (coalesce) करें, नवीनतम रीड से एक कैश अपडेट लागू करें, और एक सेशन संस्करण का उपयोग करें ताकि कोई पुराना इवेंट नई स्थिति को अधिलेखित न कर सके। कैश विलोपन और प्रीकैशिंग भी आइडेम्पोटेंट होने चाहिए।
चरण 7: असमर्थित ब्राउज़र फॉलबैक डिज़ाइन करें
जब Cookie Store अनुपलब्ध हो, तो महत्वपूर्ण नेविगेशन या नेटवर्क प्रतिक्रियाओं के बाद स्पष्ट सिंक्रोनाइज़ेशन करें जबकि सर्वर आधिकारिक बना रहे। HttpOnly मान के लिए document.cookie को पोल न करें या API गायब होने के कारण कैश प्रमाणीकरण में ढिलाई न बरतें।
चरण 8: गोपनीयता और सुरक्षा जोखिम को न्यूनतम करें
केवल व्यावसायिक रूप से आवश्यक नामों और URLs को सब्सक्राइब करें। कुकी मानों को कभी भी लॉग्स, Cache Storage या postMessage में न लिखें। Secure, HttpOnly, SameSite, Path और समझदारी भरी समाप्ति सेटिंग्स बनाए रखें, और लॉगआउट के दौरान क्लाइंट कैश साफ़ करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं Cookie Store का उपयोग एक परिवर्तन सूचक के रूप में करूँगा, प्रमाणीकरण डेटाबेस के रूप में नहीं। Service Worker एक्टिवेशन के दौरान, सटीक नामों और स्कोप के लिए एक आइडेम्पोटेंट सब्सक्रिप्शन बनाएं। cookiechange पर, वर्तमान स्क्रिप्ट-दृश्यमान स्थिति को फिर से पढ़ें, एक आइडेम्पोटेंट सेशन स्टेट मशीन को आगे बढ़ाएं, और एक सेशन संस्करण का उपयोग करके कैश को अपडेट या साफ़ करें। HttpOnly मान सर्वर-सत्यापित रहते हैं, और छूटा हुआ इवेंट कभी भी यह साबित नहीं करता कि सेशन अपरिवर्तित है। एकाधिक टैब से समवर्ती रिफ्रेश को संयोजित करें ताकि कोई पुरानी सूचना नई स्थिति को अधिलेखित न कर सके। असमर्थित ब्राउज़रों के लिए, महत्वपूर्ण अनुरोधों पर सर्वर सत्यापन बनाए रखें और स्पष्ट पेज सिंक्रोनाइज़ेशन का उपयोग करें, HttpOnly सुरक्षा के प्रतिस्थापन के रूप में कभी भी document.cookie पोलिंग का उपयोग न करें। सब्सक्रिप्शन और कैश ऑपरेशंस का स्कोप सीमित रखें, और लॉगआउट, समाप्ति, ऑफलाइन उपयोग और Service Worker अपडेट्स का परीक्षण करें।
सामान्य गलतियाँ
cookiechange को एक पूर्ण ऑडिट लॉग मानना
यह एक सूचना है, कोई क्रॉस-प्रोसेस ट्रांजेक्शन अनुक्रम नहीं। हैंडलर को वर्तमान स्थिति को फिर से पढ़ना चाहिए और डुप्लिकेट कार्य को सहन करना चाहिए।
यह मान लेना कि Service Worker HttpOnly कुकीज़ पढ़ सकता है
HttpOnly अभी भी स्क्रिप्ट रीड्स को ब्लॉक करता है। एक Service Worker अनुरोध के माध्यम से सर्वर से सेशन को सत्यापित करने के लिए कह सकता है, लेकिन Cookie Store गुप्त मान को प्रकट नहीं करता है।
किसी भी कुकी परिवर्तन को कैश प्रमाणीकरण तय करने देना
परिवर्तन रिफ्रेश, समाप्ति या किसी अन्य पाथ से आ सकते हैं। प्रमाणीकरण-संवेदनशील कैश को बदलने से पहले सर्वर सत्यापन और संस्करण स्थिति की प्रतीक्षा करें।
फॉलो-अप प्रश्न और उत्तर
आप किसी अन्य पाथ पर गलत समान-नाम वाली कुकी को हटाने से कैसे बचते हैं?
सब्सक्राइब करते और पढ़ते समय URL स्कोप को बनाए रखें, और सटीक नाम, URL, Path और अन्य एट्रिब्यूट्स के साथ डिलीट करें। यदि लक्ष्य की पहचान नहीं की जा सकती है, तो व्यापक डिलीट जारी करने के बजाय सर्वर प्रतिक्रिया को क्लीनअप करने दें।
क्या Service Worker अपडेट से सब्सक्रिप्शन खो सकते हैं?
नए वर्कर के activate चरण के दौरान, सुनिश्चित करें कि सब्सक्रिप्शन मौजूद है (आइडेम्पोटेंट रूप से) और कैश को फिर से बनाने के लिए वर्तमान कुकी स्थिति को फिर से पढ़ें। पुराने वर्कर की मेमोरी पर निर्भर न रहें; अपडेट के बाद इनिशियलाइज़ेशन चलना चाहिए।
क्या होगा यदि कोई कुकी ऑफलाइन समाप्त हो जाती है और कोई नेटवर्क नहीं है?
स्थानीय स्थिति को असत्यापित (unverified) के रूप में चिह्नित करें और ऑफलाइन क्षमताओं को सीमित करें; ऑफलाइन मोड सर्वर सेशन का विस्तार नहीं कर सकता है। कनेक्टिविटी वापस आने पर पहले पुनर्मूल्यांकन करें, फिर कैश को पुनर्स्थापित करें, साफ़ करें या डाउनग्रेड करें।