क्या होगा यदि आपका Rails ऐप यह नहीं बता सकता कि कौन इसे देख रहा है? अगर आपको पता नहीं था कि वही व्यक्ति दो अलग-अलग पेजों का अनुरोध कर रहा है? अगर आपके द्वारा संग्रहीत सभी डेटा प्रतिक्रिया वापस करते ही गायब हो गए?
यह ज्यादातर स्टैटिक साइट के लिए ठीक हो सकता है। लेकिन अधिकांश ऐप्स को उपयोगकर्ता के बारे में कुछ डेटा स्टोर करने में सक्षम होने की आवश्यकता होती है। शायद यह एक यूजर आईडी है, या एक पसंदीदा भाषा, या क्या वे हमेशा अपने आईपैड पर आपकी साइट का डेस्कटॉप संस्करण देखना चाहते हैं।
session इस तरह के डेटा को रखने के लिए एकदम सही जगह है। छोटे-छोटे डेटा के टुकड़े जिन्हें आप एक से अधिक अनुरोध के लिए रखना चाहते हैं।
सत्र उपयोग करने में आसान हैं:
session[:current_user_id] = @user.idलेकिन वे थोड़े जादुई हो सकते हैं। सत्र क्या है? Rails कैसे जानता है कि सही डेटा सही व्यक्ति को दिखाए? और आप कैसे तय करते हैं कि आप अपना सत्र डेटा कहां रखते हैं?
सत्र क्या है?
एक सत्र केवल एक अनुरोध के दौरान डेटा स्टोर करने की एक जगह है जिसे आप बाद के अनुरोधों के दौरान पढ़ सकते हैं।
आप एक कंट्रोलर एक्शन में कुछ डेटा सेट कर सकते हैं:
app/controllers/sessions_controller.rb def create # ... session[:current_user_id] = @user.id # ... endऔर इसे दूसरे में पढ़ें:
app/controllers/users_controller.rb def index current_user = User.find_by_id(session[:current_user_id]) # ... endयह उतना दिलचस्प नहीं लग सकता। लेकिन आपके उपयोगकर्ता के ब्राउज़र और आपके Rails ऐप के बीच समन्वय की आवश्यकता होती है ताकि सब कुछ जुड़ जाए। और यह सब कुकीज़ से शुरू होता है।
जब आप एक वेबपेज का अनुरोध करते हैं, तो सर्वर प्रतिक्रिया देते समय एक कुकी सेट कर सकता है:
~ jweiss$ curl -I https://www.google.com | grep Set-Cookie Set-Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-nVyaoejz-4K6aouUQtyp5B_rK3Z7G-EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnlyआपका ब्राउज़र उन कुकीज़ को स्टोर करेगा। और जब तक कुकी समाप्त नहीं होती, हर बार जब आप अनुरोध करते हैं, तो आपका ब्राउज़र कुकीज़ को सर्वर पर वापस भेज देगा:
... > GET / HTTP/1.1 > User-Agent: curl/7.37.1 > Host: www.google.com > Accept: */* > Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-nVyaoejz-4K6aouUQtyp5B_rK3Z7G-EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnly ...कई कुकीज़ सिर्फ बकवास जैसी दिखती हैं। और उन्हें ऐसा ही होना चाहिए। क्योंकि कुकी के अंदर की जानकारी उपयोगकर्ता के लिए नहीं है। आपका Rails ऐप यह पता लगाने का प्रभारी है कि कुकी का क्या मतलब है। आपका ऐप इसे सेट करता है, इसलिए आपका ऐप इसे पढ़ सकता है।
इसका सत्र से क्या लेना-देना है?
तो, आपके पास एक कुकी है। आप एक अनुरोध में डेटा डालते हैं, और आपको अगले में वही डेटा मिलता है। इसके और सत्र के बीच क्या अंतर है?
डिफ़ॉल्ट रूप से, Rails में, ज्यादा अंतर नहीं है। Rails कुकी के साथ कुछ काम करता है ताकि यह अधिक सुरक्षित हो। लेकिन इसके अलावा, यह उसी तरह काम करता है जैसा आप उम्मीद करेंगे। आपका Rails ऐप कुकी में कुछ डेटा डालता है, वही डेटा कुकी से बाहर आता है। अगर बस इतना ही होता, तो सत्र को कुकीज़ से अलग करने का कोई कारण नहीं होता।
लेकिन कुकीज़ हमेशा सत्र डेटा के लिए सही उत्तर नहीं हैं:
आप कुकी में केवल लगभग 4kb डेटा स्टोर कर सकते हैं।
यह आमतौर पर पर्याप्त है, लेकिन कभी-कभी यह नहीं है।
कुकीज़ आपके द्वारा किए जाने वाले हर अनुरोध के साथ भेजी जाती हैं।
बड़ी कुकीज़ का मतलब बड़े अनुरोध और प्रतिक्रियाएं हैं, जिसका मतलब धीमी वेबसाइटें हैं।
यदि आप गलती से अपना
secret_key_baseउजागर कर देते हैं, तो आपके उपयोगकर्ता आपके द्वारा अपनी कुकी के अंदर रखे गए डेटा को बदल सकते हैं।जब इसमें
current_user_idजैसी चीजें शामिल होती हैं, तो कोई भी वह उपयोगकर्ता बन सकता है जो वे चाहते हैं!गलत प्रकार का डेटा कुकी के अंदर स्टोर करना असुरक्षित हो सकता है।
यदि आप सावधान हैं, तो ये बड़ी समस्याएं नहीं हैं।
लेकिन जब आप इन कारणों में से एक के लिए अपनी सत्र डेटा को कुकी के अंदर स्टोर नहीं कर सकते, तो Rails के पास आपके सत्रों को रखने के लिए कुछ अन्य स्थान हैं:
वैकल्पिक सत्र स्टोर
कुकी सत्र स्टोर नहीं होने वाले सभी सत्र स्टोर बहुत अधिक उसी तरह काम करते हैं। लेकिन एक वास्तविक उदाहरण का उपयोग करके इसके बारे में सोचना सबसे आसान है।
यदि आप ActiveRecord के साथ अपने सत्रों का ट्रैक रख रहे थे:
जब आप अपने ऐप में
session[:current_user_id] = 1कॉल करते हैं, और एक सत्र पहले से मौजूद नहीं है:Rails आपके
sessionsटेबल में एक रैंडम सत्र आईडी (मान लें,09497d46978bf6f32265fefb5cc52264) के साथ एक नया रिकॉर्ड बनाएगा।यह
{current_user_id: 1}(Base64-एन्कोडेड) को उस रिकॉर्ड केdataविशेषता में स्टोर करेगा।और यह जेनरेटेड सत्र आईडी,
09497d46978bf6f32265fefb5cc52264, को ब्राउज़र कोSet-Cookieका उपयोग करके वापस करेगा।
अगली बार जब आप एक पेज का अनुरोध करते हैं,
ब्राउज़र उस कुकी को आपके ऐप को
Cookie:हेडर का उपयोग करके भेजता है।(इस तरह:
Cookie: _my_app_session=09497d46978bf6f32265fefb5cc52264;
path=/; HttpOnly)जब आप
session[:current_user_id]कॉल करते हैं:आपका ऐप आपकी कुकी से सत्र आईडी निकालता है, और
sessionsटेबल में उसका रिकॉर्ड ढूंढता है।फिर, यह उस रिकॉर्ड के
dataविशेषता सेcurrent_user_idवापस करता है।
चाहे आप सत्रों को डेटाबेस में, Memcached में, Redis में, या कहीं और स्टोर कर रहे हों, वे ज्यादातर इसी प्रक्रिया का पालन करते हैं। आपकी कुकी केवल एक सत्र आईडी रखती है, और आपका Rails ऐप उस आईडी का उपयोग करके आपके सत्र स्टोर में डेटा देखता है।
कुकी स्टोर, कैश स्टोर, या डेटाबेस स्टोर?
जब यह काम करता है, तो अपने सत्रों को कुकीज़ में स्टोर करना अब तक का सबसे आसान तरीका है। इसे किसी अतिरिक्त बुनियादी ढांचे या सेटअप की आवश्यकता नहीं है।
लेकिन अगर आपको कुकी सत्र स्टोर से आगे बढ़ने की आवश्यकता है, तो आपके पास दो विकल्प हैं:
सत्रों को डेटाबेस में स्टोर करें, या उन्हें अपने कैश में स्टोर करें।
कैश में सत्र स्टोर करना
आप पहले से ही अपने पार्शियल या डेटा को कैश करने के लिए Memcache जैसी किसी चीज़ का उपयोग कर रहे होंगे। यदि हां, तो कैश स्टोर सत्र डेटा स्टोर करने के लिए दूसरी सबसे आसान जगह है, क्योंकि यह पहले से ही सेट अप है।
आपको अपने सत्र स्टोर के नियंत्रण से बाहर होने की चिंता करने की ज़रूरत नहीं है, क्योंकि पुराने सत्र स्वचालित रूप से कैश से बाहर निकल जाएंगे अगर यह बहुत बड़ा हो जाता है। और यह तेज़ है, क्योंकि आपका कैश सबसे अधिक संभावना मेमोरी में रखा जाएगा।
लेकिन यह सही नहीं है:
यदि आप वास्तव में पुराने सत्रों को रखने की परवाह करते हैं, तो आप शायद नहीं चाहते कि वे कैश से बाहर निकलें।
आपके सत्र और आपका कैश्ड डेटा स्थान के लिए लड़ेंगे। यदि आपके पास पर्याप्त मेमोरी नहीं है, तो आप कैश मिस और जल्दी समाप्त हुए सत्रों का एक टन सामना कर सकते हैं।
यदि आपको कभी अपना कैश रीसेट करने की आवश्यकता होती है (मान लें कि आपने Rails अपग्रेड किया और आपका पुराना कैश्ड डेटा अब सटीक नहीं है), तो हर किसी के सत्रों को समाप्त किए बिना ऐसा करने का कोई तरीका नहीं है।
फिर भी, हम Avvo में सत्र डेटा को इसी तरह स्टोर करते हैं, और यह अब तक हमारे लिए अच्छा काम कर रहा है।
डेटाबेस में सत्र स्टोर करना
यदि आप अपने सत्र डेटा को तब तक रखना चाहते हैं जब तक यह वैध रूप से समाप्त नहीं हो जाता, तो आप शायद इसे किसी प्रकार के डेटाबेस में रखना चाहेंगे। चाहे वह Redis हो, ActiveRecord, या कुछ और।
लेकिन डेटाबेस सत्र स्टोरेज की भी कमियां हैं:
कुछ डेटाबेस स्टोर के साथ, आपके सत्र स्वचालित रूप से साफ नहीं होंगे।
इसलिए आपको स्वयं समाप्त सत्रों को साफ करना होगा।
आपको यह जानना होगा कि आपका डेटाबेस सत्र डेटा से भरा होने पर कैसे व्यवहार करेगा।
क्या आप अपने सत्र स्टोर के रूप में Redis का उपयोग कर रहे हैं? क्या यह आपके सभी सत्र डेटा को मेमोरी में रखने की कोशिश करेगा? क्या आपके सर्वर में इसके लिए पर्याप्त मेमोरी है, या यह इतना बुरी तरह से स्वैप करना शुरू कर देगा कि आप इसे ठीक करने के लिए
sshभी नहीं कर पाएंगे?आपको इस बारे में अधिक सावधान रहना होगा कि आप सत्र डेटा कब बनाते हैं, या आप अपने डेटाबेस को बेकार सत्रों से भर देंगे।
उदाहरण के लिए, यदि आप गलती से हर अनुरोध पर सत्र को छूते हैं, तो googlebot सैकड़ों हजारों बेकार सत्र बना सकता है। और वह बुरा समय होगा।
इनमें से अधिकांश समस्याएं काफी दुर्लभ हैं। लेकिन आपको अभी भी उनके बारे में पता होना चाहिए।
तो आपको अपने सत्र कैसे स्टोर करने चाहिए?
अगर आप काफी निश्चित हैं कि आप कुकी स्टोर की किसी भी सीमा में नहीं चलेंगे, तो इसका उपयोग करें। इसे ज्यादा सेटअप की आवश्यकता नहीं है, और यह बनाए रखने के लिए सिरदर्द नहीं है।
कैश में सत्र स्टोर करना बनाम डेटाबेस में स्टोर करना इस बारे में एक निर्णय कॉल है कि सत्र को जल्दी समाप्त करना कितना बुरा होगा। मैं सत्र डेटा को काफी अस्थायी मानता हूं, इसलिए कैश स्टोर मेरे लिए अच्छा काम करता है। तो मैं आमतौर पर पहले कुकी, फिर कैश, फिर डेटाबेस आज़माता हूं।
लेकिन आप कैसे हैं? आप अपने सत्र कैसे स्टोर करते हैं? एक टिप्पणी छोड़ें और मुझे बताएं!
और यदि आप इस बारे में अधिक जानना चाहते हैं कि Ruby और Rails इंटर्नल कैसे काम करते हैं, तो इस लेख को देखें: How do gems work? या, यदि आप इस बारे में अधिक रुचि रखते हैं कि वेब कैसे काम करता है, तो A web server vs. an app server देखें।
