लोकलस्टोरेज, सेशनस्टोरेज, सेशन और कुकीज में क्या अंतर है?

Question

लोकलस्टोरेज, सेशनस्टोरेज, सेशन और कुकीज के तकनीकी पक्ष और विपक्ष क्या हैं और मैं कब एक का उपयोग करूंगा?

Comments

यह भी एक संबंधित विषय है जो लुक अच्छा है: HTML5 स्थानीय भंडारण बनाम सत्र भंडारण ( stackoverflow.com/questions/5523140/… )

— Sarin JS

यह भी ध्यान दें कि सत्र कुकीज़ जब तक ब्राउज़र विन्डो खुली रहती हैं (तब टैब नहीं जिसमें वे सेट थे) जैसे ही आप टैब बंद करते हैं तो BUT sessionStorage को बंद कर दिया जाता है ...

— yar1

हाँ सत्र भी कुकी का प्रकार है। विशेषता यह है कि यह क्षणिक है जहां कुकी दृढ़ता है

— फारिस रेहान

@ yar1 एक विशेष ब्राउज़र विंडो एक अप्रासंगिक UI तत्व है।

— जिज्ञासु

Answer 1

यह एक बहुत व्यापक गुंजाइश सवाल है, और बहुत सारे पेशेवरों / विपक्ष स्थिति के संदर्भ में होंगे।

सभी मामलों में, ये स्टोरेज मैकेनिज़्म किसी व्यक्ति के कंप्यूटर / डिवाइस पर एक अलग ब्राउज़र के लिए विशिष्ट होंगे। सत्र के दौरान एक निरंतर आधार पर डेटा को स्टोर करने के लिए किसी भी डेटाबेस को उपयोग करने की सबसे अधिक संभावना है, लेकिन संभवतः XML या एक पाठ / CSV फ़ाइल का उपयोग करने की आवश्यकता होगी।

LocalStorage, sessionStorage, और कुकीज़ सभी ग्राहक भंडारण समाधान हैं। सत्र डेटा सर्वर पर आयोजित किया जाता है जहां यह आपके प्रत्यक्ष नियंत्रण में रहता है।

लोकलस्टोरेज और सेशनस्टोरेज

लोकलस्टोरेज और सेशनस्टोरेज अपेक्षाकृत नए एपीआई हैं (मतलब, सभी विरासत ब्राउज़र उनका समर्थन नहीं करेंगे) और दृढ़ता के एकमात्र अपवाद के साथ समान (एपीआई और क्षमताओं में) दोनों के पास हैं। sessionStorage (जैसा कि नाम से पता चलता है) केवल ब्राउज़र सत्र की अवधि के लिए उपलब्ध है (और टैब या विंडो बंद होने पर हटा दिया जाता है) - यह, हालांकि, पृष्ठ पुनः लोड करता है (स्रोत डोम स्टोरेज गाइड - मोज़िला डेवलपर नेटवर्क ) से ।

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

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

कुकीज़

यह कुकीज़ के लिए भी सच है, ये उपयोगकर्ता द्वारा तुच्छ रूप से छेड़छाड़ की जा सकती हैं, और डेटा को उनसे सादे पाठ में भी पढ़ा जा सकता है - इसलिए यदि आप संवेदनशील डेटा संग्रहीत करना चाहते हैं तो सत्र वास्तव में आपका एकमात्र विकल्प है। यदि आप एसएसएल का उपयोग नहीं कर रहे हैं, तो कुकी जानकारी को पारगमन में भी इंटरसेप्ट किया जा सकता है, खासकर एक खुली वाईफाई पर।

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

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

लोकलस्टोरेज बनाम सेशनस्टोरेज बनाम कुकीज़

क्षमताओं के संदर्भ में, कुकीज, सेशनस्टोरेज और लोकलस्टोरेज आपको केवल स्ट्रिंग्स को स्टोर करने की अनुमति देते हैं - सेटिंग करते समय आदिम मूल्यों को स्पष्ट रूप से परिवर्तित करना संभव है (इन्हें पढ़ने के बाद उन्हें अपने प्रकार के रूप में उपयोग करने के लिए वापस बदलना होगा) लेकिन ऑब्जेक्ट्स या ऐरे नहीं (यह संभव है कि JSON सीरीज़ उन्हें एपीआई का उपयोग करके स्टोर कर सके)। सत्र भंडारण आम तौर पर आप अपने सर्वर साइड भाषा / ढांचे द्वारा समर्थित किसी भी आदिम या वस्तुओं को संग्रहीत करने की अनुमति देगा।

क्लाइंट-साइड बनाम सर्वर-साइड

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

जैसा कि सत्र डेटा आपके एप्लिकेशन (सर्वर साइड) द्वारा पूरी तरह से नियंत्रित किया जाता है, यह प्रकृति में संवेदनशील या सुरक्षित किसी भी चीज के लिए सबसे अच्छी जगह है।

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

कुछ वेब फ्रेमवर्क / डेवलपर्स सत्र समाप्ति से बचने के लिए प्रपत्र के एक पृष्ठ से दूसरे तक डेटा को बनाए रखने के लिए छिपे हुए HTML इनपुट का उपयोग करते हैं।

लोकलस्टोरेज, सेशनस्टोरेज और कुकीज सभी "समान-मूल" नियमों के अधीन हैं, जिसका अर्थ है कि ब्राउज़र को डेटा तक पहुंच को रोकना चाहिए, केवल उस डोमेन को छोड़कर, जिसके साथ जानकारी शुरू करनी है।

क्लाइंट स्टोरेज तकनीकों पर आगे पढ़ने के लिए Html 5 में गोता लगाएँ ।

Comments

खबरदार: सेशनस्टोरेज, लोकलस्टोरेज ऑथेंटिकेशन की जानकारी के लिए उपयुक्त नहीं हैं। वे स्वचालित रूप से सर्वर पर नहीं भेजे जाते हैं। इसका मतलब यह है कि यदि उपयोगकर्ता URL को मैन्युअल रूप से बदलता है, या HTML लिंक पर क्लिक करता है, तो आपको प्रमाणीकरण जानकारी नहीं मिलेगी। यहां तक ​​कि अगर आप HTML लिंक को फिर से लिखते हैं, तो आपको उस URL पर प्रमाणीकरण जानकारी पास करने के लिए मजबूर किया जाता है, जो सुरक्षा नंबर नहीं है। दिन के अंत में, आपको कुकीज़ का उपयोग करने के लिए मजबूर किया जाएगा। संबंधित विषय के लिए stackoverflow.com/q/26556749/14731 देखें ।

— जिली

sessionStorageजब विंडो बंद हो जाएगी, या टैब हटा दिया जाएगा ?

— trysis

टैब बंद होने पर सेशनस्टोर को हटा दिया जाएगा।

— rcarrillopadron

@ यदि कुकीज़ का उपयोग नहीं कर रहे हैं तो URL पर केवल एक ही विकल्प से दूसरी जानकारी क्यों पारित की जा रही है? इसे HTTP हेडर में क्यों नहीं पास करें?

— yby

@ आपका कहना सही है कि यह स्वचालित रूप से नहीं भेजता है, लेकिन आपका यह कहना उचित नहीं है। मैं अपने ग्राहकों के लिए कई अलग-अलग उत्पादन अनुप्रयोगों में लोकलस्टोरेज और सेशनस्टोरेज का उपयोग करता हूं और लोकलस्टोरेज / सेशनस्टोरेज पर भरोसा करने की वजह से एक भेद्यता नहीं हुई है, जो आईडी और हेडर में टोकन भेजने के साथ जुड़ा हुआ है। सर्वर पर भी कम लोड। इसके अलावा, मैं इस पृष्ठ को फिर से लोड करने और आवेदन लोड करने के लिए एक घटना को अपने बैकएंड से पूछता हूं कि क्या यह उपयोगकर्ता अभी भी प्रमाणित है। बहुत अच्छा काम करता है। हैप्पी प्रमाणीकरण! संपादित करें: एक CSRF टोकन जो अधिक सुरक्षा जोड़ता है।

— नोडोडैड

Answer 2

1. स्थानीय भंडार

   पेशेवरों :

   1. वेब स्टोरेज को कुकीज़ पर सुधार के रूप में सरलता से देखा जा सकता है, जिससे भंडारण क्षमता अधिक हो जाती है। यदि आप मोज़िला स्रोत कोड को देखते हैं तो हम देख सकते हैं कि 5120KB ( 5MB जो क्रोम पर 2.5 मिलियन चार्ट के बराबर है ) पूरे डोमेन के लिए डिफ़ॉल्ट भंडारण आकार है। यह आपको एक विशिष्ट 4KB कुकी की तुलना में काम करने के लिए काफी अधिक स्थान देता है।
   2. हर HTTP अनुरोध (HTML, चित्र, जावास्क्रिप्ट, सीएसएस, आदि) के लिए डेटा को सर्वर पर वापस नहीं भेजा जाता है - क्लाइंट और सर्वर के बीच यातायात की मात्रा को कम करता है।
   3. स्थानीयस्टोरेज में संग्रहीत डेटा स्पष्ट रूप से हटाए जाने तक बना रहता है। किए गए परिवर्तन सहेजे गए हैं और साइट पर सभी वर्तमान और भविष्य की यात्राओं के लिए उपलब्ध हैं।

   विपक्ष :

   1. यह समान-मूल नीति पर काम करता है । तो, संग्रहीत डेटा केवल उसी मूल पर उपलब्ध होगा।

2. कुकीज़

   पेशेवरों:

   1. दूसरों की तुलना में, वहाँ AFAIK कुछ भी नहीं है।

   विपक्ष:

   1. 4K कुकी संपूर्ण कुकी के लिए है, जिसमें नाम, मान, समाप्ति तिथि आदि शामिल हैं। अधिकांश ब्राउज़रों का समर्थन करने के लिए, नाम को 4000 बाइट्स और 4093 बाइट्स के तहत समग्र कुकी आकार के अंतर्गत रखें।

   2. डेटा को हर HTTP अनुरोध (HTML, चित्र, जावास्क्रिप्ट, सीएसएस, आदि) के लिए सर्वर पर वापस भेजा जाता है - क्लाइंट और सर्वर के बीच यातायात की मात्रा में वृद्धि।

      आमतौर पर, निम्नलिखित की अनुमति है:

      • कुल 300 कुकीज़
      • 4096 बाइट्स प्रति कुकी
      • डोमेन प्रति 20 कुकीज़
      • प्रति डोमेन 81920 बाइट (अधिकतम आकार 4096 = 81920 बाइट के 20 कुकीज़ को देखते हुए।)

3. sessionStorage

   पेशेवरों:

   1. के समान है localStorage।
   2. डेटा स्थायी नहीं है अर्थात डेटा केवल प्रति विंडो (या क्रोम और फ़ायरफ़ॉक्स जैसे ब्राउज़र में टैब) उपलब्ध है। डेटा केवल पेज सत्र के दौरान उपलब्ध है। किए गए परिवर्तन वर्तमान पृष्ठ के लिए सहेजे जाते हैं और उपलब्ध होते हैं, साथ ही भविष्य की साइट पर उसी विंडो पर जाते हैं। एक बार विंडो बंद होने के बाद, स्टोरेज डिलीट हो जाता है।

   विपक्ष:

   1. डेटा केवल उस विंडो / टैब के अंदर उपलब्ध है जिसमें इसे सेट किया गया था।
   2. जैसे localStorage, यह समान-मूल नीति पर काम करता है । तो, संग्रहीत डेटा केवल उसी मूल पर उपलब्ध होगा।

क्रॉस-ऑरिजिनल ब्राउज़र टैब के बीच आसान संचार की सुविधा के लिए - चेकआउट ऑल- टैब्स।

Comments

कुकीज़ : " डेटा हर HTTP के लिए सर्वर को वापस भेजा जाता है "। कुछ उपयोग मामलों में (जैसे प्रमाणीकरण प्रक्रिया में) इसे एक लाभ के रूप में भी माना जा सकता है। sessionStorage : " परिवर्तन केवल प्रति विंडो (या क्रोम और फ़ायरफ़ॉक्स जैसे ब्राउज़रों में टैब) में उपलब्ध हैं "। मुझे लगता है कि इसे तैयार करना बेहतर है " परिवर्तन केवल पृष्ठ सत्र के दौरान उपलब्ध हैं "। एक पेज सत्र के लिए रहता है जब तक ब्राउज़र खुला है और पृष्ठ पुनः लोड और पुनर्स्थापित अधिक बचता (MDN से: के रूप में developer.mozilla.org/en/docs/Web/API/Window/sessionStorage )

— डेनिज़

अपडेट किया गया! धन्यवाद @DenizToprak

— सॉफ्टवार

@softvar: sessionStorage - Con 2 .: "डेटा लगातार नहीं है अर्थात विंडो / टैब बंद होने के बाद यह खो जाएगा।" - यह निश्चित रूप से एक दोष नहीं है। मैं कहूंगा कि यह एक फायदा है। यह सब के बाद "सत्र" भंडारण है। यह उस तरह से काम करने के लिए बनाया गया है।

— विचलनकर्ता dev

@devstructor हाँ, आप सही हैं। मैंने इसे स्थानीय रूप से कुछ डेटा संग्रहीत करने के संदर्भ में सोचा था। उत्तर को अद्यतन किया है। यह बात बताने के लिए धन्यवाद।

— सॉफ्टवार

Answer 3

ठीक है, लोकलस्टोरेज , क्योंकि इसे आपके ब्राउज़र के लिए लोकल स्टोरेज कहा जाता है, यह 10MB तक की बचत कर सकता है , SessionStorage भी ऐसा ही करता है, लेकिन जैसा कि यह नाम कह रहा है, यह सत्र आधारित है और आपके ब्राउज़र को बंद करने के बाद हटा दिया जाएगा, लोकलस्टोरेज से भी कम बचा सकता है। 5MB तक पसंद है , लेकिन कुकीज़ आपके ब्राउज़र में बहुत छोटे डेटा स्टोर कर रहे हैं, जो 4KB को बचा सकते हैं और सर्वर या ब्राउज़र दोनों के माध्यम से एक्सेस किया जा सकता है ...

मैंने एक नज़र में अंतर दिखाने के लिए नीचे की छवि भी बनाई:

Answer 4

ये जावास्क्रिप्ट में 'विंडो' ऑब्जेक्ट के गुण हैं, जैसे दस्तावेज़ विंडो ऑब्जेक्ट की एक संपत्ति है जो डोम ऑब्जेक्ट्स को रखती है।

सेशन स्टोरेज प्रॉपर्टी प्रत्येक दिए गए मूल के लिए एक अलग स्टोरेज एरिया बनाए रखती है जो पेज सेशन की अवधि के लिए उपलब्ध है यानी जब तक ब्राउजर खुला रहता है, जिसमें पेज रीलोड और रीस्टोर शामिल हैं।

लोकल स्टोरेज वही काम करता है, लेकिन ब्राउजर के बंद होने और फिर से खोलने पर भी कायम रहता है।

आप संग्रहीत डेटा को निम्नानुसार सेट और पुनर्प्राप्त कर सकते हैं:

sessionStorage.setItem('key', 'value');

var data = sessionStorage.getItem('key');

इसी तरह लोकलस्टोरीज के लिए।

Comments

बस जोड़ने के लिए - sessionStorageयहां तक ​​कि एक नया टैब एक नई विंडो है। तो एक टैब में एक विशिष्ट डोमेन के लिए संग्रहीत कुछ भी अगले टैब में उसी डोमेन के लिए उपलब्ध नहीं होगा।

— RBT

Answer 5

स्थानीय भंडारण: यह उपयोगकर्ता की जानकारी के डेटा को समाप्ति तिथि के बिना संग्रहीत करता है यह डेटा तब नहीं हटाया जाएगा जब उपयोगकर्ता ब्राउज़र विंडो बंद कर देगा, यह दिन, सप्ताह, महीने और वर्ष के लिए उपलब्ध होगा।

लोकल स्टोरेज में 5-10mb ऑफलाइन डाटा स्टोर कर सकते हैं।

//Set the value in a local storage object
localStorage.setItem('name', myName);

//Get the value from storage object
localStorage.getItem('name');

//Delete the value from local storage object
localStorage.removeItem(name);//Delete specifice obeject from local storege
localStorage.clear();//Delete all from local storege

सत्र संग्रहण: यह लोकल स्टोरेज डेट की तरह ही है, सिवाय इसके कि जब कोई वेब यूजर द्वारा ब्राउजर विंडो को बंद किया जाता है तो वह सभी विंडो को डिलीट कर देगा।

सत्र में भंडारण 5 एमबी डेटा तक स्टोर कर सकता है

//set the value to a object in session storege
sessionStorage.myNameInSession = "Krishna";

अधिवेशन : एक सत्र सर्वर पर संग्रहीत एक वैश्विक चर है। प्रत्येक सत्र को एक अद्वितीय आईडी दी जाती है जिसका उपयोग संग्रहीत मूल्यों को प्राप्त करने के लिए किया जाता है।

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

Answer 6

वेब स्टोरेज एपीआई तंत्र प्रदान करता है जिसके द्वारा ब्राउज़र कुकीज़ का उपयोग करने की तुलना में बहुत अधिक सहज तरीके से कुंजी / मूल्य जोड़े को सुरक्षित रूप से संग्रहीत कर सकते हैं। वेब संग्रहण एपीआई फैली Windowदो नए गुणों के साथ वस्तु - Window.sessionStorageऔर Window.localStorage। - इनमें से किसी एक को संग्रहित करने से स्टोरेज ऑब्जेक्ट का एक उदाहरण बन जाएगा, जिसके माध्यम से डेटा आइटम सेट, पुनर्प्राप्त और निकाले जा सकते हैं। एक भिन्न संग्रहण ऑब्जेक्ट का उपयोग प्रत्येक मूल (डोमेन) के लिए sessionStorageऔर उसके localStorageलिए किया जाता है ।

स्टोरेज ऑब्जेक्ट्स के समान सरल की-वैल्यू स्टोर हैं, लेकिन वे पेज लोड के माध्यम से बरकरार रहते हैं ।

localStorage.colorSetting = '#a4509b';
localStorage['colorSetting'] = '#a4509b';
localStorage.setItem('colorSetting', '#a4509b');

कुंजी और मूल्य हमेशा तार होते हैं । किसी भी प्रकार को स्टोर करने के लिएconvert it to Stringऔर फिर इसे स्टोर करें। यह हमेशाStorage interfaceतरीकोंका उपयोग करने के लिए अनुशंसित है।

var testObject = { 'one': 1, 'two': 2, 'three': 3 };
// Put the object into storage
localStorage.setItem('testObject', JSON.stringify(testObject));
// Retrieve the object from storage
var retrievedObject = localStorage.getItem('testObject');
console.log('Converting String to Object: ', JSON.parse(retrievedObject));

वेब स्टोरेज के भीतर दो तंत्र इस प्रकार हैं:

• sessionStorage प्रत्येक दिए गए मूल के लिए एक अलग भंडारण क्षेत्र रखता है ^{वही-मूल नीति} जो पृष्ठ सत्र की अवधि के लिए उपलब्ध है (जब तक ब्राउज़र खुला है, जिसमें पृष्ठ रीलोड और पुनर्स्थापना शामिल है)।
• लोकलस्टोरेज भी यही काम करता है, लेकिन ब्राउजर के बंद होने और फिर से खुलने पर भी यह बना रहता है।

भंडारण « स्थानीय भंडारण डेटा को डिस्क पर लिखता है, जबकि सत्र भंडारण डेटा को केवल मेमोरी में लिखता है। सत्र संग्रहण में लिखा गया कोई भी डेटा आपके ऐप से बाहर निकलने पर शुद्ध हो जाता है।

अधिकतम भंडारण उपलब्ध ब्राउज़र प्रति अलग है , लेकिन अधिकांश ब्राउज़र को लागू किया है कम से कम W3C की अधिकतम संग्रहण सीमा की सिफारिश की 5MB ।

+----------------+--------+---------+-----------+--------+
|                | Chrome | Firefox | Safari    |  IE    |
+----------------+--------+---------+-----------+--------+
| LocalStorage   | 10MB   | 10MB    | 5MB       | 10MB   |
+----------------+--------+---------+-----------+--------+
| SessionStorage | 10MB   | 10MB    | Unlimited | 10MB   |
+----------------+--------+---------+-----------+--------+

हमेशा लोकलस्टोरेज सिक्योरिटी और कोटा से अधिक की त्रुटियों को पकड़ें

• QuotaExceededError : जब इस फ़ंक्शन पर संग्रहण सीमाएँ अधिक हो जाती हैं window.sessionStorage.setItem(key, value);, तो यह "QuotaExceededError" DOMException अपवाद फेंकता है यदि नया मान सेट नहीं किया जा सकता है। (सेटिंग विफल हो सकती है, उदाहरण के लिए, उपयोगकर्ता ने साइट के लिए भंडारण को अक्षम कर दिया है, या यदि कोटा पार हो गया है।)

  DOMException। QUOTA_EXCEEDED_ERR 22 है , उदाहरण फिडल ।

• SecurityError :Uncaught SecurityError: Access to 'localStorage' is denied for this document।

  CHROME:-Privacy and security « Content settings « Cookies « Block third-party cookies.

StorageEvent «भंडारण घटना एक दस्तावेज़ की विंडो ऑब्जेक्ट पर निकाल दिया जाता है जब एक भंडारण क्षेत्र बदलता है। जब कोई उपयोगकर्ता एजेंट किसी दस्तावेज़ के लिए संग्रहण सूचना भेजता है, तो उपयोगकर्ता एजेंट को StorageEvent का उपयोग करके दस्तावेज़ ऑब्जेक्ट की विंडो ऑब्जेक्ट में संग्रहण नामक एक घटना को फायर करने के लिए कार्य को कतारबद्ध करना होगा।

नोट: एक वास्तविक दुनिया उदाहरण के लिए, वेब स्टोरेज डेमो देखें ।^{स्रोत कोड देखें}

स्टोरेज में परिवर्तन को पकड़ने के लिए डोम / विंडो पर स्टोरेज इवेंट को सुनें। बेला ।

---

कुकीज़ (वेब कुकी, ब्राउज़र कुकी) कुकीज़ डेटा हैं, जो आपके कंप्यूटर पर नाम-मूल्य जोड़े के रूप में छोटी पाठ फ़ाइलों में संग्रहीत हैं।

Document.cookie का उपयोग करके जावास्क्रिप्ट का उपयोग

डॉक्यूमेंट.कोकी प्रॉपर्टी का उपयोग करके जावास्क्रिप्ट के माध्यम से नई कुकीज़ भी बनाई जा सकती हैं, और अगर HttpOnly ध्वज सेट नहीं है, तो मौजूदा कुकीज़ को जावास्क्रिप्ट से भी एक्सेस किया जा सकता है।

document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

सुरक्षित और HttpOnly कुकीज़ ^{HTTP राज्य प्रबंधन तंत्र}

उपयोगकर्ता और उनके प्रमाणित सत्र की पहचान करने के लिए कुकीज़ का उपयोग अक्सर वेब एप्लिकेशन में किया जाता है

HTTP अनुरोध प्राप्त करते समय, एक सर्वर प्रतिक्रिया के साथ सेट-कुकी हेडर भेज सकता है । कुकी आमतौर पर ब्राउज़र द्वारा संग्रहीत की जाती है, और फिर कुकी को HTTP HTTP हेडर के अंदर एक ही सर्वर पर किए गए अनुरोधों के साथ भेजा जाता है।

Set-Cookie: <cookie-name>=<cookie-value> 
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

जब क्लाइंट बंद हो जाता है तो सत्र कुकीज निकाल दी जाएंगी। वे समयसीमा या अधिकतम-आयु निर्देशों को निर्दिष्ट नहीं करते हैं।

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

स्थायी कुकीज़ एक विशिष्ट तिथि (समय सीमा) या एक विशिष्ट लंबाई (अधिकतम-आयु) के बाद समाप्त हो जाती हैं।

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

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

कुकीज़ मुख्य रूप से तीन उद्देश्यों के लिए उपयोग की जाती हैं:

• सत्र प्रबंधन «लॉगिन, शॉपिंग कार्ट, गेम स्कोर, या कुछ और जो सर्वर को याद रखना चाहिए
• वैयक्तिकरण «उपयोगकर्ता की प्राथमिकताएँ, थीम और अन्य सेटिंग्स
• ट्रैकिंग (रिकॉर्डिंग और उपयोगकर्ता व्यवहार का विश्लेषण) «कुकीज़ उनके पास एक डोमेन है। यदि यह डोमेन आपके द्वारा जारी किए गए पृष्ठ के डोमेन के समान है, तो कुकीज़ को प्रथम-पक्ष कुकी कहा जाता है। यदि डोमेन अलग है, तो इसे तृतीय-पक्ष कुकी कहा जाता है। जबकि प्रथम-पक्ष कुकीज़ केवल उन्हें सेट करने वाले सर्वर पर भेजी जाती हैं, एक वेब पेज में अन्य डोमेन (जैसे विज्ञापन बैनर) में सर्वर पर संग्रहीत चित्र या अन्य घटक हो सकते हैं। कुकीज़ जो इन तृतीय-पक्ष घटकों के माध्यम से भेजी जाती हैं, उन्हें तृतीय-पक्ष कुकीज़ कहा जाता है और मुख्य रूप से वेब पर विज्ञापन और ट्रैकिंग के लिए उपयोग किया जाता है।

"उपयोगकर्ता के बारे में जानकारी कैसे याद रखें" समस्या को हल करने के लिए कुकीज़ का आविष्कार किया गया था:

• जब कोई उपयोगकर्ता किसी वेब पेज पर जाता है, तो उसका नाम कुकी में संग्रहीत किया जा सकता है।
• अगली बार जब उपयोगकर्ता पृष्ठ पर जाता है, तो पृष्ठ से संबंधित कुकीज़ अनुरोध में जोड़ी जाती हैं। इस तरह से सर्वर को उपयोगकर्ताओं के बारे में जानकारी "याद" करने के लिए आवश्यक डेटा मिल जाता है।

GitHubGist उदाहरण

---

सारांश के रूप में,

• LocalStorage विभिन्न टैब या विंडो पर बना रहता है, और भले ही हम ब्राउज़र को बंद करें, तदनुसार डोमेन सुरक्षा नीति और उपयोगकर्ता विकल्प कोटा सीमा के बारे में।
• यदि हम टैब (शीर्ष-स्तरीय ब्राउज़िंग संदर्भ) को बंद करते हैं तो सत्रस्टेजेज वस्तु बनी नहीं रहती है क्योंकि यदि हम किसी अन्य टैब या विंडो के माध्यम से सर्फ करते हैं तो यह मौजूद नहीं है।
• वेब संग्रहण (सत्र, स्थानीय) हमें कुंजी / मूल्य जोड़े और बहुत सारे पाठ को बचाने की अनुमति देता है, कुकी के माध्यम से कुछ असंभव है।
• कुकीज़ जो संवेदनशील कार्यों के लिए उपयोग की जाती हैं, उनका जीवनकाल कम ही होना चाहिए।
• कुकीज़ मुख्य रूप से वेब पर विज्ञापन और ट्रैकिंग के लिए उपयोग की जाती है। उदाहरण के लिए Google द्वारा उपयोग की जाने वाली कुकीज़ के प्रकार देखें ।
• कुकीज़ हर अनुरोध के साथ भेजे जाते हैं, इसलिए वे प्रदर्शन को खराब कर सकते हैं (विशेषकर मोबाइल डेटा कनेक्शन के लिए)। क्लाइंट स्टोरेज के लिए आधुनिक एपीआई वेब स्टोरेज एपीआई (लोकलस्टोरेज और सेशनस्टोरेज) और इंडेक्सडीडीबी हैं।

Answer 7

स्थानीय स्तर :

• वेब स्टोरेज को कुकीज़ पर सुधार के रूप में सरलता से देखा जा सकता है, जिससे भंडारण क्षमता अधिक हो जाती है। उपलब्ध आकार 5 एमबी है जो एक विशिष्ट 4KB कुकी की तुलना में काम करने के लिए काफी अधिक स्थान है।

• हर HTTP अनुरोध (HTML, चित्र, जावास्क्रिप्ट, सीएसएस, आदि) के लिए डेटा को सर्वर पर वापस नहीं भेजा जाता है - क्लाइंट और सर्वर के बीच यातायात की मात्रा को कम करता है।

• स्थानीयस्टोरेज में संग्रहीत डेटा स्पष्ट रूप से हटाए जाने तक बना रहता है। किए गए परिवर्तन सहेजे गए हैं और साइट पर सभी वर्तमान और भविष्य की यात्राओं के लिए उपलब्ध हैं।

• यह समान-मूल नीति पर काम करता है। तो, संग्रहीत डेटा केवल उसी मूल पर उपलब्ध होगा।

कुकीज़:

• हम प्रत्येक कुकी के लिए समाप्ति समय निर्धारित कर सकते हैं

• 4K कुकी संपूर्ण कुकी के लिए है, जिसमें नाम, मान, समाप्ति तिथि आदि शामिल हैं। अधिकांश ब्राउज़रों का समर्थन करने के लिए, नाम को 4000 बाइट्स और 4093 बाइट्स के तहत समग्र कुकी आकार के अंतर्गत रखें।

• डेटा को हर HTTP अनुरोध (HTML, चित्र, जावास्क्रिप्ट, सीएसएस, आदि) के लिए सर्वर पर वापस भेजा जाता है - क्लाइंट और सर्वर के बीच यातायात की मात्रा में वृद्धि।

sessionStorage:

• यह लोकलस्टोरेज के समान है।

• परिवर्तन केवल प्रति विंडो (या क्रोम और फ़ायरफ़ॉक्स जैसे ब्राउज़र में टैब) उपलब्ध हैं। किए गए परिवर्तन वर्तमान पृष्ठ के लिए सहेजे जाते हैं और उपलब्ध होते हैं, साथ ही भविष्य की साइट पर उसी विंडो पर जाते हैं। एक बार विंडो बंद होने के बाद, स्टोरेज डिलीट हो जाता है। डेटा केवल उस विंडो / टैब के अंदर उपलब्ध होता है, जिसमें इसे सेट किया गया था।

• डेटा लगातार नहीं है यानी विंडो / टैब बंद होने के बाद यह खो जाएगा। स्थानीयस्टोरेज की तरह, यह समान-मूल नीति पर काम करता है। तो, संग्रहीत डेटा केवल उसी मूल पर उपलब्ध होगा।

Answer 8

यहाँ एक त्वरित समीक्षा है और एक सरल और त्वरित समझ के साथ

Freecodecamp के शिक्षक ब्यू कार्नेस से