2011-10-24 15 views
12

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

समस्या प्रमाणीकरण के साथ है। ऐप एक साझा ओएस उपयोगकर्ता खाते के साथ साझा मशीन पर चलाएगा। अगर मैं ऑफ़लाइन हूं, तो मैं उपयोगकर्ता को प्रमाणित कैसे करूं?

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

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

क्या मेरे पास कोई अन्य विकल्प है?

+0

जो मैंने पढ़ा है उससे पासवर्ड की समाप्ति सहायक से अधिक हानिकारक हो सकती है- http://www.cryptosmith.com/node/218 हालांकि, यदि आप अपना डेटाबेस उजागर कर रहे हैं तो यह मामला नहीं हो सकता है। –

उत्तर

9

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

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

1

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

प्रत्येक उपयोगकर्ता के पास केवल एक API कुंजी हो सकती है।

यह एपीआई कुंजी सर्वर को प्रमाणित करने के लिए सर्वर से किए गए किसी भी अनुरोध में जोड़ा जाता है।

जब उपयोगकर्ता लॉग आउट करता है, तो API कुंजी हटा दी जाती है। इसके अलावा एपीआई कुंजी को सर्वर पर शुद्ध किया जा सकता है, जो उपयोगकर्ता को सर्वर पर एक बार प्रमाणीकृत करता है।

मैं रुचि रखने वाले नोडज ओपन सोर्स प्रोग्राम्स के लिंक प्रदान कर सकता हूं जो आपकी रुचि रखते हैं तो इस दृष्टिकोण का उपयोग करें।

+0

मुझे निश्चित रूप से दिलचस्पी होगी, अगर ऐसा करने के लिए अभी भी एक लिंक प्रदान करें तो कृपया एक लिंक प्रदान करें। – GojiraDeMonstah

+0

यह एपीआई कुंजी देकर, एक समय सीमा भी अच्छी प्रैक्टिस है – Serdar

+0

यह पोस्ट http://www.staticapps.org/articles/authentication-and- प्राधिकरण पढ़ने के लिए एक अच्छा संसाधन है – Serdar

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