लॉगिन और पुनर्निर्देशन: वेबपेज लॉगिन के लिए सबसे अच्छा HTTP प्रवाह क्या है?




rest authentication (4)

यह प्रश्न सामान्य रूप से वेब-ऐप्स के लॉगिन प्रवाह के बारे में एक प्रश्न है सुरक्षा में रखते हुए मुझे उन उत्तरों में अधिक दिलचस्पी है जो उपयुक्तता और प्रदर्शन के लिए अनुकूल हैं

बुकमार्क किए गए यूआरएल को अप्रमाणित अनुरोधों को संभालने का सबसे उचित तरीका क्या है?

समस्या का प्रदर्शन करने के लिए, यहां एक उदाहरण के लिए कुछ मार्ग और संबंधित व्यवहार हैं:

GET /login         -> Display the authentication form
POST /processLogin -> process the username and password, 
                            if unauthentic...re-render the login form; 
                            otherwise...display the default page
GET /secret         -> if authenticated...display the secret resource;
                       otherwise...display a login form
POST /secret        -> if authenticated...perform a desirable, but potentially 
                                          non-idempotent action on the secret 
                                          resource
                       otherwise...display a login form

विकल्प 1: लॉगिन स्क्रीन प्रदर्शित करें, वांछित पृष्ठ पर रीडायरेक्ट करें

  1. उपयोगकर्ता बुकमार्क क्लिक करता है
  2. GET / गुप्त -> 200, छुपा क्षेत्र पथ = "/ गुप्त" के साथ गुप्त रूप से लॉगिन फ़ॉर्म प्रदर्शित करें
  3. पोस्ट / प्रोसेस लॉगिन -> 302 टू / राइट (पथ पैरामीटर का मान)
  4. GET / गुप्त -> 200, गुप्त संसाधन प्रदर्शित किया गया

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

विकल्प 2: लॉगिन स्क्रीन पर पुनर्निर्देशित करें, वांछित पृष्ठ पर रीडायरेक्ट करें

  1. उपयोगकर्ता बुकमार्क क्लिक करता है
  2. GET / secret -> 302 से / लॉगिन
  3. रीडायरेक्ट -> 200 के माध्यम से लॉगिन / लॉगिन, छिपे हुए क्षेत्र पथ = "/ गुप्त" के साथ प्रदर्शित लॉगिन फ़ॉर्म
  4. पोस्ट / प्रोसेस लॉगिन -> 302 टू / राइट
  5. GET / गुप्त -> 200, गुप्त संसाधन प्रदर्शित किया गया

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

विकल्प 3: लॉगिन स्क्रीन प्रदर्शित करें, इच्छित पृष्ठ प्रदर्शित करें

  1. उपयोगकर्ता बुकमार्क क्लिक करता है
  2. GET / गुप्त -> 200, गुप्त रूप से कार्रवाई के साथ लॉगिन फ़ॉर्म प्रदर्शित करें = "/ गुप्त"
  3. पोस्ट / गुप्त -> 200, गुप्त संसाधन प्रदर्शित किया गया

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

उज्जवल तरफ, आप इस तकनीक के साथ गोल गोलियों को कम करते हैं।

विकल्प 4: लॉगिन स्क्रीन पर पुनर्निर्देशन, वांछित पृष्ठ प्रदर्शित करें

  1. उपयोगकर्ता बुकमार्क क्लिक करता है
  2. GET / secret -> 302 से / प्रक्रिया लॉगिन
  3. रीडायरेक्ट मार्गे / प्रोसेस लॉगिन -> 200, एक्शन के साथ प्रदर्शित लॉगिन फार्म = "/ गुप्त"
  4. पोस्ट / रहस्य -> ​​302 से / गुप्त
  5. GET / गुप्त -> 200, गुप्त संसाधन प्रदर्शित किया गया

विश्लेषण: विकल्प 2 + 4 के समान समस्याएं

विकल्प 5: ???

क्या मुझे याद आ रही एक और तकनीक है?

सामान्य तौर पर, इनमें से किन तकनीकों की आप सिफारिश करेंगे?

यह भी देखें

लॉगिन पृष्ठ पर रीडायरेक्ट करते समय सही HTTP स्थिति कोड क्या है? लॉग इन के लिए किस प्रकार के HTTP पुनर्निर्देशित हैं? रीडायरेक्ट के साथ HTTP प्रतिसाद, लेकिन बिना गोलिपूर्ण?


नोट करें कि मैकेरेइस सही है, टूटी बैक बटन की खामियों के बिना AJAX विकल्प 3 का उपयोग करता है हालांकि, इसका अर्थ है कि उपयोगकर्ता को जावास्क्रिप्ट सक्षम होना चाहिए। ऐसा कहा जा रहा है, यदि आप अपने फॉर्म को ठीक से प्रोग्राम करते हैं, तो आप यह पता लगा सकते हैं कि क्या जेएस मौजूद है, अगर विकल्प 1 का उपयोग नहीं किया जाए

ध्यान दें कि 302 प्रतिक्रिया ठीक है, हालांकि, आपको कैश के साथ समस्याएं हो सकती हैं। आपको यह सुनिश्चित करना है कि यदि आप उसी यूआरआई के लिए 2 पूरी तरह से भिन्न पृष्ठ / फ़ॉर्म दिखाना चाहते हैं, तो कुछ भी कैश नहीं किया जाता है। (/ गुप्त लॉगिन और फिर वास्तविक रहस्य दिखा रहा है।)


मेरा $ .02: मैंने हाल ही में विकल्प 2 का उपयोग करके कार्यान्वित किया है (हालांकि मैं एक सत्र में संग्रहीत /secret हूं, प्रवेश फ़ील्ड में छिपे हुए क्षेत्र के रूप में नहीं)।

मैं आपकी चिंताओं को पूरी तरह से साझा नहीं करता हूं:

जोड़े गए समस्या जो लॉगिन परिवर्तन के दौरान ब्राउज़र द्वारा प्रदर्शित यूआरएल है, जो उपयोगकर्ता को भ्रमित करता है और बुकमार्क, लिंक साझाकरण आदि को तोड़ता है।

/login पुनर्निर्देशन, और यूआरएल के बाद के परिवर्तन में, यूजर को बताता है कि इससे पहले कि वे कुछ और जारी रख सकें, जो पहले किए जाने की जरूरत है: प्रवेश करना

चूंकि एक लॉगिन पृष्ठ 'लक्ष्य पृष्ठ' से पूरी तरह अलग दिखाई देगा, मुझे नहीं पता कि यह लोगों को बुकमार्क करने और / या लिंक पेज को साझा करने के बजाय लॉगिन पृष्ठ को साझा करने में कैसे भ्रमित करेगा (चूंकि लॉगिन पृष्ठ में शामिल नहीं होगा जानकारी वे बुकमार्क्स / साझा करना चाहते हैं)

और अगर आप 302 के मानक को तोड़ने के बारे में चिंतित हैं (हालांकि मुझे पता है कि हर एक ब्राउज़र खुशी से इसे तोड़ देगा), बजाय 303 का इस्तेमाल करने पर विचार करें।


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


विकल्प 1 और 3 HTTP आरएफसी को "गुप्त रूप से प्रदर्शित लॉगिन फॉर्म" का पालन नहीं कर रहे हैं, जो 200 GET प्रतिसादिता के विपरीत है, जहां "अनुरोधित संसाधन से संबंधित एक इकाई प्रतिक्रिया में भेजी जाती है" उम्मीद की जाती है

विकल्प 2 ठीक है सभी आधुनिक ब्राउज़र्स 302 POST पर समर्थन करते हैं और कई रेस-आधारित फ्रेमवर्क (जैसे आरओआर) सक्रिय रूप से इसका इस्तेमाल करते हैं वैकल्पिक रूप से "302 से / लॉगिन" में आप पहले से ही सत्र (कुकी) बना सकते हैं और URL को सत्र में सत्र में संग्रहीत कर सकते हैं, तो GET पैरामीटर में मूल यूआरएल से बचने के लिए प्रयोज्यता के दृष्टिकोण से, आपके पास लॉगिन पृष्ठ पर भी एक उपयुक्त संदेश हो सकता है (मुझे लगता है कि यूआरएल मेल नहीं है यहाँ पर - आप उपयोगकर्ता को सामग्री को वैसे भी नहीं देख सकते हैं)।

विकल्प 4: जब आप / गुप्त को पोस्ट करते हैं, तो HTTP आरएफसी आपको "अनुरोध-यूआरआई अनुरोध-यूआरआई में पहचान के संसाधन के एक नए अधीनस्थ के रूप में अनुरोध में संलग्न इकाई को स्वीकार करने के लिए" अनुरोध करता है, लेकिन आप जो भी कर रहे हैं वह प्रवेश कर रहा है में और इसके तहत नया / गुप्त बनाने में कुछ भी नहीं

तो निम्नलिखित HTTP आरएफसी, आपका सबसे अच्छा विकल्प विकल्प 2 है दरअसल विकल्प 2 POST-> रीडायरेक्ट-> डिज़ाइन पैटर्न के अनुरूप है, जो कि बुकमार्क किए गए यूआरएल को पोस्ट किए गए संसाधनों में अनिश्चितता के मुद्दे को हल करने में मदद करता है।





web