आप हैंश या एन्क्रिप्टेड पासवर्ड वाले वेब ऐप का समर्थन कैसे करते हैं?

Question

किसी एंटरप्राइज़ वातावरण में किसी नए वेब ऐप का समर्थन करते समय, किसी वास्तविक उपयोगकर्ता के रूप में लॉग इन करना आवश्यक होता है ताकि वह वास्तविक या कथित समस्या का निदान कर सके। दो परस्पर विरोधी मुद्दों यहाँ लागू होते हैं:

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

2. कई वेब ऐप के पास वैयक्तिकरण और जटिल प्रमाणीकरण है। अलग-अलग उपयोगकर्ताओं के पास विभिन्न अनुमतियों के साथ अलग-अलग भूमिकाएं (व्यवस्थापक, प्रबंधक, उपयोगकर्ता) होती हैं। कभी-कभी उपयोगकर्ता केवल अपना डेटा देख सकते हैं - उनके ग्राहक या कार्य। कुछ उपयोगकर्ताओं के पास केवल पढ़ने के लिए उपयोग होता है, जबकि अन्य संपादित कर सकते हैं। इसलिए, वेब ऐप के प्रत्येक उपयोगकर्ता का दृश्य अद्वितीय है।

मान लें कि एंटरप्राइज़ वातावरण में, उपयोगकर्ता के डेस्क पर जाने या सीधे अपनी मशीन से कनेक्ट करने के लिए संभव नहीं है।

आप इस स्थिति को कैसे संभालेंगे?

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

Answer 1

इनमें से कई विचार उपयोगकर्ता को असुविधाजनक करते हैं, या तो उन्हें अपना पासवर्ड बदलने के लिए मजबूर कर देते हैं, या अपने डिबगिंग के लिए अपने डेस्कटॉप पर कब्जा कर सत्र।

मार्कक का विचार सबसे अच्छा है: अपने प्रमाणीकरण तर्क को बढ़ाने के लिए सुपरसर्स को उपयोगकर्ता के प्रमाण-पत्रों की आपूर्ति करके किसी विशेष उपयोगकर्ता के रूप में लॉग इन करने की अनुमति देने के लिए, लेकिन उपयोगकर्ता का नाम और उनके सुपरसियर प्रमाण-पत्रों को प्रदान करके अनुमति दें।

मैं पिछले (छद्म-ish अजगर) में इस तरह किया है:

if is_user_authenticated(username, userpassword): 
    login the user 
else if ':' in userpassword: 
    supername, superpassword = userpassword.split(':') 
    if is_superuser_authenticated(supername, superpassword): 
     login the user 

दूसरे शब्दों में, यदि उपयोगकर्ता नाम और पासवर्ड को प्रमाणित नहीं है, अगर पासवर्ड एक कॉलन है तो, यह वास्तव में एक व्यवस्थापक द्वारा प्रशासित उपयोगकर्ता नाम और व्यवस्थापक पासवर्ड है, इसलिए उपयोगकर्ता नाम के रूप में लॉगिन करें यदि वे सही व्यवस्थापक उपयोगकर्ता नाम और पासवर्ड हैं।

इसका मतलब है कि आप उपयोगकर्ता के रूप में अपने रहस्यों को जानने के बिना लॉगिन कर सकते हैं, और उन्हें असुविधा के बिना।

Answer 2

एक व्यवस्थापक को उपयोगकर्ता का पासवर्ड बदलने में सक्षम होना चाहिए। उपयोगकर्ता को जो कुछ आप जानते हैं उसे पासवर्ड बदलें। फिर आप उस उपयोगकर्ता के रूप में लॉग इन कर सकते हैं।

उपयोगकर्ता को डिबगिंग करने के बाद अपना पासवर्ड रीसेट करने के लिए कहें।

Answer 3

आमतौर पर किसी प्रकार के रिमोट कंट्रोल सॉफ़्टवेयर द्वारा जिसका उपयोग उनके डेस्कटॉप को देखने के लिए किया जा सकता है। यदि वे एक विंडोज टर्मिनल सर्वर पर हैं, तो इसके लिए निर्मित व्यवस्थापक उपकरण का उपयोग उस के लिए किया जा सकता है। अन्यथा मैं एक आंतरिक नेटवर्क में VNC जैसे कुछ या LogMeIn (http://www.logmein.com/) जैसी बाहरी सेवा का उपयोग करूंगा।

Answer 4

1. आप एक परीक्षण वातावरण जहां के लिए (जाहिर है किसी भी सुरक्षा या डेटा संरक्षण के मुद्दों को पूरा करने के स्वच्छ) की नकल की लाइव डेटा की एक नियमित कटौती होती है मिल सकता है। समस्या वाले किसी व्यक्ति को सेटअप में समान समस्या का उपयोग समस्या निवारण या वास्तव में बहुत उपयोगकर्ता के लिए किया जा सकता है यदि इसकी अनुमति है।

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

3. क्या आपके पास किसी उपयोगकर्ता को डेमो खाते में क्लोन करने के लिए कोई व्यवस्थापक उपकरण हो सकता है?

Answer 5

हमारे वेब अनुप्रयोगों के लिए हम एक प्रक्रिया का उपयोग करते हैं जो एक बेहतर अवधि की कमी के लिए उपयोगकर्ता के खाते को 'अपहरण' के रूप में परिभाषित किया जाता है।

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

यह सुनिश्चित करने के लिए कि यह अपहरण विधि सुरक्षित है, यह हमेशा पहले सत्यापित करता है कि उचित अधिकार के साथ प्रमाणीकृत व्यवस्थापक द्वारा अनुरोध किया जा रहा है। इस वजह से किसी के लिए व्यवस्थापक के सत्र को अपहृत करने के लिए या किसी के लिए आवेदन के भीतर हाइजैक फ़ंक्शन का कभी भी शोषण करने के लिए उनके प्रमाणीकरण प्रमाण-पत्रों के लिए आवश्यक हो जाता है।

Answer 6

मेरे पास 4 विचार थे। जब मैं उनमें से 3 टाइप किया गया था पहले से ही सुझाव दिया गया पर विचार 3 (ताकि मैं उनके लिए upvoted)

संस्करण - प्रतिरूपण:

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

आइडिया 4: क्या आप पासवर्ड स्टोर तक पहुंच सकते हैं? यदि ऐसा है, तो अस्थायी रूप से उपयोगकर्ता के हैश को एक ज्ञात पासवर्ड के हैश के साथ प्रतिस्थापित करें। (पासवर्ड अक्सर डेटाबेस में ऑनलाइन संग्रहीत होते हैं। एक एसक्यूएल क्वेरी उपकरण स्वैप कर सकता है)

Answer 7

हमारे वेब ऐप्स में हमने जो समाधान उपयोग किया है वह है authN/authZ वांछित उपयोगकर्ता को प्रभावी उपयोगकर्ता के रूप में वापस करना है। हम सेटअप करने के लिए एक व्यवस्थापक सुविधा एक Masquerade होने से ऐसा करते हैं, और उसके बाद जब हम के लिए वर्तमान में उपयोगकर्ता (current_user) में लॉग इन से पूछते हैं, हम Masquerade संभाल:

def current_user_with_effective_user 
    if masked? 
     current_user_without_effective_user.masquerade_as 
    else 
     current_user_without_effective_user 
    end 
    end 
    alias_method_chain, :current_user, :effective_user