2011-06-20 13 views
7

कुकीज़ बहुत अच्छी हैं क्योंकि वेबसाइट.com में लिखा गया मान www.website.com (www को नो-www का एक सूडोमेन माना जाता है) में उपयोग किया जा सकता है। नकारात्मकता सर्वर के प्रत्येक HTTP अनुरोध के साथ सभी कुकी मान भेजे जाते हैं। तो मैं जावास्क्रिप्ट को मूल रूप से उपलब्ध स्थानीय स्टोरेज तंत्र की तलाश में हूं जो क्रॉस-सबडोमेन का काम करता है और सर्वर पर प्रेषित नहीं होता है। क्या ऐसा तंत्र मौजूद है? LocalStorage क्रॉस-सबडोमेन काम नहीं करता है और Flash Cookies आईफोन पर काम नहीं करेगा।कुकीज केवल मूल क्रॉस-सबडोमेन स्टोरेज हैं?

+0

आपको कितना संग्रहण चाहिए? यदि यह अधिक नहीं है, और आप एक पीआरजी पैटर्न (पोस्ट, रेडियरेक्ट, जीईटी) का उपयोग कर रहे हैं, तो केवल पृष्ठ पर आपको आवश्यक डेटा को जारी रखें, और उसके बाद पेज से आपको जो भी डेटा चाहिए, उसे पोस्ट करें। –

+0

आप कैसे क्रॉस-डोमेन देख रहे हैं? स्थानीय स्टोरेज का समर्थन नहीं करने वाले आपको कौन से ब्राउज़र का समर्थन करने की आवश्यकता है? –

+0

@ रॉवर्ट हार्वे: यह बड़ी मात्रा में डेटा है: प्राथमिकताएं, लॉगिन स्थिति, हाल की गतिविधि। मैं गैर-महत्वपूर्ण डेटा के लिए सर्वर से पूछताछ से नफरत करता हूं, इसलिए मैं इसे स्थानीय रूप से स्टोर करना चाहता हूं। /// @ जेम्स ब्लैक: अब तक, मुझे वही मान साझा करने के लिए केवल ** www ** और ** गैर-www ** की आवश्यकता है। मेरा मानना ​​है कि यह एक खराब उपयोगकर्ता अनुभव है जब कोई उपयोगकर्ता ** गैर-www ** पर कुछ करता है, फिर ** www ** पर जाएं और उनकी सभी प्राथमिकताओं को मिटा दें। मेरा लक्ष्य कुकीज़ का उपयोग बंद करने के लिए आधुनिक ब्राउज़रों को अपग्रेड करना है, लेकिन जब कोई पुराना ब्राउज़र इस नए स्टोरेज तंत्र का समर्थन नहीं करता है तो कुकीज़ पर फ़ॉलबैक होता है। इस प्रकार मेरे सर्वर हिट – JoJo

उत्तर

3

शायद वेबसाइट.com को www.website.com पर रीडायरेक्ट करें या इसके विपरीत? ऐसा लगता है कि यह सबसे आसान तय होगा। http://www.scriptalicious.com/blog/2009/04/redirecting-www-to-non-www-using-htaccess/

+0

ऐसा करने का प्रदर्शन प्रभाव क्या है? – JoJo

+1

उन उपयोगकर्ताओं के लिए एक ही अनुरोध-प्रतिक्रिया अधिक है जिन्हें पुनर्निर्देशित करने की आवश्यकता है। http://en.wikipedia.org/wiki/HTTP_301 उपयोगकर्ता इसे भी नोटिस नहीं करेंगे। – devictories

1

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

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

  1. हमेशा www.domain.com पर रीडायरेक्ट करें ताकि सभी उपयोगकर्ता गतिविधि एक ही डोमेन पर हो।
  2. उपलब्ध होने पर HTML5 स्थानीय संग्रहण का उपयोग करें (चरण 1 में रीडायरेक्ट उप डोमेन लॉकआउट को रोकता है)।
  3. एचटीएमएल 5 स्थानीय भंडारण उपलब्ध नहीं होने पर कुकी स्टोरेज पर वापस आना।

कोई एचटीएमएल 5 स्थानीय स्टोरेज और कुकीज़ के लिए संभवतया लिखने या खोजने के लिए संभवतः लिख सकता है, तो आपके 99% कोड स्वतंत्र रूप से उपयोग किए जा रहे भंडारण तंत्र से स्वतंत्र हो सकते हैं। ऐसा लगता है कि कुछ jQuery प्लगइन्स हैं जो ठीक उसी तरह करते हैं।

संबंधित मुद्दे