कुकी में स्टोर आईडी

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

संदेह!

सत्र को संग्रहीत करने के लिए डेटाबेस का उपयोग करने की उपयुक्तता के बारे में संदेह। सत्र जिसमें केवल कुछ तत्व हैं - उपयोगकर्ता आईडी और इसकी भूमिका। और यहां तक ​​कि सिर्फ एडमिन आईडी है। नेटवर्क ओवरहेड, नई इकाइयाँ, और CAP प्रमेय आपको परेशान करते हैं। हर रात, आप एक ही दुःस्वप्न से ग्रस्त होते हैं - मेमकेच्ड शब्द में अक्षर B को मत भूलना ... सभी, चलो पहले से ही एक विकल्प पर विचार करते हैं - क्लाइंट आईडी को उसके पक्ष में, कुकीज़ में संग्रहीत करना।

तो, समस्या का बयान। तो वह

• scalability
• सुरक्षित रूप से
• जल्दी से
• केवल

लेखक संक्षिप्तता का सम्मान करता है और बहुत ही स्वतंत्र रूप से सिद्धांत को लागू करता है "आदेश और विकार मात्रा का मामला है।"

निर्णय

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

पेशेवरों और विपक्ष

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

अब हम सुरक्षा में सुधार करेंगे। हम कुक जीवनकाल को 0. सेट करते हैं, फिर अगली बार ब्राउज़र को बंद करने से सार्वजनिक कुंजी का पुनर्जनन होगा। डिक्रिप्शन को जटिल करने के लिए, हम "बिट" एल्गोरिथ्म को 256 बिट्स की कुंजी के साथ लागू करते हैं। इसके बाद, सार्वजनिक कुंजी को क्लाइंट IP से बांधें। उदाहरण के लिए, md5 और MCRYPT_RIJNDAEL_256 के लिए एक दूसरे के पूरक हैं:

$secret = md5(md5('My secret key') . md5($_SERVER['REMOTE_ADDR'])); 

क्रिप्टोनालिसिस के लिए एक आधार बनाने के खिलाफ, हम हर असफल लॉगिन प्रयास के लिए स्लीप कमांड का उपयोग करते हैं। सुरक्षा गार्ड मरने की जगह ले सकते हैं और खाते के साथ आईपी को ब्लॉक कर सकते हैं। एक हेलीकाप्टर भेजें ...

सिमेट्रिक एनक्रिप्शन नेटवर्क कनेक्टिविटी की तुलना में तेज है। आप एक विधर्मी हैं यदि आप आधार को खींचते हैं, यहां तक ​​कि स्थानीय, रैम में, यहां तक ​​कि एक स्थायी कनेक्शन के साथ या सॉकेट के माध्यम से, हर क्लिक के साथ जब आप ऐसा नहीं कर सकते। "नमस्ते,% ID%" हम बिना ओवरहेड के तुरंत दिखा सकते हैं।

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

अधिक कोड की आवश्यकता है!

Zend फ्रेमवर्क 1.x के लिए वर्ग जो प्रामाणिक कुकी संग्रहण को लागू करता है । यहां तक ​​कि अगर आप उच्च भार पर जेडएफ का उपयोग नहीं करते हैं (हम्म, किसी कारण से लेखक इस बारे में निश्चित है), तो आपके पसंदीदा फ्रेमवर्क या सेशन_सेट_सैव_हैंडलर में सिद्धांत को समझने और पुन: पेश करने के लिए मध्यम ईडीई हाथ की जेडी के लिए कोड की सौ पंक्तियाँ पर्याप्त हैं।

मंगलवार। लेखक कहीं भी किसी भी त्रुटि के लिए आभारी होगा।