सर्वर साइड कुकी और क्लाइंट साइड कुकी के बीच अंतर क्या है?

120

सर्वर और क्लाइंट पर कुकीज़ बनाने के बीच क्या अंतर है? क्या इन्हें सर्वर साइड कुकीज़ और क्लाइंट साइड कुकीज़ कहा जाता है? क्या कुकीज़ बनाने का एक तरीका है जो केवल सर्वर पर या क्लाइंट पर पढ़ा जा सकता है?

http cookies session-cookies

— राहुल
स्रोत

15

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

— डेन ग्रॉसमैन

1

संभवतः सत्र चर को संदर्भित करता है, जो सर्वर पर डेटा रखता है। आमतौर पर अभी भी एक सत्र पहचानकर्ता है जिसे क्लाइंट साइड कुकी के रूप में आयोजित किया जाता है।

— एंड्रयू ५

सभी संभावना में, प्रश्न अलग-अलग तरीकों से संदर्भित होता है कुकीज़ सर्वर साइड पर एन्कोडेड होती हैं (यानी वे जिस तरह से 'कुकी' और 'सेट-कुकी' रिस्पॉन्स हेडर में एन्कोडेड होती हैं) और क्लाइंट साइड (यानी वे जिस तरह से होती हैं) 'कुकी' अनुरोध शीर्षलेख में एन्कोडेड है - $ पथ चर और वह सब जैज़)। देखें RFC 2109

— ओपीर Radnitz

146

HTTP कुकीज

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

ब्राउज़र अनुरोध उदाहरण:

GET /index.html HTTP/1.1
Host: www.example.com

उदाहरण सर्वर से उत्तर:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

यहां दो कुकीज़ foo = 10 और बार = 20 ब्राउज़र पर संग्रहीत हैं। दूसरा 30 सितंबर को समाप्त होगा। प्रत्येक बाद के अनुरोध में ब्राउज़र कुकीज़ को सर्वर पर वापस भेज देगा।

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*

सत्र: सर्वर साइड कुकीज़

सर्वर साइड कुकीज़ को "सत्र" के रूप में जाना जाता है। इस मामले में वेबसाइट ब्राउज़र पर एक एकल कुकी संग्रहीत करती है जिसमें एक अद्वितीय सत्र पहचानकर्ता होता है। स्थिति की जानकारी (foo = 10 और बार = 20 ऊपर) सर्वर पर संग्रहीत की जाती है और सर्वर पर संग्रहीत डेटा के साथ अनुरोध की पहचान करने के लिए सत्र पहचानकर्ता का उपयोग किया जाता है।

उपयोग के उदाहरण

आप स्टोर करने के लिए सत्र और कुकीज़ दोनों का उपयोग कर सकते हैं: प्रमाणीकरण डेटा, उपयोगकर्ता प्राथमिकताएं, ई-कॉमर्स वेबसाइट में एक चार्ट की सामग्री, आदि ...

फायदा और नुकसान

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

कुकी पेशेवरों:

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

कुकी विपक्ष:

भंडारण 80 KB (20 कुकीज़, 4 KB प्रत्येक) तक सीमित है
सुरक्षित कुकीज़ को लागू करना आसान नहीं है: कागज पर एक नज़र डालें एक सुरक्षित कुकी प्रोटोकॉल

सत्र पेशेवरों:

आमतौर पर उपयोग करने में आसान PHP में शायद ज्यादा अंतर नहीं है।
असीमित भंडारण

सत्र विपक्ष:

पैमाने पर अधिक कठिन है
वेब सर्वर पुनरारंभ होने पर आप सभी सत्रों को खो सकते हैं या कार्यान्वयन के आधार पर नहीं
रेस्टफुल नहीं

— फिलिपो
स्रोत

सत्र के मुकदमे secure:?

— user2167582

1

सत्र अधिक सुरक्षित क्यों? यदि आप http पर सत्र कुकी भेजते हैं तो इसे अपहृत किया जा सकता है। यदि साइट का उपयोग करता है तो https सुरक्षा तब तक ही होनी चाहिए जब तक आप सुरक्षित कुकीज़ (एन्क्रिप्टेड, हस्ताक्षरित, आदि ...) का उपयोग करते हैं

— filippo

1

कुकीज़ सहमति: प्रत्येक अनुरोध को बड़ा बनाता है, संभवतः प्रदर्शन को प्रभावित करता है। मुझे संख्याओं का पता नहीं है, लेकिन जब से लोग खाना पकाने वाले डोमेन का उपयोग उन चीजों के लिए करते हैं, जो मुझे लगता है कि यह अनैतिक है।

— maniexx

5

बड़े पैमाने पर भ्रामक जवाब - सत्र कुकीज़ नहीं हैं। en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session आपके पास सत्र चर हो सकता है, जो सत्र प्रबंधन को सर्वर पर लागू करने के तरीके पर निर्भर करता है। आपके पास आमतौर पर एक या एक से अधिक कुकीज़ हैं जो सत्र पहचानकर्ता को पकड़कर सत्र प्रबंधन से संबंधित हैं। इसके अलावा REST और RESTful का कुकीज़ या सत्र प्रबंधन से कोई लेना-देना नहीं है - REST और RESTful कार्यान्वयन में सत्र और कुकीज़ हो सकते हैं।

— Zlatin Zlatev

2

देखें stackoverflow.com/questions/35054840/… मैं यह नहीं कह रहा था कि सत्र आमतौर पर कुकीज़ के साथ लागू नहीं होते हैं, लेकिन सत्र प्रबंधन के लिए अन्य विकल्प हैं, इसलिए सत्र चर के बारे में सर्वर-साइड कुकीज़ के रूप में बात करना गलत है। मैं JWT का भी जिक्र कर रहा था जब मैंने वर्ष 2017 में ऊपर टिप्पणी में कहा था कि "REST और RESTful कार्यान्वयन में सत्र और कुकीज़ हो सकते हैं"। हालांकि कुछ शुद्धतावादी यह तर्क दे सकते हैं कि REST API को लागू करने का यह उचित तरीका नहीं है।

— ज़्लतिन ज़्लाटेव

57

आप शायद Http केवल कुकीज़ और उनके काउंटर भाग के बीच अंतर का मतलब है ?

Http केवल क्लाइंट साइड जावास्क्रिप्ट, केवल सर्वर साइड में ही कुकीज़ को एक्सेस किया जा सकता है (पढ़ा या लिखा जा सकता है)। यदि Http केवल ध्वज सेट नहीं है, या कुकी (क्लाइंट साइड) जावास्क्रिप्ट में बनाई गई है, तो कुकी को सर्वर क्लाइंट साइड में (क्लाइंट साइड) जावास्क्रिप्ट से पढ़ा और लिखा जा सकता है।

— nikc.org
स्रोत

38

सभी कुकीज़ क्लाइंट और सर्वर हैं

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

लेकिन अनिवार्य रूप से यह एक ही कुकी है।

लेकिन, व्यवहार बदल सकता है

एक कुकी मूल रूप से एक है name=valueजोड़ी है, लेकिन मूल्य के बाद हो सकता है सेमी-कोलन का एक समूह अलग विशेषताओं है कि कुकी के व्यवहार को प्रभावित करता है, तो यह बहुत ग्राहक (या सर्वर) द्वारा कार्यान्वित किया जाता। वे विशेषताएँ जीवनकाल, संदर्भ और विभिन्न सुरक्षा सेटिंग्स के बारे में हो सकती हैं।

केवल HTTP (केवल सर्वर नहीं है)

उन विशेषताओं में से एक को एक सर्वर द्वारा यह इंगित करने के लिए सेट किया जा सकता है कि यह केवल HTTP-कुकी है। इसका मतलब है कि कुकी को अभी भी आगे और पीछे भेजा जाता है, लेकिन यह जावास्क्रिप्ट में उपलब्ध नहीं होगा। हालांकि, ध्यान दें कि कुकी अभी भी है! यह केवल ब्राउज़र में सुरक्षा में बनाया गया है, लेकिन अगर कोई IE5, या कुछ कस्टम क्लाइंट जैसे हास्यास्पद पुराने ब्राउज़र का उपयोग करेगा, तो वे वास्तव में कुकी पढ़ सकते हैं!

तो ऐसा लगता है कि 'सर्वर कुकीज़' हैं, लेकिन वास्तव में नहीं हैं। वे कुकीज़ अभी भी क्लाइंट को भेजी जाती हैं। क्लाइंट पर कुकी को सर्वर पर भेजे जाने से रोकने का कोई तरीका नहीं है।

'केवल-नेस' प्राप्त करने के लिए विकल्प

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

— GolezTrol
स्रोत

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

— करण चड्ढा

1

Hi @KaranChadha, यदि आपका कोई प्रश्न है, तो कृपया इसे पृष्ठ के शीर्ष पर 'प्रश्न पूछें' बटन का उपयोग करके एक औपचारिक प्रश्न के रूप में पूछें। 7 साल पुराने सवाल पर एक टिप्पणी धागा शायद इसकी ओर सही ध्यान आकर्षित नहीं करेगा। इस प्रश्नोत्तर के लिए एक लिंक जोड़ना, या विशेष रूप से इस उत्तर के लिए, निश्चित रूप से ठीक है। आप उसके लिए प्रत्येक पोस्ट के नीचे 'शेयर' बटन का उपयोग कर सकते हैं।

— गोलेज़ट्रॉल

क्या ये सच है? ग्राहक द्वारा सृजित कुकीज़ स्थानांतरित नहीं होती हैं। अगर वहाँ document.cookie="foo=bar"द्वारा पीछा किया fetch("/foobar", {credentials: 'include'} )जा रहा है कोई कुकी युक्त नहीं भेजा जा रहा है foo=bar। बस इस साइट पर सीधे DevTools और कंसोल का उपयोग करके कोड की कोशिश की।

— ऑलिगॉफ्रेन

हाँ यह सच है, डॉक्स भी कहते हैं , लेकिन कुछ विशिष्टताएं हैं जो इसका कारण बन सकती हैं, जैसे कि लापता समाप्ति विशेषता।

— गोलेज़ट्रॉल

1

@MarinosAn हाँ यह कर सकते हैं। लेकिन मेरा जवाब थोड़ा संक्षिप्त था जब यह उन विशेषताओं के बारे में आया जो कुकी के व्यवहार को संशोधित करती हैं, इसलिए मैंने इसे थोड़ा विस्तारित किया।

— गोलेज़ट्रॉल

4

हाँ, आप कुकीज़ बना सकते हैं जो केवल सर्वर-साइड पर पढ़ी जा सकती हैं। इन्हें "HTTP ओनली" -कुकीज कहा जाता है, जैसा कि पहले से ही अन्य उत्तरों में बताया गया है
नहीं, कोई रास्ता नहीं है (मुझे पता है) "कुकीज़" बनाने के लिए जिसे केवल क्लाइंट-साइड पर पढ़ा जा सकता है। कुकीज़ क्लाइंट-सर्वर संचार की सुविधा के लिए हैं।
लेकिन, अगर आप कुछ चाहते हैं "क्लाइंट-ओनली-कुकीज" तो एक आसान जवाब है: "लोकल स्टोरेज" का उपयोग करें।

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

https://courses.cs.washington.edu/courses/cse154/12au/lectures/slides/lecture21-client-storage.shtml#slide8

एक बिंदु: आप GUI से संबंधित चीजों को स्टोर करने के लिए जावास्क्रिप्ट में निर्मित कुकीज़ का उपयोग कर सकते हैं जो आपको केवल क्लाइंट-साइड पर चाहिए। लेकिन कुकी को भेजे गए अनुरोध के लिए सर्वर पर भेजा जाता है, यह http-request हेडर्स का हिस्सा बन जाता है, जिससे अनुरोध अधिक डेटा होता है और इस प्रकार भेजने के लिए धीमा हो जाता है।

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

स्थानीय भंडारण में उन डेटा-स्थानांतरण से संबंधित नुकसान नहीं होते हैं, यह कोई डेटा नहीं भेजता है। यह बहुत अच्छा है।

— पानू तर्क
स्रोत