फ़्रंटएंड इंटरव्यू: आप Cookies, localStorage, sessionStorage और IndexedDB के बीच कैसे चुनाव करते हैं?

सवाल और उपयोग के मामले

एक मल्टी-टिनेंट प्रोजेक्ट मैनेजमेंट वेब ऐप सर्वर-साइड रेंडरिंग और ऑफ़लाइन एडिटिंग दोनों का समर्थन करता है। इसमें चार प्रकार के स्टेट हैं: सर्वर को सभी टैब्स में लॉगिन सेशन को पहचानना होगा; थीम और भाषा प्राथमिकताओं को बाद की विज़िट में भी बने रहना चाहिए; एक मल्टी-स्टेप फ़ॉर्म ड्राफ़्ट केवल वर्तमान टैब से संबंधित है और उस टैब के बंद होने पर गायब हो सकता है; और इमेज अटैचमेंट्स वाले 10,000 तक स्ट्रक्चर्ड टास्क रिकॉर्ड्स को ऑफ़लाइन क्वेरी, एडिट और पुनः कनेक्ट होने के बाद सिंक्रोनाइज़ेशन का समर्थन करना चाहिए।

इस डेटा को cookies, localStorage, sessionStorage और IndexedDB में असाइन करें। बताएं कि डिज़ाइन XSS और CSRF, ओरिजिन आइसोलेशन, एक सुसंगत पहले SSR रेंडर, समवर्ती टैब्स, कोटा और निष्कासन (eviction), डेटाबेस वर्शन अपग्रेड, लॉगआउट और लोकल क्लीनअप, और ऑफ़लाइन सिंक्रोनाइज़ेशन को कैसे संभालता है।

10,000-रिकॉर्ड का आंकड़ा एक परिदृश्य बाधा है जो स्ट्रक्चर्ड क्वेरीज़, एसिंक्रोनस एक्सेस और एक सिंक प्रोटोकॉल पर चर्चा के लिए बाध्य करता है। यह ब्राउज़र क्षमता की कोई गारंटी नहीं है। मुख्य कौशल वेब प्लेटफ़ॉर्म सिमेंटिक्स से फ़्रंटएंड पर्सिस्टेंस निर्णय लेना है, इसलिए श्रेणी frontend है।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

पहला, क्या उम्मीदवार API चुनने से पहले यह पूछता है कि डेटा कौन पढ़ता है, यह कब तक रहता है, इसका आकार क्या है, इसके उजागर होने की क्या लागत होगी, और कौन सा सिस्टम आधिकारिक (authoritative) है? क्षमता की रटी-रटाई तालिका SSR, ऑथेंटिकेशन या ऑफ़लाइन निरंतरता की व्याख्या नहीं कर सकती।

दूसरा, क्या उम्मीदवार पर्सिस्टेंस को सुरक्षा से अलग कर सकता है? पर्सिस्टेंस localStorage को सेशन आइडेंटिफ़ायर के लिए उपयुक्त नहीं बनाता है। सेम-ओरिजिन स्क्रिप्ट इसे पढ़ और बदल सकती हैं, इसलिए एक XSS पेलोड इसके डेटा को चुरा सकता है या उससे छेड़छाड़ कर सकता है। एक HttpOnly कुकी जावास्क्रिप्ट को सेशन आइडेंटिफ़ायर पढ़ने से रोकती है, लेकिन यह उस कोड को नहीं रोकती है जो पहले से ही पेज में चल रहा है और ऑथेंटिकेटेड रिक्वेस्ट भेज रहा है।

तीसरा, क्या उम्मीदवार कुकी व्यवहार के दोनों पहलुओं को समझता है? ब्राउज़र रिक्वेस्ट के साथ मैचिंग कुकीज़ भेजता है, जिससे सर्वर रेंडरिंग और ऑथेंटिकेशन में मदद मिलती है। यही स्वचालित रूप से भेजा जाना CSRF सुरक्षा की मांग करता है। SameSite एक सुरक्षा उपाय है, यह ओरिजिन जांच, CSRF टोकन या संवेदनशील कार्रवाइयों के लिए पुनः प्रमाणीकरण (reauthentication) का विकल्प नहीं है।

चौथा, क्या उम्मीदवार IndexedDB को एक त्रुटिपूर्ण (fallible) लोकल रेप्लिका मान सकता है? यह एसिंक्रोनस स्ट्रक्चर्ड ऑब्जेक्ट्स, इंडेक्स और ब्लॉब्स का समर्थन करता है, लेकिन यह सर्वर के साथ सिंक्रोनाइज़ नहीं होता है। कोटा विफलताएं, निष्कासन, क्लीनअप, ब्लॉक किए गए अपग्रेड और कंकरेंसी टकराव एप्लिकेशन की ज़िम्मेदारी हैं।

पांचवां, क्या उम्मीदवार केवल “यह रिफ्रेश के बाद भी बना रहता है” को एकमात्र टेस्ट मानने के बजाय एक निष्पादन योग्य विफलता मैट्रिक्स (failure matrix) प्रदान कर सकता है?

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• पहले रेंडर के लिए सर्वर को किन मानों की आवश्यकता है? यदि SSR को सही लॉगिन स्थिति, भाषा या थीम के लिए HTML उत्सर्जित करना है, तो उन मानों को एक सर्वर-पठनीय स्रोत की आवश्यकता होती है, या उत्पाद को क्लाइंट माउंटिंग के बाद परिवर्तन स्वीकार करना होगा।
• कौन सा ऑथेंटिकेशन मॉडल उपयोग में है? यह उत्तर सर्वर-साइड सेशन मानता है। एक शुद्ध API टोकन डिज़ाइन को स्पष्ट जारी करने, रोटेशन, निरस्तीकरण (revocation) और क्रॉस-साइट रिक्वेस्ट नियमों की भी आवश्यकता होती है।
• क्या ड्राफ़्ट को वास्तव में टैब-स्कोप्ड होना चाहिए? यदि उपयोगकर्ता टैब बंद करने के बाद रिकवरी या किसी अन्य डिवाइस पर जारी रखने की उम्मीद करते हैं, तो sessionStorage अब आवश्यकता को पूरा नहीं करता है; IndexedDB या सर्वर का उपयोग करें।
• क्या ऑफ़लाइन डेटा में संवेदनशील जानकारी है? साझा डिवाइस, XSS, ब्राउज़र प्रोफ़ाइल और लोकल बैकअप यह बदल देते हैं कि डिस्क पर क्या लिखा जा सकता है।
• 10,000 रिकॉर्ड कैसे क्वेरी और अपडेट किए जाते हैं? प्रोजेक्ट, अपडेट समय या सिंक स्थिति द्वारा क्वेरीज़ सरल की-वैल्यू एक्सेस की तुलना में इंडेक्स और ट्रांज़ैक्शन को अधिक महत्वपूर्ण बनाती हैं।
• क्या सर्वर अंतिम सोर्स ऑफ़ ट्रुथ है? यह परिदृश्य एक आधिकारिक सर्वर और एक पुनर्निर्माण योग्य (rebuildable) लोकल कॉपी मानता है। अपूरणीय ऑफ़लाइन-निर्मित डेटा को मजबूत पर्सिस्टेंस, एक्सपोर्ट और टकराव नियंत्रण की आवश्यकता होती है।
• टकराव (conflict) क्या माना जाता है? समवर्ती डिवाइस संपादन वर्शन अस्वीकृति, फ़ील्ड मर्जिंग या व्यावसायिक प्राथमिकता का उपयोग कर सकते हैं। स्टोरेज API उत्पाद के लिए उस नीति का चयन नहीं कर सकता है।
• क्या लॉगआउट पर प्रत्येक टिनेंट का डेटा हटाना आवश्यक है? जब कई खाते एक ब्राउज़र साझा करते हैं, तो क्लीनअप को उपयोगकर्ता और टिनेंट नेमस्पेस की आवश्यकता होती है ताकि अगला उपयोगकर्ता पिछले उपयोगकर्ता की रेप्लिका न देख सके।

30-सेकंड उत्तर फ़्रेमवर्क

“मैं डेटा को रीडर, लाइफ़टाइम, आकार, संवेदनशीलता और सोर्स ऑफ़ ट्रुथ द्वारा मैप करता हूँ। प्रमाणीकरण सर्वर सेशन और __Host-, Secure और उपयुक्त HttpOnly मान वाली SameSite कुकी के साथ-साथ CSRF सुरक्षा का उपयोग करता है। छोटी गैर-संवेदनशील प्राथमिकताएं localStorage का उपयोग करती हैं, जिसमें SSR की आवश्यकता होने पर सर्वर-पठनीय प्रारंभिक मान होता है। एक डिस्पोज़ेबल सिंगल-टैब ड्राफ़्ट sessionStorage का उपयोग करता है। स्ट्रक्चर्ड रिकॉर्ड और छवियां इंडेक्स, ट्रांज़ैक्शन, एक वर्शन किए गए स्कीमा और एक आउटबॉक्स के साथ IndexedDB का उपयोग करते हैं। सर्वर आधिकारिक बना रहता है; सिंक वर्शन और आइडेम्पोटेंसी कुंजियों का उपयोग करता है और टकरावों को स्पष्ट रूप से हल करता है। लोकल स्टोरेज को क्लियर करने योग्य और कोटा-त्रुटिपूर्ण मानें, फिर XSS, CSRF, मल्टीपल टैब्स, निष्कासन, ब्लॉक किए गए अपग्रेड, पुन: कनेक्ट और लॉगआउट क्लीनअप का परीक्षण करें।”

चरण-दर-चरण गहन विश्लेषण

चरण 1: पाँच प्रश्नों के साथ निर्णय मैट्रिक्स बनाएं

प्रत्येक मान के लिए, पाँच प्रश्न पूछें: क्या रीडर सर्वर है, वर्तमान टैब है, या प्रत्येक सेम-ओरिजिन पेज है; क्या लाइफ़टाइम एक रेंडर, एक टैब, एक ब्राउज़र सेशन या कई सेशन है; क्या डेटा एक छोटी स्ट्रिंग, स्ट्रक्चर्ड ऑब्जेक्ट्स या ब्लॉब्स है; प्रकटीकरण (disclosure) और छेड़छाड़ कितने हानिकारक हैं; और क्या सर्वर या लोकल डिवाइस आधिकारिक है?

यह इस परिदृश्य के लिए प्रारंभिक आवंटन तैयार करता है:

Login session       -> Server session + random identifier in an HttpOnly cookie
Theme and language  -> localStorage; add a server-readable initial value when SSR requires it
Single-tab draft    -> sessionStorage
Offline data/images -> IndexedDB + an application-level synchronization protocol

यह क्षमता के आधार पर रैंकिंग नहीं है। यहाँ एक कुकी की परिभाषित क्षमता रिक्वेस्ट के साथ सर्वर तक पहुँचना है। sessionStorage की परिभाषित सीमा टॉप-लेवल ब्राउज़िंग संदर्भ है। IndexedDB एसिंक्रोनस ट्रांज़ैक्शन, स्ट्रक्चर्ड ऑब्जेक्ट्स और इंडेक्स प्रदान करता है।

चरण 2: सर्वर को प्रमाणीकरण के लिए आधिकारिक बनाएं

ब्राउज़र केवल एक उच्च-एन्ट्रॉपी, अल्पकालिक सेशन आइडेंटिफ़ायर संग्रहीत करता है। वास्तविक अनुमतियां, समाप्ति और निरस्तीकरण सर्वर पर रहते हैं। Secure, HttpOnly, एक उपयुक्त SameSite मान सेट करें, और अधिमानतः बिना __Host- और रूट पाथ के साथ एक Domain कुकी का उपयोग करें। लॉगआउट, पासवर्ड परिवर्तन और जोखिम की घटनाएं सर्वर सेशन को अमान्य करती हैं; केवल ब्राउज़र मान को हटाना अपर्याप्त है।

HttpOnly सेशन आइडेंटिफ़ायर तक सीधी स्क्रिप्ट पहुंच को कम करता है, लेकिन सेम-ओरिजिन XSS अभी भी सक्रिय पेज से ऑथेंटिकेटेड कार्रवाइयां जारी कर सकता है। आउटपुट एन्कोडिंग, CSP और अन्य XSS सुरक्षा आवश्यक बनी रहती हैं, और उच्च जोखिम वाले संचालन के लिए पुन: प्रमाणीकरण की आवश्यकता हो सकती है। चूंकि मेल खाने वाली कुकीज़ स्वचालित रूप से भेजी जाती हैं, इसलिए स्थिति बदलने वाले रिक्वेस्ट को ओरिजिन को मान्य करना चाहिए और CSRF टोकन का उपयोग करना चाहिए। SameSite एकमात्र नियंत्रण नहीं होना चाहिए।

सेशन आइडेंटिफ़ायर को localStorage में रखने से यह सफलतापूर्वक चलने वाली किसी भी सेम-ओरिजिन स्क्रिप्ट के लिए पठनीय हो जाता है। क्लाइंट-साइड एन्क्रिप्शन एक स्वचालित समाधान नहीं है: यदि पेज जावास्क्रिप्ट डिक्रिप्शन कुंजी प्राप्त कर सकता है या डिक्रिप्शन पथ को कॉल कर सकता है, तो सेम-ओरिजिन XSS आमतौर पर ऐसा कर सकता है।

चरण 3: छोटी, गैर-संवेदनशील प्राथमिकताओं के लिए localStorage का उपयोग करें

localStorage ओरिजिन-स्कोप्ड है, स्ट्रिंग कुंजियों और मानों को संग्रहीत करता है, ब्राउज़र सेशन में बना रहता है, और सिंक्रोनस संचालन को उजागर करता है। थीम, भाषा या टेबल डेंसिटी जैसी छोटी प्राथमिकताएं उपयुक्त हैं। वे स्थायी नहीं हैं: साइट डेटा साफ़ करना, निजी ब्राउज़िंग सेशन समाप्त करना या ब्राउज़र नीति उन्हें हटा सकती है।

सर्वर localStorage को सीधे नहीं पढ़ सकता है। यदि पहले SSR फ़्रेम को सही भाषा या थीम का उपयोग करना चाहिए, तो एक मान्य प्राथमिकता को सर्वर-पठनीय कुकी या उपयोगकर्ता प्रोफ़ाइल में सिंक्रोनाइज़ करें और परिभाषित करें कि कौन सी प्रतिलिपि मान्य होगी। यदि मान केवल क्लाइंट है, तो एक स्थिर डिफ़ॉल्ट उत्सर्जित करें और माउंट करने के बाद स्विच करें ताकि सर्वर HTML और पहला क्लाइंट रेंडर असहमत न हों।

localStorage में एक बड़ा रिकॉर्ड ऐरे संग्रहीत करने और बार-बार संपूर्ण JSON मान को पार्स करने से बचें। डेटासेट के साथ सिंक्रोनस सीरियलाइज़ेशन और मेन-थ्रेड एक्सेस बढ़ता है, जबकि मॉडल में IndexedDB ट्रांज़ैक्शन और इंडेक्स की कमी होती है।

चरण 4: केवल डिस्पोज़ेबल टैब स्थिति को sessionStorage में रखें

sessionStorage ओरिजिन और टॉप-लेवल ब्राउज़िंग संदर्भ द्वारा विभाजित है। यह उसी टैब में रीलोड होने पर बना रहता है और टैब या विंडो बंद होने पर साफ़ हो जाता है। यह इसे वर्तमान टैब के स्टेप नंबर और डिस्पोज़ेबल ड्राफ़्ट के लिए उपयुक्त बनाता है, लेकिन क्रॉस-टैब कार्ट, दीर्घकालिक रिकवरी या क्रॉस-डिवाइस स्थिति के लिए नहीं।

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

सेम-ओरिजिन स्क्रिप्ट sessionStorage को पढ़ और लिख भी सकती है। "बंद होने पर साफ़ किया गया" लंबे समय तक चलने वाले क्रेडेंशियल को संग्रहीत करने का कोई कारण नहीं है। ड्राफ़्ट को बनाए रखने से पहले, पासवर्ड, भुगतान डेटा या मेडिकल जानकारी जैसे फ़ील्ड को बाहर करें जिन्हें डिस्क पर नहीं लिखा जाना चाहिए।

चरण 5: IndexedDB में एक पुनर्निर्माण योग्य ऑफ़लाइन रेप्लिका बनाएं

IndexedDB एसिंक्रोनस रिक्वेस्ट, ट्रांज़ैक्शन, ऑब्जेक्ट स्टोर, कुंजियाँ, इंडेक्स और ब्लॉब स्टोरेज प्रदान करता है। यह इस परिदृश्य के स्ट्रक्चर्ड रिकॉर्ड्स और छवियों के लिए उपयुक्त है। डेटा को tenantId + userId द्वारा विभाजित करें, कार्यों, अनुलग्नकों और एक आउटबॉक्स के लिए ऑब्जेक्ट स्टोर बनाएं, और केवल वास्तविक प्रश्नों जैसे प्रोजेक्ट, अपडेट समय और सिंक स्थिति के लिए आवश्यक इंडेक्स जोड़ें।

एक स्पष्ट डेटाबेस वर्शन और वृद्धिशील (incremental) माइग्रेशन का उपयोग करें। एक नया वर्शन खोलना पुराने टैब के कनेक्शन द्वारा ब्लॉक किया जा सकता है। उन टैब्स को versionchange को सुनना चाहिए, अपने पुराने कनेक्शन बंद करने चाहिए, और उपयोगकर्ता को रीफ़्रेश करने के लिए कहना चाहिए। नए पेज को स्टार्टअप के दौरान हमेशा लटके रहने के बजाय blocked को हैंडल करना चाहिए।

IndexedDB एक स्थानीय डेटाबेस है, सिंक्रोनाइज़ेशन सेवा नहीं। एक सफल राइट का अर्थ है कि स्थानीय ट्रांज़ैक्शन कमिट हो गया है। एप्लिकेशन अभी भी स्थानीय और सर्वर वर्शन, एक ऑपरेशन ID और सिंक स्थिति रिकॉर्ड करता है, और पुनः प्रयासों (retries) को आइडेम्पोटेंट बनाता है।

चरण 6: ऑफ़लाइन सिंक्रोनाइज़ेशन और क्रॉस-टैब टकरावों को स्पष्ट रूप से डिज़ाइन करें

प्रत्येक ऑफ़लाइन व्यावसायिक परिवर्तन और उसकी आउटबॉक्स प्रविष्टि को एक IndexedDB ट्रांज़ैक्शन में कमिट करें। पुनः कनेक्ट होने के बाद, एक वर्कर ऑपरेशन ID द्वारा अपलोड करता है। सर्वर एक आइडेम्पोटेंसी कुंजी के साथ डिडुप्लिकेट करता है और रिकॉर्ड वर्शन की तुलना करता है। पावती (acknowledgement) के बाद ही किसी अन्य ट्रांज़ैक्शन को सर्वर वर्शन को अपडेट करना चाहिए और आउटबॉक्स आइटम को हटाना चाहिए। यह पेंडिंग ऑपरेशन को खोए बिना रिकॉर्ड को बदलने से बचाता है।

टकराव नीति व्यवसाय से आती है। कम जोखिम वाली प्राथमिकता अंतिम लेखक की जीत (last writer wins) का उपयोग कर सकती है; कार्य स्थिति वर्शन बेमेल को अस्वीकार कर सकती है और उपयोगकर्ता को मर्ज करने के लिए कह सकती है; वित्तीय या अनुमति परिवर्तन ऑफ़लाइन कमिट को प्रतिबंधित कर सकते हैं। एक storage इवेंट या BroadcastChannel अन्य टैब्स को डेटा पुनः लोड करने के लिए कह सकता है, लेकिन एक अधिसूचना कोई लॉक नहीं है और IndexedDB ट्रांज़ैक्शन या सर्वर वर्शन जांच की जगह नहीं ले सकती है। storage इवेंट उस दस्तावेज़ में ट्रिगर नहीं होता है जिसने राइट का प्रदर्शन किया था।

चरण 7: कोटा, निष्कासन और क्लीनअप को सामान्य विफलताओं के रूप में मानें

ब्राउज़र कोटा ब्राउज़र, डिवाइस और मोड के अनुसार भिन्न होता है। IndexedDB आमतौर पर बेस्ट-एफ़र्ट स्टोरेज का उपयोग करता है, जिसे उपयोगकर्ता साफ़ कर सकता है और स्टोरेज के दबाव में ब्राउज़र निष्कासित कर सकता है। कोटा की कमी के कारण राइट्स भी विफल हो सकते हैं। उपयोग का निरीक्षण करने के लिए स्टोरेज अनुमानों का उपयोग करें, अपूरणीय डेटा के लिए सावधानी से पर्सिस्टेंस का अनुरोध करें, और हमेशा ट्रांज़ैक्शन और कोटा विफलताओं को हैंडल करें।

नीति में अटैचमेंट सीमाएं, लीस्ट-रीसेंटली-यूज़्ड क्लीनअप, सर्वर-पुष्ट पुराने वर्शन का कम्प्रेशन या विलोपन, और एक पुनर्प्राप्त करने योग्य "स्थानीय स्थान भरा हुआ है" स्थिति शामिल होनी चाहिए। लॉगआउट पर, पहले सर्वर सेशन को रद्द करें, फिर डेटाबेस कनेक्शन बंद करें और उस उपयोगकर्ता और टिनेंट के IndexedDB डेटा, प्राथमिकताओं और ड्राफ़्ट को हटा दें। अन्य टैब्स को भी सूचित करें। स्थानीय विलोपन सर्वर निरस्तीकरण का विकल्प नहीं हो सकता।

चरण 8: विफलता मैट्रिक्स के साथ सीमाओं को सत्यापित करें

पहले SSR रेंडर और हाइड्रेशन का परीक्षण करें; टैब को रिफ्रेश करें, डुप्लिकेट करें, नया खोलें और बंद करें; दूसरे टैब से लॉगआउट करें; XSS के तहत स्क्रिप्ट-पठनीय स्कोप; क्रॉस-साइट स्थिति बदलने वाले रिक्वेस्ट; निजी ब्राउज़िंग; साफ़ किया गया साइट डेटा; कोटा समाप्ति; एक पुराना टैब जो डेटाबेस अपग्रेड को रोक रहा है; दो टैब समवर्ती रूप से संपादन कर रहे हैं; ऑफ़लाइन पुनः प्रयास, डुप्लिकेट और आउट-ऑफ़-ऑर्डर प्रतिक्रियाएं, और टकराव; और पुराने डेटा को उजागर किए बिना टिनेंट बदलना।

पास होने का अर्थ "डेटा बना रहता है" से अधिक है। प्रमाणीकरण रद्द करने योग्य है, संवेदनशील मान जावास्क्रिप्ट के संपर्क में नहीं आते हैं, ड्राफ़्ट टैब सीमा का पालन करते हैं, एक ऑफ़लाइन राइट अपनी आउटबॉक्स प्रविष्टि नहीं खो सकता है, डुप्लिकेट सिंक व्यावसायिक प्रभावों को डुप्लिकेट नहीं करता है, अपग्रेड पुनर्प्राप्त होते हैं, कोटा विफलताओं में फ़ॉलबैक होता है, और सर्वर स्थानीय रेप्लिका का पुनर्निर्माण कर सकता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

“मैं क्षमता के बजाय रीडर, लाइफ़टाइम, डेटा मॉडल, ट्रस्ट बाउंड्री और सोर्स ऑफ़ ट्रुथ से शुरुआत करता हूँ। सर्वर और प्रत्येक टैब को लॉगिन सेशन की आवश्यकता होती है, इसलिए वास्तविक सेशन सर्वर पर रहता है और ब्राउज़र __Host-, Secure और एक उपयुक्त HttpOnly मान वाली एक SameSite कुकी रखता है। यह जावास्क्रिप्ट टोकन एक्सेस को कम करता है, लेकिन XSS अभी भी उपयोगकर्ता के रूप में कार्य कर सकता है, और स्वचालित कुकी भेजने के लिए अभी भी एक CSRF टोकन, ओरिजिन जांच और संवेदनशील कार्रवाइयों के लिए पुनः प्रमाणीकरण की आवश्यकता होती है।

थीम और भाषा छोटी गैर-संवेदनशील प्राथमिकताएं हैं, इसलिए वे localStorage का उपयोग करती हैं। यदि SSR को पहले फ़्रेम पर उनकी आवश्यकता है, तो मैं एक मान्य सर्वर-पठनीय प्राथमिकता को सिंक्रोनाइज़ करता हूँ और आधिकारिक प्रतिलिपि को परिभाषित करता हूँ। वर्तमान टैब का डिस्पोज़ेबल फ़ॉर्म ड्राफ़्ट sessionStorage का उपयोग करता है: रीलोड इसे पुनर्स्थापित करता है और क्लोज़ इसे हटा देता है। मैं एक नए पेज के लिए ओपनर के मान की प्रारंभिक प्रतिलिपि बनाने का भी ध्यान रखता हूँ।

10,000 कार्य और चित्र IndexedDB का उपयोग करते हैं। डेटाबेस को उपयोगकर्ता और टिनेंट द्वारा विभाजित किया गया है और यह एक वर्शन किए गए स्कीमा, इंडेक्स और ट्रांज़ैक्शन का उपयोग करता है। प्रत्येक व्यावसायिक संपादन और आउटबॉक्स प्रविष्टि एक साथ कमिट होती है। पुनः कनेक्ट होने पर, क्लाइंट एक आइडेम्पोटेंट ऑपरेशन ID के साथ अपलोड करता है, और सर्वर पावती देने या टकराव वापस करने से पहले रिकॉर्ड वर्शन की तुलना करता है। क्रॉस-टैब सूचनाएं केवल पुनः लोड का कारण बनती हैं; स्थानीय ट्रांज़ैक्शन और सर्वर वर्शन शुद्धता प्रदान करते हैं।

मैं सभी स्थानीय स्टोरेज को क्लियर करने योग्य, कोटा-त्रुटिपूर्ण और सेम-ओरिजिन स्क्रिप्ट के लिए उपलब्ध मानता हूँ। मैं कोटा त्रुटियों को संभालता हूँ, पुनर्निर्माण योग्य अनुलग्नकों को साफ़ करता हूँ, अपग्रेड के दौरान पुराने कनेक्शन बंद करता हूँ, और लॉगआउट पर उपयोगकर्ता के स्थानीय नेमस्पेस को साफ़ करने से पहले सर्वर सेशन को रद्द करता हूँ। मेरा परीक्षण मैट्रिक्स SSR और हाइड्रेशन, टैब कॉपी, XSS, CSRF, कोटा, निष्कासन, ब्लॉक किए गए अपग्रेड, समवर्ती संपादन, ऑफ़लाइन पुन: प्रयास और टिनेंट स्विचिंग को कवर करता है।”

सामान्य गलतियाँ

• क्षमता तालिका से यांत्रिक रूप से चयन करना → सर्वर रीडर्स, टैब सीमाओं और अधिकार को अनदेखा करता है → पहले पांच-आयामी मैट्रिक्स का उपयोग करें।
• सेशन आइडेंटिफ़ायर को localStorage में रखना → सेम-ओरिजिन XSS इसे पढ़ सकता है और चुरा सकता है → सर्वर सेशन द्वारा समर्थित एक संरक्षित कुकी का उपयोग करें और XSS को रोकना जारी रखें।
• यह मान लेना कि HttpOnly XSS को समाप्त कर देता है → दुर्भावनापूर्ण स्क्रिप्ट अभी भी ऑथेंटिकेटेड कार्रवाइयां कर सकती है → टोकन-चोरी सुरक्षा को कार्रवाई सुरक्षा से अलग करें।
• CSRF के लिए केवल SameSite का उपयोग करना → ब्राउज़र नीतियों, रिक्वेस्ट प्रकारों और व्यावसायिक प्रवाहों की अभी भी सीमाएं हैं → टोकन, ओरिजिन जांच और पुन: प्रमाणीकरण को मिलाएं।
• सर्वर को localStorage पर निर्भर बनाना → SSR ब्राउज़र स्टोरेज को नहीं पढ़ सकता है → एक सर्वर-पठनीय प्रारंभिक मान प्रदान करें या पोस्ट-माउंट परिवर्तन स्वीकार करें।
• यह मान लेना कि एक नए टैब में हमेशा खाली sessionStorage होता है → एक ओपनर प्रारंभिक प्रति प्रदान कर सकता है → ओपनर को हटा दें या एक टैब इंस्टेंस ID जोड़ें।
• localStorage में एक बड़ा ऐरे रखना → सिंक्रोनस पार्सिंग, पूरे-मान के पुनर्लेखन की आवश्यकता होती है, और इसमें कोई इंडेक्स किए गए ट्रांज़ैक्शन नहीं होते हैं → IndexedDB का उपयोग करें।
• यह मान लेना कि IndexedDB स्वचालित रूप से सिंक्रोनाइज़ होता है → स्थानीय कमिट और सर्वर पावती अलग-अलग घटनाएं हैं → एक आउटबॉक्स, आइडेम्पोटेंसी, वर्शन और टकराव नीति लागू करें।
• क्रॉस-टैब अधिसूचना को एक वितरित लॉक मानना → संदेशों में देरी हो सकती है और वे सर्वर टकराव का निर्णय नहीं ले सकते हैं → अधिसूचना के बाद पुनः लोड करें और शुद्धता के लिए ट्रांज़ैक्शन के साथ-साथ वर्शन का उपयोग करें।
• यह मान लेना कि स्थानीय डेटा स्थायी है → क्लीनअप, निष्कासन, निजी मोड और कोटा इसे हटा सकते हैं → इसे पुनर्निर्माण योग्य बनाएं और राइट विफलताओं को संभालें।
• लॉगआउट पर केवल कुकी साफ़ करना → IndexedDB और प्राथमिकताएं अगले खाते में लीक हो सकती हैं → सर्वर-साइड रद्द करें, फिर प्रत्येक उपयोगकर्ता और टिनेंट स्थानीय रेप्लिका को साफ़ करें।

फ़ॉलो-अप सवाल और जवाब

फ़ॉलो-अप 1: क्या मैं किसी टोकन को एन्क्रिप्ट करके localStorage में रख सकता हूँ?

यदि पेज जावास्क्रिप्ट कुंजी प्राप्त कर सकता है या डिक्रिप्शन पथ को कॉल कर सकता है, तो सफलतापूर्वक चलने वाली सेम-ओरिजिन दुर्भावनापूर्ण स्क्रिप्ट आमतौर पर ऐसा कर सकती है। यह इस परिदृश्य में XSS से सेशन की चोरी का समाधान नहीं करता है। एक मजबूत सीमा HttpOnly कुकी के साथ एक सर्वर सेशन है, जिसमें XSS रोकथाम, CSRF सुरक्षा, रोटेशन और निरस्तीकरण शामिल है। क्लाइंट-साइड एन्क्रिप्शन केवल तभी किसी खतरे का समाधान करता है जब उसकी कुंजी उसी हमले की सतह (attack surface) से बाहर हो।

फ़ॉलो-अप 2: क्या होगा यदि किसी ड्राफ़्ट को टैब बंद करने के बाद भी बने रहना चाहिए?

लाइफ़टाइम की आवश्यकता बदल गई है, इसलिए sessionStorage अब उपयुक्त नहीं है। एक गैर-संवेदनशील ड्राफ़्ट जिसे केवल स्थानीय रिकवरी की आवश्यकता है, IndexedDB का उपयोग कर सकता है। एक ड्राफ़्ट जिसे विभिन्न डिवाइसों पर चलना चाहिए या खोया नहीं जा सकता है, उसे सर्वर से सिंक्रोनाइज़ होना चाहिए। किसी भी विकल्प को एक अवधारण अवधि (retention period), उपयोगकर्ता और टिनेंट आइसोलेशन, और पर्सिस्टेंस से संवेदनशील फ़ील्ड को बाहर करने वाले नियमों की आवश्यकता होती है।

फ़ॉलो-अप 3: क्या होगा यदि दो टैब एक ही ऑफ़लाइन कार्य को संपादित करते हैं?

प्रत्येक रिकॉर्ड पर एक सर्वर वर्शन और स्थानीय संशोधन संग्रहीत करें और प्रत्येक राइट के लिए एक IndexedDB ट्रांज़ैक्शन का उपयोग करें। BroadcastChannel या डेटा-परिवर्तन अधिसूचना अन्य टैब को पुनः लोड करने के लिए कहती है, लेकिन सर्वर अभी भी वर्शन के विरुद्ध एक सशर्त अपडेट करता है। टकराव के बाद, व्यवसाय फ़ील्ड मर्जिंग, उपयोगकर्ता संकेत या अस्वीकृति चुनता है। संदेश प्राप्त करने वाला अंतिम टैब सोर्स ऑफ़ ट्रुथ नहीं बन सकता।

फ़ॉलो-अप 4: क्या होगा यदि कोई पुराना टैब IndexedDB अपग्रेड को ब्लॉक करता है?

पुराने कनेक्शन versionchange को सुनते हैं, बंद होते हैं, और रिफ्रेश करने के लिए प्रेरित करते हैं। नया पेज अनिश्चित काल तक प्रतीक्षा करने के बजाय एक पुनर्प्राप्त करने योग्य स्थिति के साथ blocked को संभालता है। माइग्रेशन वृद्धिशील, आइडेम्पोटेंट होते हैं, और आंशिक ऐतिहासिक डेटा को सहन करते हैं। रिलीज़ से पहले, एक पुराने वर्शन वाले टैब को कनेक्ट रखें और क्लोज़र, मैसेजिंग और माइग्रेशन को सत्यापित करने के लिए नया वर्शन खोलें।

फ़ॉलो-अप 5: ब्राउज़र स्टोरेज भर जाने पर ऐप को कैसे डिग्रेड होना चाहिए?

कोटा और ट्रांज़ैक्शन त्रुटियों को संभालें, पहले नए अटैचमेंट्स को कैश करना बंद करें, और पुराने सर्वर-पुष्ट अटैचमेंट्स और वर्शन को हटा दें जिन्हें फिर से बनाया जा सकता है। एक गैर-सिंक्रोनाइज़्ड आउटबॉक्स की प्राथमिकता डाउनलोड करने योग्य कैश से अधिक होती है। यदि स्थान अभी भी अपर्याप्त है, तो उपयोगकर्ता को पुनः कनेक्ट करने और सिंक्रोनाइज़ करने या स्थान खाली करने के लिए कहें; कभी भी मूक (silent) सेव को सफल के रूप में रिपोर्ट न करें।

फ़ॉलो-अप 6: सही लॉगआउट क्रम क्या है?

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