2012-10-07 12 views
5

पिरामिड के pyramid.authentication.AuthTktAuthenticationPolicy फ़ंक्शन का 'गुप्त' पैरामीटर वास्तव में क्या है? documentation कहता है कि यह "(एक स्ट्रिंग) है जिसका उपयोग auth_tkt कुकी हस्ताक्षर के लिए किया जाता है। आवश्यक है।" tutorial कहता है कि यह "एक स्ट्रिंग है जो इस नीति द्वारा प्रतिनिधित्व 'प्रमाणीकरण टिकट' मशीनरी द्वारा उपयोग की जाने वाली एन्क्रिप्शन कुंजी का प्रतिनिधित्व करती है"।पिरामिड AuthTktAuthenticationPolicy गुप्त पैरामीटर

auth_tkt कुकी हस्ताक्षर क्या है? यह 'प्रमाणीकरण टिकट' मशीनरी क्या है? क्या यह रहस्य कुछ ऐसा है जो मैं किसी डेटाबेस या किसी चीज़ में हैश के रूप में संग्रहीत करता हूं? मैं वास्तव में उलझन में हूँ।

उत्तर

13

एक tkt auth कुकी उपयोगकर्ता नाम और वैकल्पिक रूप से एक टाइमस्टैम्प समेत जानकारी के कई टुकड़ों का एक सुरक्षित हैश है, लेकिन उपयोगकर्ता पासवर्ड नहीं है। एक बार प्रमाणीकृत हो जाने पर, आप उपयोगकर्ता को ऐसी कुकी देते हैं, और जब भी उपयोगकर्ता आपको वापस लौटाता है तो उपयोगकर्ता नाम दोबारा निकालें और जानें कि यह वही उपयोगकर्ता है।

इस कुकी को सुरक्षित रखें, आपको सर्वर-साइड रहस्य होना चाहिए, हालांकि। केवल उस सर्वर के कब्जे में एक सर्वर इन कुकीज़ को बना सकता है; अगर किसी हमलावर को कभी पकड़ लिया जाता है तो वह इन उपयोगकर्ताओं के पासवर्ड जानने के बिना मनमाने ढंग से उपयोगकर्ताओं के लिए प्रमाणीकरण कुकीज़ उत्पन्न कर सकता है।

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

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

ध्यान दें कि गुप्त परिवर्तन बदलना मौजूदा सत्र अमान्य हो गया है, और उपयोगकर्ताओं को पुनः प्रमाणीकरण करना होगा।

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

1

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

संबंधित मुद्दे