लॉगआउट: GET या POST?

Question

यह सवाल नहीं है कि सामान्य रूप से GET या POST का उपयोग कब किया जाए; यह एक वेब एप्लिकेशन से लॉगिंग से निपटने के लिए अनुशंसित एक है जिसके बारे में है। मुझे सामान्य अर्थ में GET और POST के बीच अंतर के बारे में बहुत सारी जानकारी मिली है, लेकिन मुझे इस विशेष परिदृश्य के लिए निश्चित उत्तर नहीं मिला।

एक व्यावहारिक के रूप में, मैं GET का उपयोग करने के लिए इच्छुक हूं, क्योंकि इसे लागू करना POST की तुलना में सरल है; बस एक सरल लिंक छोड़ें और आपका काम हो गया। ऐसा लगता है कि मैं अपने सिर के ऊपर से कम से कम वेबसाइटों के बारे में सोच सकता हूं। यहां तक ​​कि स्टैक ओवरफ्लो GET के साथ लॉग आउट करता है।

मुझे संकोच करने वाली बात यह है (यद्यपि पुराना) तर्क है कि कुछ वेब एक्सेलेरेटर / प्री-कैशे पृष्ठों को पृष्ठ पर जाने वाले प्रत्येक लिंक पर जाकर पुनः प्राप्त करते हैं, इसलिए जब वह उन पर क्लिक करता है तो उपयोगकर्ता को तेजी से प्रतिक्रिया मिलती है। मुझे यकीन नहीं है कि अगर यह अभी भी लागू होता है, लेकिन यदि यह मामला था, तो सिद्धांत रूप में, इनमें से एक त्वरक के साथ एक उपयोगकर्ता को आवेदन से बाहर निकाल दिया जाएगा जैसे ही वह लॉग इन करता है, क्योंकि उसका त्वरक लॉगआउट ढूंढेगा और पुनः प्राप्त करेगा। लिंक पर क्लिक करें, भले ही वह उस पर क्लिक न करें।

मैंने अब तक जो कुछ पढ़ा है, वह बताता है कि POST का उपयोग "विनाशकारी कार्यों" के लिए किया जाना चाहिए, जबकि ऐसी क्रियाएं जो एप्लिकेशन-जैसी क्वेरी की आंतरिक स्थिति को परिवर्तित नहीं करती हैं और जैसे- GET के साथ संभाला जाना चाहिए । इसके आधार पर, यहां असली सवाल यह है:

क्या किसी एप्लिकेशन से लॉग आउट करना विनाशकारी कार्रवाई माना जाता है / क्या यह एप्लिकेशन की आंतरिक स्थिति को बदल देता है?

Comments

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

— हाइपरकास

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

— डैनियल लियुज़ी

कोई भी त्वरक जो स्वचालित रूप से एक फॉर्म प्रस्तुत करता है (उदाहरण के लिए) मैलवेयर IMO होगा ... यह सोचना पूरी तरह से अतार्किक है कि एक त्वरक स्वचालित रूप से एक फॉर्म सबमिट करेगा। कल्पना कीजिए कि आप Google पर जाएँ। यह खोज फ़ॉर्म कैसे सबमिट कर सकता है? मैलवेयर के लिए कोई भी जिम्मेदार नहीं है क्योंकि यह बहुत अप्रत्याशित है और नियमों का पालन नहीं करता है।

— एलेक्स

@AlexW - मुझे लगता है कि आपने मेरे प्रश्न को गलत समझा। एक्सेलेरेटर परिदृश्य जो मैंने प्रस्तावित किया है वह GET का उपयोग करते समय एक संभावित मुद्दे को प्रदर्शित करता है, POST को नहीं, इसलिए पोस्ट करने के लिए कोई फॉर्म नहीं होगा, केवल सादे लिंक जो त्वरक के बाद कोई समस्या नहीं होगी।

— डैनियल लियुज़ी

मुझे पता है कि मुझे इसके लिए बहुत साल हो गए हैं, लेकिन एलेक्स, वह नहीं है जिसके बारे में डैनियल पूछ रहा है। वह कह रहा है कि यदि कोई उपयोगकर्ता लॉगआउट लिंक पर क्लिक करता है और कोई त्वरक कैश्ड लॉगआउट पृष्ठ को एप्लिकेशन को हिट किए बिना वापस कर देता है, तो उपयोगकर्ता लॉग इन रहेगा। मैलवेयर से कोई लेना-देना नहीं है, हालांकि FYI उपयोगकर्ता-एजेंट स्ट्रिंग की जाँच नहीं करेगा। वैसे भी कुछ भी।

— रोब ग्रांट

Answer 1

का उपयोग करें POST।

2010 में, उपयोग करना GETसंभवतः एक स्वीकार्य उत्तर था। लेकिन आज (2013 में), ब्राउज़र उन पृष्ठों को पूर्व-प्राप्त करेंगे जो वे सोचते हैं कि आप अगले पर जाएंगे।

यहाँ एक StackOverflow डेवलपर्स के इस मुद्दे पर ट्विटर पर बात कर रहा है:

मैं एक GET अनुरोध को लॉग इन करने के लिए अपने बैंक को धन्यवाद देना चाहता हूं, और आसान URL के लिए क्रोम टीम को प्रीफ़ेटिंग करना चाहता हूं। - Nick Craver ( @Nick_Craver ) 29 जनवरी, 2013

मजेदार तथ्य: Gack के माध्यम से लॉग-आउट को संभालने के लिए StackOverflow का उपयोग किया जाता है, लेकिन अब और नहीं।

Comments

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

— डैनियल लियुज़ी

मेरे ब्राउज़र में, Stackoverflow logout <li> <a href="https://stackoverflow.com/users/logout"> लॉग आउट </a> </ li> जैसा दिखता है, जो GET है, न कि POST

— boatcoder

@ Mark0978, लिंक पर क्लिक करें।

— डेविड मर्डोक

दिलचस्प। यह शायद मेरी सबसे कम पसंदीदा विशेषताओं में से एक है, एक लॉगआउट जो तब मुझसे पूछता है कि क्या मुझे यकीन है। लगता है कि यह आपको लॉग आउट करने से प्रीफ़ैच रखता है, लेकिन अमेज़ॅन, ईबे और जीमेल सभी उस ट्रिक पेज के बिना लॉगआउट के लिए GET का उपयोग करते हैं, जो उपयोगकर्ता द्वारा बताए गए लॉगआउट और वास्तविक लॉगआउट इवेंट के बीच होता है। मुझे लगता है कि पृष्ठ के बीच में बहुत से लोग गलती से विश्वास करेंगे कि वे लॉग आउट हो गए हैं। एसओ के साथ समस्याएं कम से कम हैं, कोई पैसा शामिल नहीं है, और 99% सब कुछ वैसे भी सार्वजनिक है।

— बोटकोडर

@Red HTTP / 1.1 मानक के अनुसार, यह सर्वर की गलती है, ब्राउज़र की नहीं। GET के सर्वर साइड पर कोई दुष्प्रभाव नहीं होने की उम्मीद है। मानक यहां तक ​​कहता है "उपयोगकर्ता ने साइड-इफेक्ट्स का अनुरोध नहीं किया था, इसलिए उन्हें उनके लिए जिम्मेदार नहीं ठहराया जा सकता है"।

— आईयूएलटीटी

Answer 2

REST में कोई सत्र नहीं होना चाहिए, इसलिए नष्ट करने के लिए कुछ भी नहीं है। एक REST क्लाइंट हर अनुरोध पर प्रमाणित होता है। लॉग इन या बाहर, यह सिर्फ एक भ्रम है।

क्या आप वास्तव में पूछ रहे हैं कि क्या ब्राउज़र को हर अनुरोध पर प्रमाणीकरण जानकारी भेजना जारी रखना चाहिए।

यकीनन, यदि आपका एप्लिकेशन लॉग इन होने का भ्रम पैदा करता है, तो आपको जावास्क्रिप्ट का उपयोग करके "लॉग आउट" करने में सक्षम होना चाहिए। राउंड ट्रिप की आवश्यकता नहीं है।

---

फील्डिंग शोध प्रबंध - धारा 5.1.3

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

Comments

मुझे वास्तव में इसकी जानकारी नहीं थी। तब मुझे लगता है कि मेरा ऐप बहुत ज्यादा Restful नहीं होगा, क्योंकि मैं ASP.NET MVC का उपयोग फॉर्म्यूशन के साथ कर रहा हूं और यह सत्रों पर निर्भर करता है ...

— डैनियल लिउजी

लेकिन व्यवहार में httponlyकुछ xss जोखिमों को रोकने के लिए विशेषता के साथ लॉगिन जानकारी को कुकी के रूप में चिह्नित किया जाता है, जिसका अर्थ है कि इसे केवल सर्वर से रीसेट किया जा सकता है (मैन्युअल रूप से कुकी को साफ़ करना)

— Remus Rusanu

उपयोगकर्ता के रूप में 'मैनुअल' ब्राउजर सेटिंग्स में जाता है और 'क्लियर कुकीज' विकल्प चुनता है। एक वेब साइट को 'लॉग ऑफ' करने का एक स्वीकार्य तरीका।

— रेमस रूसु

@Remus आह, कैसे शानदार वेब ब्राउज़र लेखन वेब एप्लिकेशन को इतना दर्दनाक बनाता है।

— डारेल मिलर

@DarrelMiller हाँ, हालांकि सर्वर की ओर से JWT को रद्द नहीं करना सुरक्षा भेद्यता है। यहां तक ​​कि अगर टोकन सर्वर पर संग्रहीत नहीं हैं, तो उपयोगकर्ता द्वारा लॉग आउट / परिवर्तन पासवर्ड / परिवर्तन / क्विट / आदि के दुरुपयोग को रोकने के लिए (कम से कम जब तक वे समाप्त नहीं होते हैं) तब उन्हें ब्लैकलिस्ट किया जाना चाहिए।

— जावा-आदी ३०१

Answer 3

यहां एक तरीके GETका दुरुपयोग किया जा सकता है कि एक व्यक्ति (शायद प्रतियोगी) ने src="<your logout link>"इंटरनेट पर कहीं भी एक छवि टैग लगाई है , और यदि आपकी साइट का कोई उपयोगकर्ता उस पृष्ठ पर ठोकर खाता है, तो वह अनजाने में लॉग आउट हो जाएगा।

Comments

नहीं, यह सही नहीं है। लॉग आउट लिंक केवल तभी काम करेगा जब सही कुकी डेटा भेजा जाएगा, जो कि यह किसी अन्य डोमेन से नहीं होगा। और यहां तक ​​कि अगर सत्र आईडी को url में संग्रहीत किया जाता है, तो यह हर सत्र के लिए इन परिवर्तनों के रूप में भी काम नहीं करेगा।

— रिचर्ड एच

वाह, मैंने ऐसा कभी नहीं सोचा था! इसलिए, GET का उपयोग नहीं करने का एक और कारण, और दूसरा कारण मुझे समझ नहीं आता कि हर कोई ऐसा क्यों करता है। धिक्कार है, अब मैं अपने पद के लिए एक stackoverflow.com/users/logout "छवि" को शामिल करने के लिए तैयार हूं और देखें कि क्या होता है :-D

— डैनियल लिउजी

src = एक सरल ब्राउज़र अनुरोध है, यह सर्वर की ओर से नहीं आता है, बल्कि क्लाइंट से आता है। यह सभी कुकीज़ ले जाता है और उपयोगकर्ता आईपी से आता है। यही कारण है कि विज्ञापन ट्रैकिंग पिक्सल काम करते हैं। इस तरह के शोषण को निर्धारित करने का एकमात्र तरीका रेफरल की जांच करना होगा।

— raveren

SuperLogout.com बिल्कुल ऐसा करता है ( /logoutछिपे हुए चित्रों में URL लोड करता है ), और यह काम करता है।

— डेन डैस्कलेस्कु

पुन: SuperLogout ... मुझे नहीं पता कि मैंने क्यों क्लिक किया।

— एमआई राइट

Answer 4

सही होने के लिए, GET / POST (या अन्य क्रियाएं) कुछ संसाधन पर कार्य कर रहे हैं (URL द्वारा संबोधित किया गया है) - इसलिए इसकी आम तौर पर संसाधन की स्थिति के बारे में और इस तरह के अनुप्रयोग राज्य के बारे में नहीं। तो सच्ची आत्माओं में, आपके पास एक URL होना चाहिए जैसे कि[host name]\[user name]\session , तब 'DELETE' लॉग आउट कार्रवाई के लिए सही क्रिया होगी।

[host name]\bla bla\logoutवास्तव में REST पूर्ण तरीके (IMO) के रूप में URL का उपयोग नहीं किया गया है, इसलिए इस पर GET / POST के सही उपयोग के बारे में बहस क्यों?

बेशक, मैं भी अपने अनुप्रयोगों में लॉगआउट यूआरएल के लिए GET का उपयोग करें :-)

Comments

उस स्थिति में, मैं तब तर्क दूंगा कि URL में [उपयोगकर्ता नाम] का हिस्सा अनावश्यक लगता है, क्योंकि उपयोगकर्ता हमेशा अपने सत्र से लॉगआउट करते हैं (यानी DELETE) ; कभी नहीं अन्य उपयोगकर्ताओं के :-)

— डैनियल Liuzzi

वास्तव में नहीं - हम कह रहे हैं कि सत्र एक संसाधन है और हम इसे हटाना चाहते हैं। इसलिए किसी भी सत्र को समान रूप से संबोधित करने के लिए, आपको URL के एक भाग के रूप में उपयोगकर्ता का नाम होना चाहिए। आपका तर्क उतना ही अच्छा है जितना कि [फोटो दीर्घा] \ _ चित्रों पर PUT कार्रवाई जारी करने के रूप में कहा जाता है कि आप अपनी तस्वीरों में जोड़ रहे हैं ([फोटो गैलरी] ([उपयोगकर्ता नाम] \ चित्रों पर उपलब्ध)। विभिन्न संसाधनों को स्पष्ट रूप से संबोधित करना होगा, इसमें कोई भी साक्षी नहीं हो सकता है। साइट अन्य उपयोगकर्ताओं को आपकी गैलरी में चित्र जोड़ने की अनुमति दे सकती है - यह एक्सेस कंट्रोल का एक हिस्सा होगा जैसे कि आपके पास एक सुपर उपयोगकर्ता हो सकता है जो किसी के सत्र को मार सकता है।

— 13 अक्टूबर को विनय

दार्शनिक रूप से, आप सत्र और फ़ोटो को 'संसाधन' कह सकते हैं, लेकिन वास्तविक रूप से मैं उनके साथ ऐसा व्यवहार नहीं करूंगा। सत्र हमेशा वर्तमान उपयोगकर्ता (इसलिए नाम सेशन) के लिए आंतरिक रूप से प्रतिबंधित है और कम से कम ASP.NET में, किसी अन्य उपयोगकर्ता के सत्र तक पहुंचने का कोई तरीका नहीं है। यहां तक ​​कि एप्लिकेशन डेवलपर के पास सभी सक्रिय सत्रों की गणना करने का कोई सीधा तरीका नहीं है, या सत्रों को व्यक्तिगत रूप से मारने का मतलब है। आप सभी सत्रों (InProc) को मारने के लिए आवेदन को पुनः आरंभ कर सकते हैं, लेकिन मैं उस अभिगम नियंत्रण को नहीं कहूंगा। एक तरफ URL, प्रश्न अभी भी बना हुआ है: GET या POST?

— डैनियल लियुज़ी

संसाधन, इसलिए इसका पता (URL) REST का महत्वपूर्ण हिस्सा है। इसलिए यदि आप URL का चयन करते हैं जैसा कि मैंने कहा, DELETE सही शब्द है - GET या POST नहीं। इसके अलावा, यहां तक ​​कि अगर आप खुद को ASP.NET तक सीमित कर रहे हैं, तो आप हमेशा अपने कस्टम राज्य प्रदाता रख सकते हैं जो आपको सत्रों के माध्यम से गणना करने और यदि आवश्यक हो तो अन्य सत्रों को मारने का रास्ता दे सकता है। आउट-ऑफ-सेशन सत्रों के लिए, Global.asax में कुछ फ़िडलिंग आपको कार्यक्षमता देनी चाहिए। यह वास्तव में एक सवाल है कि इस तरह की कार्यक्षमता की आवश्यकता होगी या नहीं। अक्सर ज़रूरतों के लिए, लोगों को साइट से बाहर निकालने के लिए वेब साइट को फिर से शुरू करना पड़ता है।

— विनयसी

यह मेरे लिए सबसे ज्यादा मायने रखता है। वेब एप को एक सत्र मार्ग दें और उस पर DELETE को कॉल करें। वह बनो ../session या ../session/current। थैंक्स @VinayC

— साइमन हूपर

Answer 5

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

Comments

दिलचस्प; मैंने कभी इस तरह से नहीं सोचा था। +1।

— strager

यह गर्भ धारण करने वाले अनुप्रयोग (कुछ प्रकार के "कैस्केडिंग डिलीट" व्यवहार) पर निर्भर हो सकता है, लेकिन आप सही हैं।

— एंड्रेस जान टैक

@JoelEtherton जोएल धन्यवाद, मैं नीचे जवाब पढ़ रहा था सोच रहा था जब मैं सही एक के लिए मिल जाएगा। :)

— किरिल फूच्स

यह भ्रामक है क्योंकि लॉगआउट स्थिति बदलता है। POST राज्य बदलने की क्रिया है। GET स्टेटलेस डेटा प्राप्त करने के लिए है। यह भ्रामक है क्योंकि हम उम्मीद करते हैं कि POST के पेलोड के अनुरोध हैं। जैसा कि नीचे उल्लेख किया गया है, DELETE एक सत्र वस्तु पर सबसे सही होगा।

— माइकल कोल

@MichaelCole: मैं POST और GET के बीच की कठिनाई के प्रतिनिधित्व से सहमत हूँ। मैं DELETE क्रिया के उपयोग से सहमत नहीं हूँ, यद्यपि। DELETE एक संसाधन को संभालने के लिए है, और सत्र इस अर्थ में एक संसाधन नहीं है। गौर कीजिए, अगर आप इसे डिलीट कर सकते हैं, तो आपको इसे PUT करने में भी सक्षम होना चाहिए।

— जोएल एथर्टन

Answer 6

मेरे दृष्टिकोण पर नमस्कार, जब आप लॉगिन करते हैं तो आप उपयोगकर्ता नाम / पासवर्ड की जांच करते हैं और यदि वे मेल खाते हैं तो आप लॉगिन टोकन बनाते हैं।

CREAT टोकन => विधि POST

जब आप लॉग आउट कर रहे हैं तो मेरे लिए टोकन को डिस्टर्ब कर दें तो सबसे तार्किक तरीका एक DELETE होना चाहिए

DELETE टोकन => पद्धति DELETE

Comments

दिलचस्प कोण।

— द्रुमबेग

मैं अपने स्प्रिंग बूट रीस्ट एप्लिकेशन में उस पद्धति का उपयोग करता हूं।

— कृपया _Dont_Bully_Me_SO_Lords

शब्दार्थ रूप से सही। मैं सहमत हूं ...

— डीएजी

Answer 7

प्री-कैशिंग का परिदृश्य एक दिलचस्प है। लेकिन मैं अनुमान लगा रहा हूं कि अगर बहुत सारी साइटें एसओ इस बारे में चिंता नहीं करती हैं तो शायद आपको भी नहीं करना चाहिए।

या शायद लिंक को जावास्क्रिप्ट में लागू किया जा सकता है?

संपादित करें: जैसा कि मैं इसे समझता हूं, तकनीकी रूप से एक GET केवल-पढ़ने के लिए अनुरोध के लिए होना चाहिए, जो एप्लिकेशन स्थिति को नहीं बदलता है। एक POST राज्य बदलने वाले अनुरोधों को लिखने / संपादित करने के लिए होना चाहिए। हालाँकि, अन्य एप्लिकेशन समस्याएँ कुछ राज्य-बदलते अनुरोधों के लिए POST से अधिक प्राप्त कर सकती हैं, और मुझे नहीं लगता कि इससे कोई समस्या है।

Comments

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

— डैनियल लियुज़ी

Answer 8

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

Comments

क्या आप "लॉग आउट स्क्रिप्ट" विस्तृत कर सकते हैं? मैं नहीं यकीन है कि अगर आप एक कुकी समाप्ति की स्थापना की बात कर रहे है (जो उपयोगकर्ताओं को दे मैन्युअल लॉगआउट का एक तरीका की आवश्यकता को समाप्त नहीं करता है।)

— डैनियल Liuzzi

एक लॉग आउट स्क्रिप्ट से उपयोगकर्ता का सत्र समाप्त हो जाएगा (वास्तव में: ब्राउज़र) इसे कॉल करना। ASP.net में, सत्र सर्वर साइड ऑब्जेक्ट है जिसे छोड़ दिया जा सकता है। PHP में एक समान प्रणाली है। क्योंकि वह ब्राउज़र सत्र समाप्त करने वाली स्क्रिप्ट को कॉल करता है, यह पहले से ही जानता है कि किसे समाप्त करना है, POST या GET चर की आवश्यकता को समाप्त करना।

— रॉब

हां, अब मैं तुम्हें ले आता हूं। मेरे पास पहले से ही स्क्रिप्ट है, विशेष रूप से FormsAuthentication.SignOut (), लेकिन मेरा सवाल यह है कि स्क्रिप्ट को कैसे प्राप्त किया जाए, जैसा कि GET या POST में है।

— डैनियल लियुज़ी

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

— रोब

Answer 9

हाल ही में मैं एक परियोजना पर काम कर रहा था जिसमें मैं गेट टू लॉगआउट का उपयोग कर रहा हूं, यह कोड नोड्स एक्सप्रेस में है और यह पूरी तरह से ठीक है

आपका रूटर .js

const express = require("express");
router.get("/signout", signout);

आपका नियंत्रक। js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

Answer 10

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

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

Comments

wgetमकड़ी मोड में एक निजी विकी पर एक सही सत्र कुकी के साथ एक ऐसी चीज थी जिसे मुझे वास्तव में एक बार करना था। बेशक, पहले क्रॉल किए गए URL में से एक था /logout।

— हेलगी

SuperLogout.com पर जाकर देखें कि /logoutवास्तव में पृष्ठों के लिए विनाशकारी GET अनुरोध कितने हैं। उदाहरण के लिए, आपको फिर से Gmail में साइन इन करना होगा, फिर से चैट में साइन इन करना होगा, अपने द्वारा स्क्रॉल किए गए किसी भी Hangouts वार्तालाप में अपना स्थान ढूंढना होगा - और यह केवल Google.com के लिए है।

— डैन डस्केल्सस्कू