दिलचस्प पोस्ट
दो गतिविधियों के बीच संवाद करने के लिए इंटरफ़ेस का उपयोग कैसे करें कूकीज का उपयोग कर सी # वेबआरइज़ेस्ट वसंत-डेटा-मोंगोडब बहु-किरायेदार बनाना Android सामग्री डिज़ाइन बटन शैलियाँ दूसरे पैरामीटर के आधार पर सॉर्ट करें जावा स्मृति समझाया (एसयूएन जेवीएम) नोडजेएस + सॉकेट.आईओ और पीएचपी कैसे एकीकृत करें? कैसे स्थापित करें और phpize को चलाने के लिए Php का उपयोग करते हुए दो तिथियों के बीच यादृच्छिक दिनांक कैसे उत्पन्न करें? RemapColums के साथ remapColumnsByName मुक्त jqgrid में कैसे बदलें जावा रिफ्लेक्शन बीन्स प्रॉपर्टी एपीआई "पार्स त्रुटि: एंड्रॉइड एप्लिकेशन इंस्टॉल करते समय पैकेज को पार्स करने में कोई समस्या है" मोबाइल डिवाइस पर बूटस्ट्रैप 3 – डेस्कटॉप दृश्य एक पूर्णांक प्रभाग में अंश कैसे प्राप्त करें? गुणों को एक ऑब्जेक्ट से एक ही प्रकार के दूसरे को स्वचालित रूप से लागू करें?

क्या सत्र वास्तव में शांतता का उल्लंघन करते हैं?

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

  • मान्यता के लिए प्रमाणीकरण निषिद्ध नहीं है (अन्यथा रियायतें सेवाओं में बहुत कम उपयोग होगा)
  • प्रमाणीकरण अनुरोध में प्रमाणीकरण टोकन भेजकर किया जाता है, आमतौर पर हेडर
  • इस प्रमाणीकरण टोकन को किसी भी तरह से प्राप्त करने की आवश्यकता है और इसे रद्द कर दिया जा सकता है, जिसके मामले में इसे नवीनीकृत करने की आवश्यकता है
  • प्रमाणीकरण टोकन को सर्वर द्वारा मान्य होना चाहिए (अन्यथा यह प्रमाणीकरण नहीं होगा)

तो सत्रों का यह उल्लंघन कैसे होता है?

  • क्लाइंट-साइड, सत्रों को कुकीज का उपयोग करके एहसास होता है
  • कुकीज़ बस एक अतिरिक्त HTTP हैडर हैं
  • एक सत्र कुकी किसी भी समय प्राप्त की जा सकती है और रद्द कर सकती है
  • सत्र कुकीज को अनंत जीवन समय हो सकता है यदि ज़रूरत हो
  • सत्र आईडी (प्रमाणीकरण टोकन) मान्य सर्वर-साइड है

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

क्या मेरी धारणा गलत है? क्या सत्र कुकीज को निष्क्रिय करता है ?

Solutions Collecting From Web of "क्या सत्र वास्तव में शांतता का उल्लंघन करते हैं?"

सबसे पहले, कुछ शब्दों को परिभाषित करें:

  • RESTful:

    कोई भी इस खंड में वर्णित शेष बाधाओं के अनुरूप अनुप्रयोगों को "रसीला" के रूप में चिह्नित कर सकता है। [15] यदि कोई सेवा किसी भी आवश्यक बाधाओं का उल्लंघन करती है, तो उसे शांत नहीं माना जा सकता है

    विकिपीडिया के अनुसार

  • स्टेटलेस बाधा:

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

    फील्डिंग निबंध के अनुसार

तो सर्वर साइड सत्र, बाकी की स्टेटलेस बाधा का उल्लंघन करती है, और इतनी धीमी गति से या तो।

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

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

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

मेरे नज़रिये से:

  • मान्यता के लिए प्रमाणीकरण निषिद्ध नहीं है (अन्यथा रियायतें सेवाओं में बहुत कम उपयोग होगा)
  • प्रमाणीकरण अनुरोध में प्रमाणीकरण टोकन भेजकर किया जाता है, आमतौर पर हेडर
  • इस प्रमाणीकरण टोकन को किसी भी तरह से प्राप्त करने की आवश्यकता है और इसे रद्द कर दिया जा सकता है, जिसके मामले में इसे नवीनीकृत करने की आवश्यकता है
  • प्रमाणीकरण टोकन को सर्वर द्वारा मान्य होना चाहिए (अन्यथा यह प्रमाणीकरण नहीं होगा)

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

चित्रा 1. विश्वसनीय ग्राहकों द्वारा स्टेटलेस प्रमाणीकरण

  • चित्रा 1. विश्वसनीय ग्राहकों द्वारा स्टेटलेस प्रमाणीकरण

आपको संभवतः चीजों को तेज बनाने के लिए सर्वर की ओर से एक इन-मेमरी एथ कैश की आवश्यकता है, क्योंकि आपको प्रत्येक अनुरोध को प्रमाणित करना होगा।

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

चित्रा 2. - तीसरे पक्ष के ग्राहकों द्वारा स्टेटलेस प्रमाणीकरण

  • चित्रा 2. – तीसरे पक्ष के ग्राहकों द्वारा स्टेटलेस प्रमाणीकरण

तो तीसरी पार्टी क्लाइंट विश्वसनीय ग्राहक (या उपयोगकर्ता से सीधे) से पहुंच टोकन प्राप्त कर सकता है। इसके बाद यह एपीआई कुंजी और एक्सेस टोकन के साथ एक वैध अनुरोध भेज सकता है। यह सबसे बुनियादी तृतीय पक्ष प्रमाणन तंत्र है आप प्रत्येक 3 पार्टी प्राधिकृत सिस्टम के दस्तावेज़ीकरण में कार्यान्वयन विवरण के बारे में अधिक पढ़ सकते हैं, जैसे OAuth बेशक यह और अधिक जटिल और अधिक सुरक्षित हो सकता है, उदाहरण के लिए आप सर्वर के पक्ष में हर एक अनुरोध के विवरण पर हस्ताक्षर कर सकते हैं और अनुरोध के साथ हस्ताक्षर भेज सकते हैं, और इसी तरह … वास्तविक समाधान आपके आवेदन की आवश्यकता पर निर्भर करता है।

सबसे पहले, आराम एक धर्म नहीं है और इस तरह से संपर्क नहीं किया जाना चाहिए। जबकि रसीला सेवाओं के फायदे हैं, तो आपको केवल आपके बाकी हिस्सों के लिए ही आवेदन करना चाहिए, जब तक कि वे आपके आवेदन के लिए समझें।

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

Google की वेब सेवाएं एक रेंटल सिस्टम का शानदार उदाहरण हैं प्रत्येक अनुरोध पर पास किए जाने वाले उपयोगकर्ता की प्रमाणीकरण कुंजी के साथ उन्हें प्रमाणीकरण शीर्षलेख की आवश्यकता होती है यह थोड़ा आराम से थोड़ा-सा सिद्धांतों का उल्लंघन करता है, क्योंकि सर्वर प्रमाणीकरण कुंजी की स्थिति को ट्रैक कर रहा है। इस कुंजी की स्थिति को बनाए रखा जाना चाहिए और इसके कुछ प्रकार की समाप्ति तिथि / समय है जिसके बाद यह अब एक्सेस का अनुदान नहीं देता है। हालांकि, जैसा कि मैंने अपने पद के शीर्ष पर उल्लेख किया है, वास्तव में काम करने के लिए आवेदन करने के लिए बलिदान किए जाने चाहिए। उसने कहा, प्रमाणीकरण टोकन को ऐसे तरीके से संग्रहित किया जाना चाहिए जिससे सभी संभावित ग्राहकों को उनके वैध समय के दौरान पहुंच प्रदान करने की अनुमति मिल सके। यदि एक सर्वर प्रमाणीकरण कुंजी की स्थिति को प्रबंधित कर रहा है, तो उस बिंदु के आधार पर एक और लोड संतुलित सर्वर उस कुंजी के आधार पर अनुरोध को पूरा नहीं कर सकता, तो आपने REST के सिद्धांतों का वास्तव में उल्लंघन करना शुरू कर दिया है। Google की सेवाओं यह सुनिश्चित करती है कि, किसी भी समय, आप लोड बैलेंस सर्वर ए के हिसाब से अपने फोन पर उपयोग कर रहे प्रमाणीकरण टोकन ले सकते हैं और अपने डेस्कटॉप से ​​भार संतुलन सर्वर बी को हिट कर सकते हैं और फिर भी सिस्टम तक पहुंच प्राप्त कर सकते हैं और उसी संसाधनों को निर्देशित कर सकते हैं अनुरोध समान थे।

यह सब क्या उबाल हो जाता है कि यह सुनिश्चित करने की आवश्यकता है कि आपके प्रमाणीकरण टोकन किसी प्रकार के बैकिंग स्टोर (डेटाबेस, कैश, जो कुछ भी) के खिलाफ मान्य हैं, यह सुनिश्चित करने के लिए कि आप जितनी संभव हो सके REST गुणों को बनाए रखेंगे।

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

कुकी प्रमाणीकरण के लिए नहीं हैं क्यों एक पहिया को नया बनाना? HTTP ने अच्छी तरह से तैयार किया गया प्रमाणीकरण तंत्र है यदि हम कुकीज़ का उपयोग करते हैं, तो हम केवल एक ट्रांसपोर्ट प्रोटोकॉल के रूप में HTTP का इस्तेमाल करते हैं, इस प्रकार हमें अपना सिग्नलिंग सिस्टम बनाने की जरूरत है, उदाहरण के लिए, उपयोगकर्ताओं को बताएं कि उन्होंने गलत प्रमाणीकरण की है (HTTP 401 का उपयोग करना गलत होगा क्योंकि हम शायद नहीं आपूर्ति Www-Authenticate एक ग्राहक को Www-Authenticate , के रूप में HTTP चश्मा की आवश्यकता :))। यह भी ध्यान दिया जाना चाहिए कि Set-Cookie क्लाइंट के लिए केवल एक सिफारिश है इसकी सामग्री हो सकती है या सहेजा नहीं जा सकती (उदाहरण के लिए, यदि कुकी अक्षम हैं), जबकि Authorization शीर्ष लेख प्रत्येक अनुरोध पर स्वचालित रूप से भेजा जाता है।

एक और मुद्दा यह है कि, एक प्राधिकरण कुकी प्राप्त करने के लिए, संभवतः आप पहले अपने क्रेडेंशियल्स की आपूर्ति करना चाहते हैं? यदि हां, तो क्या यह अस्वस्थ नहीं होगा? सरल उदाहरण:

  • आप कुकी के बिना GET /a करने की कोशिश GET /a
  • आपको किसी तरह प्राधिकरण अनुरोध मिलता है
  • आप किसी तरह जैसे POST /auth जाते हैं और अधिकृत करते हैं
  • आप Set-Cookie
  • आप कुकी के साथ GET /a आज़माएं लेकिन क्या इस मामले में सही तरीके से व्यवहार करता है?

इस राशि को जोड़ने के लिए, मुझे विश्वास है कि यदि हम कुछ संसाधनों का उपयोग करते हैं और हमें प्रमाणित करने की आवश्यकता है, तो हमें उस संसाधन को प्रमाणित करना होगा, कहीं और नहीं।

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

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

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

बाकी एप्लिकेशन डेटा के बारे में है, उस डेटा को हस्तांतरित करने के लिए आवश्यक निम्न स्तर की जानकारी के बारे में नहीं है

निम्न ब्लॉग पोस्ट में, रॉय फील्डिंग ने पूरे बाकी के विचार का अच्छा सारांश दिया:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"एक स्थिर प्रणाली एक स्थिर-राज्य से दूसरे तक आगे निकलती है, और प्रत्येक ऐसी स्थिर अवस्था एक संभावित प्रारंभिक राज्य और एक संभावित अंत-राज्य दोनों होती है Ie, एक रसीला प्रणाली एक अज्ञात संख्या है जो एक सरल सेट का पालन करते हैं ऐसे नियम हैं कि वे हमेशा या तो बाकी पर रहते हैं या एक शांत राज्य से एक दूसरे राज्य को दूसरे स्थान पर स्थानांतरित करते हैं.प्रत्येक राज्य को उस प्रस्तुति के द्वारा पूरी तरह से समझा जा सकता है और इसमें परिवर्तनों का संचरण किया जाता है, जिसमें वर्दी समझने योग्य कार्यों का सेट। सिस्टम एक जटिल राज्य आरेख हो सकता है, लेकिन प्रत्येक उपयोगकर्ता एजेंट केवल एक समय (वर्तमान स्थिर-राज्य) में एक राज्य को देख सकता है और इस तरह प्रत्येक राज्य सरल है और इसका स्वतंत्र रूप से विश्लेषण किया जा सकता है। उपयोगकर्ता, ओटोह, किसी भी समय अपने स्वयं के संक्रमण बना सकते हैं (जैसे, यूआरएल दर्ज करें, एक बुकमार्क का चयन करें, एक संपादक खोलें, आदि)। "


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

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

इसलिए, ग्राहक उपयोगकर्ता द्वारा क्या कर रहा है, का ट्रैक रखता है, और केवल सर्वर पर तार्किक रूप से पूर्ण राज्य संक्रमण भेजता है।

एचटीटीपी लेनदेन, बुनियादी एक्सेस प्रमाणीकरण, आरबीएसी के लिए उपयुक्त नहीं है, क्योंकि मूल प्रवेश प्रमाणन एन्क्रिप्टेड यूज़रनेम का उपयोग करता है: पहचानने के लिए हर बार पासवर्ड, जबकि आरबीएसी में क्या जरूरत है वह भूमिका वह भूमिका है जो उपयोगकर्ता विशिष्ट कॉल के लिए उपयोग करना चाहता है। आरबीएसी उपयोगकर्ता नाम पर अनुमतियों को मान्य नहीं करता है, लेकिन भूमिकाओं पर

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

इसलिए बुनियादी समस्या प्रमाणीकरण का उपयोग करके उस समस्या का समाधान नहीं किया जा सकता है।

इस समस्या को हल करने के लिए, सत्र-रखरखाव आवश्यक है, और ऐसा लगता है कि, कुछ जवाबों के अनुसार, बाकी के साथ विरोधाभास में।

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

मेरे लिए HTTP पर सत्र बनाए रखने के कई तरीके नहीं हैं I कोई एक सत्र, सत्र या सत्र के साथ शीर्ष लेख वाला कुकीज का उपयोग कर सकता है

अगर किसी के पास एक और विचार है तो मुझे यह सुनकर खुशी होगी।

  1. सत्र निरर्थक नहीं हैं
  2. क्या आप का मतलब है कि केवल http- उपयोग के लिए ही आरईएसटी सेवा या मुझे गलत गड़बड़ा है? कुकी-आधारित सत्र का उपयोग केवल स्वयं के लिए ही किया जाना चाहिए! ()! Http- आधारित सेवाएं! (यह कुकी के साथ काम करने में एक समस्या हो सकती है, जैसे मोबाइल / कंसोल / डेस्कटॉप / आदि से)
  3. यदि आप 3 डी पार्टी डेवलपर्स के लिए सशक्त सेवा प्रदान करते हैं, कभी भी कुकी-आधारित सत्र का उपयोग न करें, सुरक्षा के साथ समस्याओं से बचने के बजाय टोकन का उपयोग करें