कुकीज़ बनाम सत्र

Question

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

StackOverflow में आप सभी के लिए धन्यवाद!

Comments

दोनों तरीके डेटा को स्टोर करते हैं । कुकीज़ क्लाइंट की ओर से करते हैं, यानी आपके आगंतुकों के उपकरणों के भंडारण पर। सत्र एक चतुर "विस्तार" है जिसमें वे केवल क्लाइंट साइड पर एक अद्वितीय आईडी और सर्वर साइड पर सभी वास्तविक डेटा संग्रहीत करते हैं। जब उन्हें क्लाइंट की कुकी से विशिष्ट आईडी मिलती है, तो उन्हें पता होता है कि सर्वर पर क्या डेटा लोड करना है। ज्यादातर मामलों में, सत्र वही होंगे जो आपको चाहिए। वैसे, आप अधिक आधुनिक तरीके से github.com/delight-im/PHP-Cookie के साथ दोनों का प्रबंधन कर सकते हैं ।

— 23:12 पर जौ

एक तरफ के रूप में, वर्डप्रेस कोर ने कई साल पहले सत्र का उपयोग छोड़ दिया और अब पूरी तरह से कुकीज़ का उपयोग करता है । दिलचस्प। मुझे आश्चर्य है कि अगर उन्होंने ऐसा किया है कि लोड-संतुलित सर्वर और / या सत्र कचरा संग्रह के कारण यादृच्छिक लॉगआउट को कम करने के लिए तैनात करना आसान है।

— साइमन ईस्ट

Answer 1

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

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

संपादित करें: मुझे नहीं लगता कि सादगी के अलावा, कुकीज़ का उपयोग करने का कोई फायदा है। इसे इस तरह से देखें ... क्या उपयोगकर्ता के पास अपनी आईडी # जानने का कोई कारण है? आमतौर पर मैं कहता हूं कि नहीं, उपयोगकर्ता को इस जानकारी की कोई आवश्यकता नहीं है। जानकारी देने को आधार के आधार पर सीमित होना चाहिए। क्या होगा यदि उपयोगकर्ता अपनी कुकी को एक अलग आईडी के लिए बदलता है, तो आपका आवेदन कैसे प्रतिक्रिया देगा? यह एक सुरक्षा जोखिम है।

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

Comments

@JiminyCricket मुझे नहीं लगता कि यह सच है ... यदि ऐसा है, तो कोई भी उपयोगकर्ता में वर्तमान में लॉग इन करने के लिए सत्र चर का उपयोग नहीं करेगा - और हर कोई करता है। यह एक बड़ा सुरक्षा जोखिम होगा। बहुत यकीन है कि आम तौर पर सत्र आईडी ग्राहक मशीन पर एक कुकी के रूप में संग्रहीत किया जाता है, और फिर सत्र डेटा के साथ सर्वर-साइड से मिलान किया जाता है। सर्वर आमतौर पर कुकी के माध्यम से आईपी पते के माध्यम से सत्रों को नियंत्रित नहीं करता है।

— जॉन एम।

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

— ब्रायन लीशमैन

क्या आपको लगता है कि मुझे प्रमाणीकरण के लिए सत्रों का उपयोग करना चाहिए? क्या इसका कोई सुरक्षा जोखिम है? कैसे एक हैकर अपने सत्र-आईडी को बदलने की कोशिश करता है, सर्वर कैसे प्रतिक्रिया देगा (मान लीजिए सत्र-आईडी मान्य है)?

— O-BL

सत्र का उपयोग करें और फिर सत्र के रूप में 2FA अपहृत किया जा सकता है।

— जाकिर साजिब

Answer 2

उन दोनों के बीच अंतर करने के लिए मूल विचार।

सत्र:

1. IDU सर्वर पर संग्रहीत किया जाता है (अर्थात सर्वर-साइड)
2. सुरक्षित (1 के कारण)
3. समाप्ति सेट नहीं किया जा सकता है, जब उपयोगकर्ता ब्राउज़र बंद करते हैं तो सत्र चर समाप्त हो जाएगा। (आजकल इसे 24 मिनट के लिए php में डिफ़ॉल्ट रूप में संग्रहीत किया जाता है)

कुकीज़:

1. आईडीयू वेब-ब्राउज़र (अर्थात क्लाइंट-साइड) पर संग्रहीत है
2. बहुत सुरक्षित नहीं है, क्योंकि हैकर्स आपकी जानकारी प्राप्त कर सकते हैं (1 के कारण)
3. समाप्ति निर्धारित की जा सकती है ( अधिक जानकारी के लिए सेटकुकीज़ देखें)

जब आपको अल्पकालिक जानकारी / मान संग्रहीत करने की आवश्यकता होती है, जैसे गणना, माप, क्वेरी आदि के लिए सत्र को प्राथमिकता दी जाती है।

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

Comments

जागरूक रहें: यह एक अच्छा जवाब नहीं है। यह काफी ठीक है, लेकिन चीजों को भ्रमित करता है और विघटन के साथ समाप्त होता है। यह सत्र बनाम कुकीज़ स्पष्टीकरण नहीं है। यह एक सत्र बनाम सत्र + सत्र कुकी स्पष्टीकरण है। अकेले कुकीज़ को बताए गए कारणों के लिए पसंद नहीं किया जाता है। सत्र + सत्र कुकीज़ को बताए गए कारणों के लिए पसंद किया जाता है।

— मार्कस

एक और गलती यह है कि आपके पास PHP कॉन्फ़िगरेशन के माध्यम से जीवन भर सत्र पर प्रभाव पड़ता है।

— चिह्न

सत्र अभी भी उपयोगकर्ता ब्राउज़र पर एक कुकी सेट करता है, इसलिए यह सर्वर-क्लाइंट साइड स्पष्टीकरण सटीक नहीं है

— Zalaboza

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

— saran3h

आईडीयू किस लिए खड़ा है?

— साइमन ईस्ट

Answer 3

SESSIONS ENDS WHEN USER CLOSES THEIR BROWSER,

COOKIES END DEPENDING ON THE LIFETIME YOU SET FOR IT. SO THEY CAN LAST FOR YEARS

यह आपकी पसंद में प्रमुख अंतर है,

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

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

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

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

Comments

दरअसल, एक सत्र डिफ़ॉल्ट रूप से तब तक चलता है जब तक कि उपयोगकर्ता अपना ब्राउज़र बंद नहीं कर देता है, लेकिन BUT इसे php.ini फ़ाइल में 0 सेशन में बदल कर बदल सकता है ।ookie_lifetime = 0 सेकंड में वह संख्या होनी चाहिए जिसे आप सत्र को अंतिम रूप देना चाहते हैं, या session_set_cookie_params () का उपयोग करना।

— DOK

आगे उपयोगी जानकारी, ऐसे प्रश्न जो कई उत्तर प्राप्त करते हैं .. महान, फिर से धन्यवाद DOK!

— नदजीब ममी

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

— शॉन ई कार्टर

क्या कोई भी इस बात की पुष्टि कर सकता है: "जब उपयोगकर्ता USER CLOSE HIS BROSER" का उपयोग करता है, तो 1. यदि उपयोगकर्ता पृष्ठ से awyaates करता है .. तो ब्राउज़र को बंद किए बिना वापस चला जाता है। 2. क्या होगा अगर उनके पास एक ही साइट पर कई ब्राउज़र विंडो / टैब खुले हों? काम के दौरान कुछ वेब ऐप इस स्थिति में भ्रमित हो जाते हैं, लेकिन मुझे नहीं पता कि वे किस प्रकार के कुकीज़ का उपयोग करते हैं।

— jansansell

@jcansell कुआं, मल्टी टैब या कुकी को दूर करने से कोई कुकी भ्रमित नहीं होगी, ऐसे में संभवतया इन

— वेबएप्स ने

Answer 4

जब आप उपयोगकर्ताओं में लॉग इन को पहचानने के लिए #ID को कुकी के रूप में सहेजते हैं, तो आप वास्तव में उन उपयोगकर्ताओं को डेटा दिखा रहे हैं जो उनसे संबंधित नहीं हैं। इसके अलावा, यदि कोई तृतीय पक्ष अपने ब्राउज़र में कुकी डेटा के रूप में यादृच्छिक आईडी सेट करने का प्रयास करता है, तो वे सर्वर को यह समझाने में सक्षम होंगे कि वे एक उपयोगकर्ता हैं जबकि वे वास्तव में नहीं हैं। वह सुरक्षा की कमी है।

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

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

Comments

अच्छी व्याख्या। मैं व्यक्तिगत उपयोगकर्ताओं को पहचानने के लिए GUID टोकन का उपयोग करता हूं।

— कार्तिक

Answer 5

संक्षिप्त जवाब

प्राथमिकता के आधार पर दिए गए नियम:

• नियम 1. उपयोगकर्ता इनपुट पर कभी भरोसा न करें: कुकीज़ सुरक्षित नहीं हैं। संवेदनशील डेटा के लिए सत्र का उपयोग करें।
• नियम 2. यदि उपयोगकर्ता द्वारा ब्राउज़र बंद करने पर लगातार डेटा रहना चाहिए, तो कुकीज़ का उपयोग करें।
• नियम 3. यदि उपयोगकर्ता द्वारा ब्राउज़र बंद करने पर लगातार डेटा नहीं रहना है, तो सत्र का उपयोग करें।
• नियम 4. विस्तृत उत्तर पढ़ें!

स्रोत: https://www.lucidar.me/en/web-dev/session-or-cookies/

---

विस्तृत जवाब

कुकीज़

• कुकीज़ क्लाइंट की ओर (विज़िटर के ब्राउज़र में) संग्रहीत हैं।
• कुकीज़ सुरक्षित नहीं हैं: कुकी सामग्री पढ़ना और लिखना काफी आसान है।
• कुकीज़ का उपयोग करते समय, आपको यूरोपीय कानूनों (GDPR) के अनुसार आगंतुकों को सूचित करना होगा।
• समय सीमा समाप्त हो सकती है, लेकिन उपयोगकर्ता या ब्राउज़र इसे बदल सकते हैं।
• उपयोगकर्ता (या ब्राउज़र) कुकीज़ के उपयोग को अस्वीकार कर सकते हैं (सेट किया जा सकता है)।

सत्र

• सर्वर साइड पर सत्र संग्रहीत हैं।
• सत्र कुकीज़ का उपयोग करते हैं (नीचे देखें)।
• सत्र कुकीज़ की तुलना में सुरक्षित हैं, लेकिन अतुलनीय नहीं हैं।
• समाप्ति सर्वर कॉन्फ़िगरेशन (उदाहरण के लिए php.ini) में सेट की गई है।
• डिफ़ॉल्ट समाप्ति समय 24 मिनट या जब ब्राउज़र बंद हो जाता है।
• उपयोगकर्ता द्वारा नया पृष्ठ ताज़ा करने या लोड करने पर समाप्ति रीसेट हो जाती है।
• उपयोगकर्ता (या ब्राउज़र) कुकीज़ के उपयोग को अस्वीकार कर सकते हैं (इसलिए सेट किया जा सकता है), इसलिए सत्र।
• कानूनी तौर पर, आपको कुकी के लिए आगंतुकों को सूचित करना होगा, लेकिन मिसाल की कमी अभी तक स्पष्ट नहीं है।

उपयुक्त विकल्प

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

संवेदनशील डेटा को कभी भी कुकीज़ (ईमेल, एन्क्रिप्टेड पासवर्ड, पर्सनल डेटा ...) में संग्रहित नहीं किया जाना चाहिए। ध्यान रखें कि डेटा एक विदेशी कंप्यूटर पर संग्रहीत हैं, और यदि कंप्यूटर निजी (कक्षा या सार्वजनिक कंप्यूटर) नहीं है, तो कोई अन्य व्यक्ति संभवतः कुकी सामग्री को पढ़ सकता है।

याद रखें-मुझे डेटा कुकीज़ में संग्रहीत किया जाना चाहिए, अन्यथा उपयोगकर्ता द्वारा ब्राउज़र बंद करने पर डेटा खो जाएगा। हालाँकि, 'याद रखें' कुकी में पासवर्ड या उपयोगकर्ता के व्यक्तिगत डेटा को न सहेजें। उपयोगकर्ता डेटा को डेटाबेस में संग्रहीत करें और इस डेटा को एक कुकी में संग्रहीत आईडी / कुंजी की एक एन्क्रिप्टेड जोड़ी के साथ लिंक करें।

पिछली सिफारिशों पर विचार करने के बाद, निम्नलिखित प्रश्न अंत में कुकीज़ और सत्रों के बीच चयन करने में आपकी मदद करता है:

उपयोगकर्ता द्वारा ब्राउज़र बंद करने पर लगातार डेटा बना रहना चाहिए?

• यदि जवाब हां है , तो कुकीज़ का उपयोग करें ।
• यदि उत्तर नहीं है , तो सत्र का उपयोग करें ।

Answer 6

दरअसल, सत्र और कुकीज़ हमेशा अलग चीजें नहीं होती हैं। अक्सर, लेकिन हमेशा नहीं, सत्र कुकीज़ का उपयोग करता है।

इन अन्य प्रश्नों में आपके प्रश्न के कुछ अच्छे उत्तर यहां दिए गए हैं। चूँकि आपका प्रश्न विशेष रूप से उपयोगकर्ता के IDU (या ID) को बचाने के बारे में है, मुझे नहीं लगता कि यह उन अन्य प्रश्नों का एक बहुत डुप्लिकेट है, लेकिन उनके उत्तरों से आपको मदद मिलनी चाहिए।

कुकीज़ बनाम सत्र

कैश वी.एस. सत्र वी.एस. कुकीज़?

सत्र और कुकी में क्या अंतर है?

Answer 7

मैं व्यक्तिगत रूप से कुकीज़ और सत्र दोनों का उपयोग करता हूं।

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

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

धन्यवाद,

Answer 8

सत्र और कुकी एक समान नहीं हैं।

वेब पृष्ठों से जानकारी संग्रहीत करने के लिए एक सत्र का उपयोग किया जाता है। आम तौर पर वेब पेजों में इन सूचनाओं को संग्रहीत करने के लिए कोई यादें नहीं होती हैं। लेकिन हम का उपयोग करके आवश्यक जानकारी को बचा सकते हैं।

लेकिन यूजर्स की पहचान के लिए कुकी का इस्तेमाल किया जाता है। कुकी का उपयोग करके हम डेटा को स्टोर कर सकते हैं। यह डेटा का एक छोटा सा हिस्सा है जो उपयोगकर्ता वेब ब्राउज़र में संग्रहीत करेगा। इसलिए जब भी उपयोगकर्ता अगली बार ब्राउज करे तो पिछली गतिविधियों को प्राप्त करने के लिए सर्वर को कुकी डेटा जानकारी वापस भेजें।

क्रेडिट: सत्र और कुकी

Comments

क्या होगा अगर उपयोगकर्ता कुकीज़ अक्षम करता है? कुकी उपयोगकर्ता की पहचान कैसे करती है?

— सोहेलराजपूत

Answer 9

सत्र आपको कुकीज़ के समान जानकारी के अलग-अलग टुकड़ों को स्टोर करने की अनुमति देते हैं, लेकिन डेटा क्लाइंट के बजाय सर्वर पर संग्रहीत हो जाता है।

Answer 10

जैसा कि अन्य ने कहा, सत्र चतुर हैं और ग्राहक से जानकारी छिपाने का अधिक लाभ है।

लेकिन कुकी के पास अभी भी कम से कम एक फायदा है , आप अपने कुकीज़ को जावास्क्रिप्ट से एक्सेस कर सकते हैं (उदाहरण के लिए ngCookies )। PHP सत्र के साथ आप इसे PHP स्क्रिप्ट के बाहर कहीं भी एक्सेस नहीं कर सकते।

Comments

आप कर सकते हैं .. सीधे तौर पर नहीं, होवर आप सत्र डेटा को वापस करने वाली स्क्रिप्ट के लिए कुछ ajax अनुरोध के माध्यम से इसे एक्सेस कर सकते हैं। लेकिन मुझे यकीन नहीं है कि आपको करना चाहिए।

— l00k

Answer 11

मैं सत्र का चयन करूंगा, सबसे पहले सत्र अधिक सुरक्षित है फिर कुकीज़, कुकीज़ ग्राहक साइट डेटा और सत्र सर्वर साइट डेटा है। किसी उपयोगकर्ता की पहचान करने के लिए कुकीज़ का उपयोग किया जाता है, क्योंकि यह कोड के छोटे टुकड़े हैं जो उपयोगकर्ता कंप्यूटर ब्राउज़र के साथ मेरा सर्वर एम्बेडेड है। दूसरी ओर, सत्र आपको पहचान सुरक्षित करने में आपकी मदद करता है क्योंकि वेब सर्वर यह नहीं जानता कि आप कौन हैं क्योंकि HTTP पता राज्य में 192.168.0.1 से 765487cf34ert8ded… .. को GET और POST विधियों की सहायता से कुछ और संख्या में बदलता है। सत्र यूजर्स के डेटा को यूनिक आईडी सेशन में स्टोर करता है, यहां तक ​​कि यूजर आईडी एक दूसरे के साथ मेल नहीं खा सकती है। सत्र एक अनुप्रयोग के सभी पृष्ठों में एकल उपयोगकर्ता जानकारी संग्रहीत करता है। कुकी एक्सपायर को सेटक्यूकीज () की मदद से सेट किया जाता है जबकि सेशन एक्सपायर सेट नहीं होता है यह तब समाप्त हो जाता है जब उपयोगकर्ता ब्राउजर बंद कर देता है।

Answer 12

एक सत्र सर्वर पर जानकारी का एक समूह है जो कुकी जानकारी से जुड़ा है। यदि आप PHP का उपयोग कर रहे हैं तो आप सत्र की जाँच कर सकते हैं। सहेजें _ पथ स्थान और वास्तव में "सत्र देखें"। कुकी ग्राहकों को भेजे गए और भेजे गए डेटा का एक स्निपेट है। कुकीज़ का उपयोग अक्सर सत्रों को सुविधाजनक बनाने के लिए किया जाता है क्योंकि यह सर्वर को बताता है कि किस सत्र को किस क्लाइंट ने संभाला है। ऐसा करने के अन्य तरीके हैं (क्वेरी स्ट्रिंग मैजिक आदि) लेकिन कुकीज़ इसके लिए सबसे आम हैं।