सत्र क्या हैं? वो कैसे काम करते है?

Question

मैं सिर्फ अजगर का उपयोग करके वेब अनुप्रयोग विकास सीखना शुरू कर रहा हूं। मैं 'कुकीज़' और 'सेशन' की शर्तों पर आ रहा हूँ। मैं कुकीज़ को समझता हूं कि वे ब्राउज़र पर एक महत्वपूर्ण मूल्य जोड़ी में कुछ जानकारी संग्रहीत करते हैं। लेकिन मुझे सत्रों के बारे में थोड़ा भ्रम है, एक सत्र में भी हम उपयोगकर्ता के ब्राउज़र पर एक कुकी में डेटा संग्रहीत करते हैं।

उदाहरण के लिए - मैं का उपयोग कर लॉगिन username='rasmus'और password='default'। ऐसे मामले में डेटा को सर्वर पर पोस्ट किया जाएगा जो कि प्रमाणित होने पर मुझे जांचने और लॉग इन करने वाला है। हालाँकि पूरी प्रक्रिया के दौरान सर्वर एक सत्र आईडी भी बनाता है जिसे मेरे ब्राउज़र पर कुकी में संग्रहीत किया जाएगा। अब सर्वर इस सेशन आईडी को अपने फाइल सिस्टम या डेटास्टोर में भी स्टोर करता है।

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

मैं यहां काफी भ्रमित हो रहा हूं। मदद की ज़रूरत है।

Comments

"क्या यह सर्वर पर डेटा को एक तानाशाह के रूप में संग्रहीत करता है जहां कुंजी एक सत्र आईडी होगी और उपयोगकर्ता नाम, ईमेल आदि जैसे विवरण मूल्य होंगे?" ...हाँ। 'तानाशाह' एक संबंधपरक डेटाबेस हो सकता है, लेकिन मूल रूप से यह कैसे काम करता है।

— 13

मैं वेब सत्रों को भी समझना चाहता था, अब मैं समझता हूं। मैं अपने खुद के विकि लेखन समाप्त हो गया है, तो यह है कि किसी भी मदद की है: machinesaredigging.com/2013/10/29/how-does-a-web-session-work

— eloone

यदि आपको पता नहीं है तो: क्लाइंट की ओर पासवर्ड संग्रहीत करना सुरक्षित नहीं है, भले ही पासवर्ड हैशेड हो (इससे कोई फर्क नहीं पड़ता, वास्तव में। क्रैकर सीधे नकली कुकी बनाकर हैशेड पासवर्ड इनपुट कर सकता है) लॉगिन स्थिति को संग्रहीत करने के लिए बेहतर तरीके हैं।

— सायंट्सनी

मैंने प्रोटोकॉल स्तर के विवरणों का उपयोग करके अपना स्वयं का लिखा है - बिट्सपीडिया.कॉम

— आसिफ शहजाद

Answer 1

चूँकि HTTP स्टेटलेस है, किसी अन्य अनुरोध के लिए एक अनुरोध को जोड़ने के लिए, आपको HTTP अनुरोधों के बीच उपयोगकर्ता डेटा को संग्रहीत करने के लिए एक तरीका चाहिए।

कुकीज़ या URL पैरामीटर (उदाहरण के लिए, जैसे http://example.com/myPage?asd=lol&boo=no ) 2 या अधिक अनुरोध के बीच डेटा परिवहन के लिए दोनों उपयुक्त तरीके हैं। हालाँकि, यदि आप उस डेटा को ग्राहक की ओर से पठनीय / संपादन योग्य नहीं बनाना चाहते हैं तो वे अच्छे नहीं हैं।

समाधान यह है कि डेटा सर्वर साइड को स्टोर करें, इसे "आईडी" दें, और ग्राहक को केवल उस आईडी को जाने दें (और हर http अनुरोध पर वापस पास करें)। वहाँ तुम जाओ, सत्र कार्यान्वित। या आप क्लाइंट को एक सुविधाजनक रिमोट स्टोरेज के रूप में उपयोग कर सकते हैं, लेकिन आप डेटा को एन्क्रिप्ट करेंगे और गुप्त सर्वर-साइड रखेंगे।

निश्चित रूप से विचार करने के लिए अन्य पहलू हैं, जैसे आप नहीं चाहते कि लोग दूसरे सत्रों को हाईजैक करें, आप चाहते हैं कि सत्र हमेशा के लिए न समाप्त हो, बल्कि समाप्त हो जाए, और इसी तरह।

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

Comments

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

— मैट हैरिसन

@MattHison आप "कुछ भी याद रखे" सर्वर-साइड के बिना डेटा को कैसे डिक्रिप्ट करेंगे? मैंने किसी भी तरह से इस विषय को अपने उत्तर में विस्तारित करने की कोशिश की है।

— ल्यूक404

@MattHarrison इस बात का ध्यान रखें कि ढेर सारा डेटा यूज़र-साइड स्टोर करने से आपका ट्रैफ़िक बढ़ेगा।

— नितास

क्या तीसरा पक्ष उपयोगकर्ता के रूप में कार्य करने में सक्षम नहीं होगा यदि वे उपयोगकर्ता की सत्र कुंजी को रोक सकते हैं? यह मानते हुए कि साइट HTTPS का उपयोग नहीं करती है, ऐसा लगता है कि तृतीय पक्ष उपयोगकर्ता को सत्र कुंजी के साथ संदेश भेज सकता है, भले ही कुंजी एन्क्रिप्ट की गई हो। सर्वर इसे डिक्रिप्ट करेगा।

— user137717

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

— ल्यूकहॉमी

Answer 2

सादृश्य द्वारा सरल व्याख्या

कल्पना कीजिए कि आप बैंक में हैं, अपने खाते से कुछ पैसे निकालने की कोशिश कर रहे हैं। लेकिन अंधेरा है; बैंक पिच ब्लैक है: कोई प्रकाश नहीं है और आप अपने हाथ को अपने चेहरे के सामने नहीं देख सकते हैं। आप एक और 20 लोगों से घिरे हैं। वे सभी एक ही दिखते हैं। और सबकी आवाज एक जैसी है। और हर कोई एक संभावित बुरा आदमी है। दूसरे शब्दों में, HTTP स्टेटलेस है।

यह बैंक एक मज़ेदार प्रकार का बैंक है - यहाँ तर्क के लिए कि कैसे काम करते हैं:

1. आप लाइन में प्रतीक्षा करते हैं (या ऑन-लाइन) और आप टेलर से बात करते हैं: आप पैसे वापस लेने का अनुरोध करते हैं, और फिर
2. आपको सोफे पर कुछ समय इंतजार करना होगा, और 20 मिनट बाद
3. आपको जाना है और वास्तव में टेलर से अपना पैसा इकट्ठा करना है।

लेकिन कैसे बताएगा आप सभी के अलावा अन्य लोगों से?

बताने वाला आपको देख नहीं सकता या आसानी से पहचान नहीं सकता, याद रखें, क्योंकि रोशनी बिल्कुल बाहर है। क्या होगा यदि आपका टेलर किसी और को - गलत व्यक्ति को आपकी $ 10,000 की निकासी देता है ?! यह बिल्कुल महत्वपूर्ण है कि टेलर आपको उस व्यक्ति के रूप में पहचान सकता है जिसने निकासी की थी, ताकि आप उस धन (या संसाधन) को प्राप्त कर सकें जो आपने माँगा था।

समाधान:

जब आप पहली बार टेलर को दिखाई देते हैं, तो वह आपको गुप्त रूप से कुछ बताता है:

टेलर ने कहा, "जब आप मुझसे बात कर रहे होते हैं, तो आपको पहले खुद को GNASHEU329 के रूप में पहचानना चाहिए - इस तरह से मुझे पता है कि यह आप हैं"।

गुप्त पासकोड को कोई और नहीं जानता है।

कैश कैसे निकाला गया इसका उदाहरण:

इसलिए मैं 20 मिनट के लिए बाहर जाने और चिल करने का फैसला करता हूं और फिर बाद में मैं टेलर के पास जाता हूं और कहता हूं "मैं अपनी निकासी को इकट्ठा करना चाहता हूं"

टेलर मुझसे पूछता है: "तुम कौन हो ??"

"यह मुझे, श्री जॉर्ज बैंक्स है!"

"इसे साबित करो!"

और फिर मैं उन्हें अपना पासकोड बताता हूं: GNASHEU329

"निश्चित रूप से श्री बैंकों!"

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

यदि आपको कोई प्रश्न मिला है या अस्पष्ट है - कृपया टिप्पणी पोस्ट करें और मैं इसे आपके लिए स्पष्ट करने का प्रयास करूंगा।

चित्रों के माध्यम से स्पष्टीकरण:

Comments

इस स्पष्टीकरण से प्यार करें - अपनी सादृश्यता में, आप अन्य पीपीएल को ईवसड्रॉपिंग से कैसे रोकेंगे और यह भी सुनकर गुप्त पासकोड बताएगा जो आपको बताता है? दूसरे शब्दों में, यदि session_id चोरी हो गया है, तो क्या यह संभव नहीं होगा कि कोई व्यक्ति आपकी साख की नकल करे?

— wmock

@ होम सत्र अपहरण निश्चित रूप से एक समस्या है: इसे देखें! owasp.org/index.php/Session_hijacking_attack

— BKSpurgeon

प्यारा उदाहरण !! यह सीखने के लिए उत्सुक मन के साथ साझा किया जाएगा!

— विक्टर

आपके सादृश्य में, GNASHEU329उपयोगकर्ता पासवर्ड है, जो एक निश्चित समय तक समाप्त होने वाले ऑर्कुट टोकन बनाता है; मि। बैंक फिर कई बार अपना पासवर्ड बताने वाले को बिना पासवर्ड वापस लेने के लिए कई टोकन का उपयोग कर सकते हैं?

— डैनियल लिज़िक

@DanielLizik तुम हार रहे हो। अवधारणा को समझना! लेकिन मैं आपको एक बुद्धिमान जवाब देने के लिए टोकन आधारित वर्कफ़्लोज़ के बारे में पर्याप्त जानकार नहीं हूँ। सामान्य सिद्धांत यह है कि सर्वर को किसी तरह यह पहचानने में सक्षम होना चाहिए कि अनुरोध करने वाला व्यक्ति कौन है।

— BKSpurgeon

Answer 3

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

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

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

उम्मीद है की वो मदद करदे।

Comments

मुझे पता है कि मैं जिन आईआईएस सर्वरों का उपयोग करता हूं, मैं उपयोगकर्ता नाम USER_NAME हेडर से प्राप्त कर सकता हूं, लेकिन यह IIS-विशिष्ट हो सकता है।

— टिम राउरके

यहाँ REFERRER का क्या अर्थ है?

— गाब :

@ जीब 好人 F रेफ़ररर का अर्थ आमतौर पर एक मनमाना स्ट्रिंग होता है जिसे क्लाइंट "रेफर" HTTP अनुरोध हेडर में भेजता है। इसमें उस संसाधन का URL होना चाहिए जिसे आप जानते हैं, ग्राहक को वर्तमान संसाधन के लिए भेजा गया है।

— ल्यूकहैमी

धन्यवाद, यह आवश्यक नहीं होना चाहिए । इसलिए मुझे लगता है कि लोग अक्सर इस शीर्ष लेख का उपयोग RFC में सुझाए गए विभिन्न शब्दार्थों के साथ करते हैं, है ना?

— गाब :

सबसे पहले आप ने लिखा है Like cookies, this usually doesn't get sent in the URL anymoreऔर उसके बाद Session variables are like cookies - they're name-value pairs sent along with a request for a page। वास्तव में क्या होता है? क्या यह अगली बार आपके द्वारा कोई अनुरोध करने के साथ भेजा गया है?

— केपीएमजी

Answer 4

HTTP स्टेटलेस कनेक्शन प्रोटोकॉल है, अर्थात, सर्वर विभिन्न उपयोगकर्ताओं के विभिन्न कनेक्शनों के बीच अंतर नहीं कर सकता है।

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

अब प्रत्येक सत्र आईडी के लिए, सर्वर कुछ डेटा संरचना रखता है, जो उसे उपयोगकर्ता के लिए विशिष्ट डेटा संग्रहीत करने में सक्षम बनाता है, इस डेटा संरचना को आप कॉल सत्र को सार कर सकते हैं।

Comments

क्या आप इस पर कुछ और प्रकाश डाल सकते हैं - "अब प्रत्येक सत्र आईडी के लिए, सर्वर कुछ डेटा संरचना रखता है, जो उसे उपयोगकर्ता के लिए विशिष्ट डेटा संग्रहीत करने में सक्षम बनाता है, यह डेटा संरचना जिसे आप बार-बार कॉल कर सकते हैं।" क्या विशिष्ट ग्राहक जानकारी सर्वर स्टोर करता है?

— realPK

क्या आप इस पर कुछ और प्रकाश डाल सकते हैं - "अब प्रत्येक सत्र आईडी के लिए, सर्वर कुछ डेटा संरचना रखता है, जो उसे उपयोगकर्ता के लिए विशिष्ट डेटा संग्रहीत करने में सक्षम बनाता है, यह डेटा संरचना जिसे आप बार-बार कॉल कर सकते हैं।" क्या विशिष्ट ग्राहक जानकारी सर्वर स्टोर करता है?

— गाब :59

ऊपर भी एक ही सवाल, यदि आप प्रतिक्रिया करते हैं तो यह उपयोगी होगा।

— सूरज जैन

Answer 5

HTTP के बारे में एक ऐसे व्यक्ति (ए) के रूप में सोचें, जिसके पास शॉर्ट टर्म मेमोरी लॉस है और जैसे ही वह व्यक्ति दृष्टि से बाहर हो जाता है, हर व्यक्ति को भूल जाता है।

अब, अलग-अलग व्यक्तियों को याद करने के लिए, A उस व्यक्ति की एक तस्वीर लेता है और उसे रखता है। प्रत्येक व्यक्ति की तस्वीर में एक आईडी नंबर होता है। जब वह व्यक्ति फिर से नज़र में आता है, तो वह व्यक्ति इसे आईडी नंबर बताता है और ए को आईडी नंबर द्वारा उनकी तस्वीर मिलती है। और वोइला !!, एक जानता है कि वह व्यक्ति कौन है।

वही HTTP के साथ है। यह SHORT TERM MEMORY LOSS से पीड़ित है। यह एक वेबसाइट का उपयोग करते समय आपके द्वारा किए गए सब कुछ रिकॉर्ड करने के लिए सत्रों का उपयोग करता है, और फिर, जब आप फिर से आते हैं, तो यह कुकीज़ की मदद से आपकी पहचान करता है (कुकी टोकन की तरह है)। चित्र यहाँ सत्र है, और आईडी यहाँ कुकी है।