SaaS एप्स में यूजर सेशन टाइमआउट हैंडलिंग - कई तरीकों पर चर्चा

Question

मुझे पता है कि यह डुप्लिकेट के रूप में चिह्नित होने का एक बड़ा मौका है, लेकिन मैं जो खोज रहा हूं वह बिल्कुल नहीं मिल सका

यह एक आम समस्या है और मुझे यकीन है कि इसमें कुछ अच्छी तरह से परिभाषित सर्वोत्तम अभ्यास समाधान है

पृष्ठभूमि

1. एक एकल पृष्ठ SaaS ऐप में बहुत सारे ड्रैग एंड ड्रॉप हैं, उपयोगकर्ता समय की अवधि के लिए बहुत सर्वर संचार के बिना इसके साथ बातचीत कर सकता है

2. सर्वर सत्र केवल उपयोगकर्ता ऑब्जेक्ट रखता है, एक गैर लगातार सत्र कुकी का उपयोग करके

3. X घंटे के बाद सर्वर पर सत्र समाप्त हो जाता है

4. कुछ चीजें केवल लॉग-इन के दौरान भरी हुई हैं

मुसीबत

1. उपयोगकर्ता ऐप पर काम करता है, जब किया जाता है, तो उपयोगकर्ता लॉग आउट नहीं करता है, बस ब्राउज़र को खुला रखता है
2. एक्स घंटे से अधिक के बाद उपयोगकर्ता वापस आता है (सत्र सर्वर पर अमान्य है)
3. उपयोगकर्ता को सर्वर कनेक्शन की आवश्यकता के बिना ऐप के साथ इंटरैक्ट करता है (ड्रग्स और चीजें ड्रॉप करता है, टेक्स्ट एडिट ...)
4. केवल अगले सर्वर इंटरैक्शन पर (मान लें कि कोई ऑटो सेव नहीं है) उपयोगकर्ता को लॉगिन पृष्ठ पर फेंक दिया जाता है और अपना कुछ काम खो देता है

संभव समाधान

यहां कुछ समाधान दिए गए हैं, जिन्हें मैं सुनना चाहता हूं कि क्या कोई अन्य है, और यदि उनमें से किसी के साथ भी कुछ गलत है।

1. उपयोगकर्ता को कभी भी लॉग आउट न करें

• कैसे? या तो एक लंबा सत्र रखें, लगातार कुकी रखें, या javaScript "ज़िन्दा रखें" पिंग करें
• पेशेवरों : उपयोगकर्ता को कुछ भी चिंता करने की ज़रूरत नहीं है, उनके लिए समस्या को ठीक करता है
• विपक्ष : पीसीआई के अनुरूप नहीं, सुरक्षित नहीं है, और विकास में बदलाव की जरूरत है, उदाहरण के लिए केवल उपयोगकर्ता लॉग पर सत्र के लिए भरी हुई चीजें एक पब उप मॉडल (घटना परिवर्तन पर सुन) या कैश टाइमआउट के लिए स्थानांतरित करने की आवश्यकता है।

2. स्थानीय भंडारण

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

3. ऑटो बचाओ

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

• कैसे? मॉडल को बाँधने के लिए एक MV ** फ्रेमवर्क (Backbone.js / Knockout.js / Ember.js / Angular.js आदि) का उपयोग करें, और परिवर्तनों पर बने रहें।
• पेशेवरों : एक साफ समाधान की तरह लगता है, सत्र तब तक सक्रिय होता है जब तक उपयोगकर्ता सक्रिय होता है, कोई क्लाइंट साइड काम इसे जारी रखने के बिना नहीं किया जाता है।
• विपक्ष : अंतिम क्रिया उपयोगकर्ता सत्र समय समाप्त होने के बाद कर रहा है।

4. सत्र समाप्त होने के बाद उपयोगकर्ता को लॉग आउट करें

इसके कई दृष्टिकोण हो सकते हैं

1. सर्वर से "सत्र समाप्त हो गया है" पूछें - यह एक पकड़ 22 / श्रोडिंगर की एक बिट है, क्योंकि सर्वर के लिए केवल सवाल सत्र का विस्तार करता है (टाइमआउट को पुनरारंभ करता है),

   • कैसे? या तो एक सर्वर है जो इस तरह के प्रश्न का समर्थन करता है (मुझे किसी के बारे में पता नहीं है, लेकिन मैं जावा भूमि बनाता हूं) या, कोई व्यक्ति केवल सत्र आईडी की एक तालिका रख सकता है, और अंतिम बार मैन्युअल रूप से पहुंच सकता है, और सत्र पारित करके सर्वर से पूछ सकता है कुकी के बजाय एक पैरामीटर के रूप में आईडी, मुझे यकीन नहीं है कि यह भी संभव है, लेकिन यह खतरनाक, असुरक्षित और खराब डिजाइन लगता है।
   • पेशेवरों : यदि सर्वर में ऐसा मूल समर्थन था, तो एक साफ, वैध प्रश्न की तरह लगता है (यह पूछते हुए कि क्या उपयोगकर्ता X के पास अभी भी सत्र है या नहीं और इसे नवीनीकृत किए बिना यदि वे करते हैं)
   • विपक्ष : यदि सर्वर इसका समर्थन नहीं करता है (और फिर से, मुझे नहीं पता कि किसी भी सर्वर या फ्रेमवर्क में यह कार्यक्षमता है), तो वर्कअराउंड में भारी जोखिम संभावित हैं।

2. मैंने सुना है एक वर्कअराउंड सर्वर साइड पर एक छोटा सत्र है, और एक जीवित ग्राहक पक्ष पिंग है, जिसमें पिंग की अधिकतम संख्या है

   • कैसे? सर्वर पर शॉर्ट सेशन, क्लाइंट हर सेशन टाइमऑउट / 2 में, Y के अधिकतम रिट्रीव करता है।
   • पेशेवरों : समस्या को हल करता है, त्वरित और गंदा
   • विपक्ष : एक हैक की तरह महसूस करता है, सर्वर को करने देने के बजाय सत्र को खुद को नवीनीकृत करना

3. ग्राहक पक्ष टाइमर

   • कैसे? ग्राहक पक्ष पर एक टाइमर रखें और सर्वर के साथ इसे सिंक करें इसे प्रत्येक अनुरोध पर पुनरारंभ करके अधिकतम सर्वर सत्र टाइमआउट के बराबर होने के लिए कुछ पैडिंग है, उपयोगकर्ता द्वारा सर्वर को कोई अनुरोध नहीं भेजने के बाद, यूआई एक "सत्र दिखाता है" क्या आप इसे जारी रखना चाहते हैं? " (जैसे आपके पास ऑनलाइन बैंकिंग है)

   • पेशेवरों : समस्या को ठीक करता है

   • विपक्ष : सिंक कार्यों को सुनिश्चित करने की आवश्यकता को छोड़कर किसी के बारे में सोच भी नहीं सकते

प्रश्न

मैं शायद उपरोक्त विश्लेषण में कुछ याद कर रहा हूं, कुछ मूर्खतापूर्ण गलतियां हो सकती हैं, और मैं उन्हें सुधारने में आपकी मदद करना चाहूंगा। इसके लिए मेरे पास और क्या उपाय हो सकते हैं?

Comments

मैं इस दृष्टिकोण से यहाँ अपने विचारों के साथ tastypie के कोणीय और django का उपयोग करता हूं: 4.1: आपके सभी संसाधनों के लिए उपयोग किए जाने वाले प्रमाणीकरण वर्ग आपके उपयोगकर्ता के लिए "अंतिम-उपयोग" फ़ील्ड के अब और समय के बीच के अंतर की जांच और तुलना कर सकता है। नमूना। 401 का समय कॉन्फ़िगर समय सीमा से अधिक है। 200 अन्यथा और 'अंतिम पहुँच' क्षेत्र के साथ अद्यतन करें now। 4.2 आपके सर्वर को मारने और एंड्रॉइड पर लागत को बढ़ाने के लिए 4.3 की तरह एक शानदार आवाज़ है। होम स्क्रीन पर लौटने पर मुझे पूरा यकीन है कि प्रक्रिया को रोक दिया गया है और यह आपके क्लाइंटसाइड टाइमर के साथ हस्तक्षेप भी कर सकता है।

— airtonix

Answer 1

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

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

लॉग आउट कभी नहीं किया जा सकता है जहाँ विनियमों की अनुमति होती है, लेकिन यह आपको गलतियों में ले जाता है जहाँ आप सही ढंग से संभाल नहीं पाते हैं यदि कोई अप्रत्याशित रूप से लॉग आउट हो जाता है, और सभी राज्य व्यापार को बनाए रखने के लिए थोड़ा गहन हो जाता है अगर वहाँ पर नज़र रखने के लिए बहुत कुछ है एक "सक्रिय" उपयोगकर्ता।

Answer 2

मैंने सुना है एक वर्कअराउंड सर्वर साइड पर एक छोटा सत्र है, और एक रखने> जिंदा ग्राहक पक्ष पिंग, जिसमें अधिकतम संख्या है

कैसे? सर्वर पर लघु सत्र, क्लाइंट हर सेशनटाइम / 2 को पिंग करता है, इसमें Y> पेशेवरों की अधिकतम संख्या होती है। समस्या का समाधान, त्वरित और गंदे को ठीक करता है। विपक्ष: एक हैक की तरह लगता है, सेशन रिन्यूअल को हैंडल करने के बजाय खुद को> सर्वर को करने दें।

यह मेरी राय में सबसे अच्छा समाधान है। आप इसे "गंदा हैक" क्यों मानते हैं?

यह वही बनाता है जो किया जाना चाहिए। जबकि उपयोगकर्ता कार्यक्रम के साथ काम करता है सत्र खुला रहेगा।

उपयोगकर्ता प्रोग्राम के साथ काम करने के लिए रुकने के बाद, सत्र बंद हो जाएगा।

लागू करने के लिए पर्याप्त सरल है।

वास्तव में क्या जरूरत है, अगर मैं सवाल सही समझ गया।

Comments

कभी-कभी गंदे हैक सबसे अच्छा समाधान होते हैं :) धन्यवाद। आपने प्रश्न को पूरी तरह से सही समझा

— एरन मेडन

Answer 3

मैं वास्तव में एक एप्लिकेशन बना रहा हूं जो इससे संबंधित है।

मैंने Django, Guradian और Tastypie का उपयोग करके एक RESTful सेवा की शुरुआत की। यह केवल APIKEY का उपयोग करके प्रमाणित करता है, वस्तुओं को प्राधिकरण अभिभावक द्वारा नियंत्रित किया जाता है।

Django ऐप में केवल एक टेम्प्लेट व्यू urlconf है जो base.html को लोड करता है ...

क्लाइंट पक्ष पर मैंने एंगुलर का उपयोग करके एक एप्लिकेशन बनाया।

जहाँ तक प्रमाणीकरण जाता है, वहाँ एक HTTP- नीति-अवरोधक है जो 401 प्रतिक्रियाओं को सुनता है।

जब एक 401 को पुनः प्राप्त किया जाता है, तो यह निवर्तमान अनुरोध को बफ़र करता है और "लॉगिन-आवश्यक" ईवेंट को बंद कर देता है। यह कई बार हो सकता है।

मेरे पास एक मोडल पॉपअप है जिसमें एक लॉगिन फ़ॉर्म है जो "लॉगिन-आवश्यक" घटना को सुनने के बाद प्रस्तुत किया जाता है, और यह एक लॉगिन करता है जो एक उपयोगकर्ता संसाधन (एक JSON बंडल) देता है जिसमें APIKEY भी होता है।

सभी बफ़र किए गए अनुरोध जो पहले 401 प्रतिसाद के परिणामस्वरूप थे, अब APIKEY के साथ फिर से अधिकृत किए गए हैं जिन्हें प्राधिकरण http हेडर में शामिल किया गया है।

मैं एक और कोणीय सेवा / फैक्ट्री का उपयोग करता हूं ताकि लोकलस्टोरेज जेनसन डेटा का प्रबंधन किया जा सके, और यहीं मैं उपयोगकर्ता नाम और एपिके स्टोर करता हूं।

हल करने के लिए छोड़ी गई पहेली का एकमात्र टुकड़ा यह है कि उस जानकारी को कैसे सुरक्षित किया जाए, और उस जानकारी पर टाइमआउट कैसे लागू किया जाए।

शायद अंतिम वैध http अनुरोध से टाइमस्टैम्प चेक का उपयोग करें।

Comments

इस पर अनुवर्ती कार्रवाई के रूप में, मैंने प्रत्येक tastypie प्रमाणीकरण जांच पर निम्न तुलना करने पर विचार किया है: current_time> user.lastlogin_time + settings.SESSION_TIMEOUT। अगर सच है तो वापस 401। प्रत्येक मान्य प्रमाणीकरण user.lastlogin_time को current_time में अद्यतन करता है।

— airtonix

यह काफी अच्छा है और मैंने इसे संभालने के बारे में भी सोचा।

— oligofren

Answer 4

मेरे मामले में, मैं 4.1 के समान कुछ का उपयोग कर रहा हूं। एक बहुत ही हल्के कोणीय संचालित AJAX जोंस अनुरोध में उपयोगकर्ता लॉग के बाद सर्वर के खिलाफ निर्धारित अंतराल पर REST API के लिए होता है। सुरक्षा आवश्यकताओं के कारण, मालिकाना यूआई का अनुमान है कि सर्वर उस उपयोगकर्ता के लिए एक सत्र बनाए रखेगा जो सर्वर की तरफ कुछ संरक्षित जानकारी, टेम्प्लेट, डेटा आदि संग्रहीत करता है। यह अभी भी सुरक्षा के दृष्टिकोण से मेरा पसंदीदा तरीका है। जब संवेदनशील डेटा (केवल हैशेड पासवर्ड और ऐसे नहीं) के साथ काम करते हैं, तो IMO इसे स्थानीय स्टोरेज में क्लाइंट साइड स्टोर करता है, आदि सर्वर साइड की तुलना में अधिक जोखिम पैदा करता है (मुझे यकीन है कि कोई मेरे साथ बहस करेगा)। तृतीय पक्ष सिस्टम के साथ संचार करते समय उसी API का उपयोग करते हैं, लेकिन हर अनुरोध पर प्रमाणीकरण क्रेडेंशियल भेजना चाहिए।

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

मेरे मामले में, विभिन्न उपयोगकर्ताओं के संगठन के भीतर उनकी भूमिकाओं के आधार पर अलग-अलग सत्र निष्क्रिय समयबाह्य हो सकते हैं। सर्वर जीवनकाल में अधिकतम सीमाएं रखता है लेकिन जब तक उपयोगकर्ता परिभाषित सीमाएं उन से कम होती हैं, यह ठीक काम करता है। एक बार जब सर्वर सत्र समाप्त हो जाता है, तो यह एक मूक मुद्दा है क्योंकि सत्र समाप्ति की प्रक्रिया पहले ही इनायत से संभाल ली गई होगी। यह मेरे द्वारा निर्मित व्यावसायिक अनुप्रयोग की आवश्यकता है।

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

यदि संयोग से सत्र अनियंत्रित तरीके से समाप्त हो जाता है (सत्र मेमस्कैड पर डंप हो जाते हैं), तो अगला अनुरोध जो सर्वर को प्रभावित करता है, उपयोगकर्ता को सूचित करेगा और उन्हें वापस एक वर्ग में ले जाएगा (शायद ही कभी होता है, लेकिन)।