मैं कैसे सुनिश्चित कर सकता हूं कि उपयोगकर्ता केवल एक बार लॉग इन हो?

Question

कुछ साल पहले मैंने एक वेब ऐप विकसित किया जिसके लिए हम यह सुनिश्चित करना चाहते थे कि उपयोगकर्ता क्रेडेंशियल्स साझा नहीं कर रहे थे।

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

समाधान, हालांकि मेरे प्रबंधक द्वारा अनुमोदित, हमेशा मुझे हैकी लग रहा था। इसके अलावा, ऐसा लगता है कि इसे बाधित करना आसान होगा।

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

Answer 1

मैंने वर्तमान में लॉग इन उपयोगकर्ताओं के हैशटेबल को बनाए रखकर इसे कार्यान्वित किया है, कुंजी उपयोगकर्ता नाम था, मूल्य उनका अंतिम गतिविधि समय था।

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

जब उपयोगकर्ता कुछ भी करता है, तो आप उस समय हैशटेबल को अपडेट करते हैं (यदि आप इसे कोर पेज फ्रेमवर्क का हिस्सा बनाते हैं तो यह आसान है)।

यदि हैशटेबल में समय निष्क्रियता के 20 मिनट से अधिक है, तो आप उन्हें हटा दें। जब भी हैशटेबल की जांच की जाती है, तो आप इसे हर बार कर सकते हैं, इसलिए यदि आपके पास केवल एक उपयोगकर्ता था, और कई घंटे बाद लॉगिन करने की कोशिश की, उस प्रारंभिक जांच के दौरान, यह उन्हें निष्क्रिय होने के लिए हैशटेबल से हटा देगा।

सी # (untested) में कुछ उदाहरण:

public Dictionary<String,DateTime> UserDictionary 
{ 
    get 
    { 
     if (HttpContext.Current.Cache["UserDictionary"] != null) 
     { 
      return HttpContext.Current.Cache["UserDictionary"] as Dictionary<String,DateTime>; 
     } 
     return new Dictionary<String,DateTime>(); 
    } 
    set 
    { 
     HttpContext.Current.Cache["UserDictionary"] = value; 
    } 
} 

public bool IsUserAlreadyLoggedIn(string userName) 
{ 
    removeIdleUsers(); 
    return UserDictionary.ContainsKey(userName); 
} 

public void UpdateUser(string userName) 
{ 
    UserDictionary[userName] = DateTime.Now; 

    removeIdleUsers(); 
} 

private void removeIdleUsers() 
{ 
    for (int i = 0; i < UserDictionary.Length; i++) 
     { 
      if (user[i].Value < DateTime.Now.AddMinutes(-20)) 
       user.RemoveAt(i); 
     } 
} 

Answer 2

अत्यधिक सुरक्षित एप्लिकेशन में, आपको ऐसा करने की आवश्यकता हो सकती है। आप जो कर सकते हैं वह लॉग इन गिनती बढ़ाना है जो उस उपयोगकर्ता के लिए है जो लॉग इन करता है और आईपी पता। गिनती कभी नहीं होनी चाहिए 2. यदि ऐसा है तो आप अन्य आईपी आउट लॉग करते हैं और जिसे भी लॉग इन किया जाता है, उस आईपी को फेंक दिया जाता है। यह उपयोगकर्ता -1 को उपयोगकर्ता-2 को अपने क्रेडेंशियल देने से नहीं रोकता है, यह उपयोगकर्ता-1 के लिए अपने काम करने के लिए निराशाजनक होगा यदि उपयोगकर्ता -2 एक ही समय में कहीं और लॉग करता है।

Answer 3

मुझे इस समस्या का कोई मानक समाधान कभी नहीं मिला है। मेरे ऐप्स में से एक में मैंने यह सुनिश्चित करने के लिए जावास्क्रिप्ट + जावा का संयोजन किया था कि एक उपयोगकर्ता निर्दिष्ट आईपी (वास्तव में यह एक सत्र आईडी था) से केवल एक बार लॉग किया जा सकता है, लेकिन एक टाइमआउट के लिए काम करने के सबसे बुरे मामले में (सेट करने के लिए) 2 मिनट) खाता उपलब्ध नहीं था। मुझे नहीं लगता कि ऐसा करने का कोई आम तरीका नहीं है।

Answer 4

सिर्फ आईपी को देखते हुए अविश्वसनीय हो सकता है। आईआईआरसी प्रॉक्सी की कुछ शैलियों हैं जो कई आईपी पते पर खेत से बाहर जाने वाले अनुरोधों को यादृच्छिक रूप से करते हैं। आपके आवेदन के दायरे के आधार पर, यह आपको प्रभावित कर सकता है या नहीं। अन्य प्रॉक्सी एक आईपी से यातायात के ढेर दिखाएंगे।

अंतिम लॉगिन समय भी एक मुद्दा हो सकता है। कुकी आधारित प्रमाणीकरण पर विचार करें जहां प्रमाणीकृत कुकीज़ लगातार नहीं है (एक अच्छी बात है)। यदि ब्राउज़र क्रैश हो जाता है या बंद हो जाता है, तो उपयोगकर्ता को वापस लॉग इन करना होगा, लेकिन टाइमआउट समाप्त होने तक नहीं हो सकता है। यदि ऐप ट्रेडिंग स्टॉक के लिए है, तो 20 मिनट काम करने की लागत नहीं है और शायद अस्वीकार्य है।

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

Answer 5

मुझे बस यह समस्या थी।

हम एक Drupal साइट है कि एक फ्लेक्स अनुप्रयोग (ग्राहक द्वारा निर्मित) निहित बना रहे थे, और वह निम्नलिखित चाहता था: Drupal < से

1. पारदर्शी लॉगिन -> फ्लेक्स (! Bleh)
2. नहीं समवर्ती लॉगिन !!

वह हर समाधान से बाहर बकवास परीक्षण किया है, और अंत में, यह हम क्या किया है:

• हम हर यूआरएल के माध्यम से सत्र आईडी के साथ पारित कर दिया।
• उपयोगकर्ता लॉग-इन, हम एक टाइमस्टैम्प-आईपी SessionID-प्रयोक्ता नाम पदचिह्न
• हर पृष्ठ की स्थापना की है, डीबी पिंग किया गया था, और एक ही उपयोगकर्ता/एक अलग SessionID एक ही आईपी पर मिला था, तो w, वे पुराने उपयोगकर्ता हटा दिया गया था

यह समाधान हमारे ग्राहक की कठोर परीक्षण संतुष्ट

Answer 6

(अपने house..he में 2 कंप्यूटर हमें घंटे कोड में थोड़ा nooks और crannies को खोजने के लिए इससे पहले कि हम इस समाधान के लिए आया था रखा) मैं समस्या को चारों ओर बदल दूंगा, और किसी भी पहले लॉगिन के खर्च पर अंतिम लॉगिन की अनुमति दूंगा, इसलिए जब भी कोई उपयोगकर्ता लॉग ऑन करता है, तो किसी भी ओथ को समाप्त कर देता है एर लॉगिन सत्र वह हो सकता है।

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

Answer 7

इस तरह की 'फीचर' पर काम करने के लिए चेतावनी दी जा रही है - यह किनारे के मामलों का हाथी-जाल है जहां आप सोचते हैं कि आपने इसे नाखुश किया है और फिर आप या कोई और कहता है "लेकिन अगर कोई एक्स करता है तो क्या होगा?" और आप महसूस करते हैं कि आपको जटिलता की एक और परत जोड़नी है।

• उपयोगकर्ता सत्र की एक प्रति के साथ नया टैब खोलने पर क्या हुआ अगर:
  उदाहरण के लिए

  ?

• क्या होगा यदि उपयोगकर्ता एक नई ब्राउज़र विंडो खुलता है?
• यदि उपयोगकर्ता लॉग इन करता है और उनका ब्राउज़र क्रैश हो जाता है तो क्या होगा?

और इतने पर ...

मूल रूप से वहाँ कम या ज्यादा hacky समाधान कोई भी की एक सीमा है जिसमें से सरल और जो बनाए रखने के लिए कठिन होने जा रहे हैं के सभी कर रहे हैं। आम तौर पर ग्राहक का असली उद्देश्य कुछ अन्य वैध सुरक्षा लक्ष्य है जैसे 'उपयोगकर्ताओं को खातों को साझा करना बंद करें'।

सबसे अच्छा विचार यह पता लगाने के लिए है कि अंतर्निहित लक्ष्य क्या है और उसे पूरा करने का तरीका ढूंढें। और मुझे डर है कि एक तकनीकी जंगली हंस पीछा शुरू करने की बजाए वार्तालाप कूटनीति और अन्य ऐसे 'मुलायम कौशल' शामिल हैं ..,