टी एल; डॉ
- हाँ, यह सुरक्षित है।
- यूआरएल को छिपाने, या "स्पूफिंग" को रोकने के बारे में चिंता न करें। हकीकत में, आप न तो कर सकते हैं, इसलिए आप दोनों के लिए तैयार हैं।
- संभावित बग: एक बार जब आप सत्र पर रीडायरेक्ट सेट करते हैं, तो अगला लॉगिन इसका पालन करेगा, चाहे सत्र समाप्त होने तक कोई फर्क नहीं पड़ता। इसका समाधान करने का एक तरीका केवल रीडायरेक्ट पथ को जीईटी पैरामीटर के रूप में सहेजता है (उत्तर के नीचे देखें)।
- सुरक्षा चिंताओं को पुनर्निर्देशित करने और अग्रेषित करने के लिए यहां nice cheat sheet है।
यह एक सुरक्षित वर्कफ़्लो है, यह मानते हुए कि आपका सर्वर आने वाले अनुरोधों को सभी सुरक्षित संसाधनों को प्रमाणित करता है।
जब आप पूछते हैं कि "अगर मुझे अभी भी रीडायरेक्ट करने से पहले अगले यूआरएल को सत्यापित करना चाहिए", तो इसका उत्तर नहीं है, लेकिन आपको यह सुनिश्चित करने के लिए कि यूआरएल (रीडायरेक्ट करने के बाद) में सभी अनुरोधों को सत्यापित करने की आवश्यकता है, वे लॉग इन हैं
आपके प्रश्न में, ऐसा लगता है कि आप यूआरएल से लॉग इन होने तक यूआरएल को छिपाने की कोशिश कर रहे हैं। यह आवश्यक नहीं होना चाहिए।
url 1: "/login" # anyone can access this
url 2: "/secure_page" # only a logged in user can access this
मान लें कि कोई उपयोगकर्ता में लॉग इन नहीं कर रहा है, और yoursite.com/secure_page करने के लिए नेविगेट करने की कोशिश करता है:
उदाहरण के लिए, मान लीजिए कि आप दो यूआरएल डालते हैं। उन्हें हर बार आपके लॉगिन पेज पर रीडायरेक्ट किया जाना चाहिए। अगर वे secure_page यूआरएल जानते हैं, तो आपकी सुरक्षा को समझौता नहीं करना चाहिए। वास्तव में, वे पहले से ही है कि यूआरएल, क्योंकि वे पहली जगह में है कि पृष्ठ पर भेज पता होना चाहिए, तो या तो उन्होंने इसे में टाइप, एक लिंक पर क्लिक करें, या यह किसी बुकमार्क या एक ब्राउज़िंग इतिहास में बचा लिया गया था। महत्वपूर्ण बात यह है कि जब आप secure_page पर अनुरोध संभालते हैं, तो आपको उन्हें लॉग इन करने की आवश्यकता होती है।
आप पूछते हैं कि क्या वे उस यूआरएल को "स्पूफ" कर सकते हैं जिसे वे रीडायरेक्ट कर रहे हैं। वे इस तरह के सत्र में सहेजते समय नहीं कर सकते हैं। हालांकि, वे लॉग इन करने के बाद इच्छित किसी भी यूआरएल को मार सकते हैं, इसलिए इससे कोई फर्क नहीं पड़ता कि वे यूआरएल को "स्पूफ" करते हैं।
तो क्योंकि वे पहले से ही है कि यूआरएल को जानते हैं और वे किसी भी यूआरएल वे के बाद वे में लॉग चाहते हिट कर सकते हैं, तो आप उपयोगकर्ता द्वारा की गई यूआरएल गुप्त रखने के लिए जरूरत नहीं है। ऐसा करने का एकमात्र लाभ एक सौंदर्यपूर्ण क्लीनर यूआरएल है। यही कारण है कि आप कई प्रवेश पृष्ठों है कि इस तरह दिखना देखें:
http://yoursite.com/login?next=secure_page
क्या हो रहा है वहाँ वे बचत कर रहे हैं कि एक HTTP GET पैरामीटर के रूप में अगले यूआरएल। हालांकि यह कम "साफ" है, यह अधिक स्पष्ट है, इसलिए इसमें इसके पेशेवर और विपक्ष हैं। और यदि वे बाद में लॉगिन पेज पर फिर से जाएं, तो वह रीडायरेक्ट नहीं होगा, जो आपका वांछित व्यवहार हो सकता है। आपके वर्तमान कोड के साथ, एक बार जब रीडायरेक्ट सत्र पर होता है, तो उसके बाद यह अगला लॉगिन सत्र समाप्त होने तक रीडायरेक्ट का पालन करेगा, जो उपयोगकर्ता के चलने के बाद हो सकता है और कोई और उस वेब ब्राउज़र का उपयोग करता है।
कई साइटों यह रास्ता मैं ऊपर से पता चला है। Django does it that way। इस मामले में, दुर्भावनापूर्ण लिंक "अगला" यूआरएल प्रदान कर सकता है और यह कुछ फ़िशिंग साइट पर पुन: निर्देशित किया है, लेकिन है कि आसानी से "अगला" यूआरएल सुनिश्चित आपके डोमेन से बाहर नेविगेट नहीं करता से रोका जा सकता है।
यहाँ रीडायरेक्ट/आगे सुरक्षा के लिए एक basic cheat sheet (आप रीडायरेक्ट कर रहे हैं, लेकिन यहाँ लैंडिंग दूसरों अग्रेषण अनुरोध पर विचार किया जा सकता है) है।