2012-06-06 10 views
9

मुझे कहीं भी इस पर बहुत कुछ नहीं मिला। अधिकांश नमूना अनुप्रयोग केवल सुरक्षा आदि के बारे में बात नहीं करते हैं मान लें कि उपयोगकर्ता को एक आधारित आधारित API कॉल का उपयोग करके प्रमाणित किया जाएगा। प्रमाणीकरण की देखभाल करने के लिए एप्लिकेशन को कैसे संरचित किया जाना चाहिए [इसके अलावा प्राधिकरण]। नमूना आवेदन के लिए एक सूचक महान होगा। कृपया एकल पृष्ठ एप्लिकेशन के साथ-साथ सामान्य एप्लिकेशन के संदर्भ में विचार जोड़ें। [मुझे विश्वास है कि प्रत्येक दृश्य को इसकी देखभाल करनी चाहिए]बैकबोन.जेएस अनुप्रयोग में प्रमाणीकरण (सत्र) और प्रमाणीकरण को प्रबंधित करने के लिए सबसे अच्छा डिज़ाइन/आर्किटेक्चर अभ्यास क्या है

+1

नमूना अनुप्रयोग सुरक्षा के बारे में बात नहीं करते हैं क्योंकि कम (अगर कुछ भी है) बैकबोन-विशिष्ट बात करने के लिए विशिष्ट है। –

+0

बस इतना है कि मैं अधिक स्पष्ट हूं, मुझे सुरक्षा समझौता किए बिना प्रमाणीकरण/प्रमाणीकरण पैटर्न में दिलचस्पी है। जैसे क्या मुझे सत्र/प्राधिकरण जानकारी को सहेजने के लिए मध्यस्थ पैटर्न का उपयोग करना चाहिए और प्रत्येक दृश्य को प्रतिपादन से पहले इस जानकारी को देखना चाहिए। या इसे किसी अन्य माध्यम से देखभाल की जानी चाहिए –

+0

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

उत्तर

5

कुछ महीनों पहले एक एकल पृष्ठ ऐप करने में एक ही समस्या उत्पन्न हुई जो एक आरईएसटी आधारित एपीआई का उपभोग करती है। उत्तर के लिए खोज के बाद मैं क्या आया था HTTP की मौजूदा 401 और 403 त्रुटि का उपयोग करना था। मैंने अपनी एपीआई इन त्रुटियों को वापस कर दिया था। फिर इन त्रुटियों को संभालने के लिए विस्तारित त्रुटि हैंडलिंग मॉडल का उपयोग करके अपवादों को पकड़ा और राउटर navigate फ़ंक्शन के माध्यम से उन्हें अपने लॉगिन में भेज दिया।

var ErrorHandlerModel = Backbone.Model.extend({ 

    initialize: function(attributes, options) { 
     options || (options = {}); 
     this.on("error", this.errorHandler); 
     this.init && this.init(attributes, options); 
    }, 

    errorHandler: function(model, error) { 
     if (error.status == 401 || error.status == 403) { 
      app.history.navigate('login', true); 
     } 
    } 

}); 

मसा में, हालांकि मुझे लगता है कि यह सिर्फ बजाय एक वैश्विक jQuery ajaxError समारोह का उपयोग करने के लिए बेहतर हो गया होता। उपरोक्त स्निपेट कुछ महीने पहले इसी तरह के question posted here पर आधारित था।

मुझे बैकबोन डिफॉल्ट फ़ेच व्यवहार को ओवरराइड करना पड़ा ताकि मैं एपीआई की जेसन प्रतिक्रिया में प्रतिक्रिया प्रतिक्रिया को पकड़ने के लिए ओगिन के साथ एक त्रुटि ट्रिगर कर सकूं।

var Login = Backbone.Model.extend({ 

    urlRoot: '/login', 

    parse: function(resp,xhr) { 
     if (resp.response == 'success') { 
      app.history.navigate('dashboard', true); 
     } 
     else { 
      this.trigger('loginError');  
     } 
    return false; 
    } 
}); 
+0

यह अच्छा लगता है। आपने लोगों को प्रमाणीकरण जांच में रखा था ... क्या यह विचारों में या नियंत्रक में है। आइए लॉग इन के बाद उपयोगकर्ता डैशबोर्ड पर जमीन कहें, क्या आप नियंत्रक तत्कालता या दृश्य में प्रमाणीकरण कोड डालते हैं। मेरा मानना ​​है कि विचारों में प्राधिकरण जांच में डाल देना समझ में आता है। अगर मुझे पर्याप्त स्पष्ट नहीं है तो मुझे बताएं। –

+1

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

+0

ठंडा। बहुत बहुत धन्यवाद। इसे बंद करने से पहले आप कुछ नमूना कोड साझा करना चाहते हैं। –

1

मैं Mu की टिप्पणी से सहमत हूं। प्रमाणीकरण के मामले में बात करने के लिए बहुत कम है।

मानक HTML ऐप्स के साथ प्रमाणीकरण कैसे प्रबंधित करते हैं जो आपके सर्वर पर वापस पोस्ट करते हैं? ऐसा करने के लिए ऐसा करें क्योंकि ऐसा ही किया जाना चाहिए।

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

ब्राउज़र में जावास्क्रिप्ट सुरक्षित नहीं है, इसलिए ब्राउज़र में प्रमाणीकरण और प्रमाणीकरण पर भरोसा करने वाली चीजें न करें।

मैं यहाँ इस में से कुछ के बारे में एक छोटे से लेख लिखा था,: http://lostechies.com/derickbailey/2012/01/26/modularity-and-security-in-composite-javascript-apps/

+0

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

+0

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

+0

@ डेरिक बेली, मैंने नीचे एकमात्र कारण के लिए आपका जवाब वोट दिया कि मुझे पूछा गया कि इसमें कोई जवाब नहीं है। –

8

आप बिल्कुल सही है कि ज्यादातर नमूने सुरक्षा बिल्कुल पता नहीं कर रहे हैं। और नतीजतन मेरे पास एक अच्छा नमूना नहीं है जिसे मैं आपको इंगित कर सकता हूं। मैं केवल आपको बता सकता हूं कि हमने अपनी सामग्री कैसे बनाई:

  1. जैसा कि आपने सुझाव दिया है, हम उपयोगकर्ता को प्रमाणीकृत करने के लिए एक एपीआई कॉल करते हैं। में हमारे मामले में जावा सर्वर द्वारा जल्द से जल्द बनाया गया एक सत्र आईडी था क्योंकि उपयोगकर्ता ने पहले पृष्ठ पर क्लिक किया था (लॉग इन करने से पहले भी) और एक कुकी क्लाइंट पक्ष में संग्रहीत किया था। के बाद से है कि कुकी सर्वर के लिए हर HTTPS अनुरोध के साथ यात्रा करता है (यहां तक ​​कि AJAX डेटा प्राप्त करने के लिए कॉल या आदेशों प्रदर्शन) यह एक विशेष खाते सर्वर ओर एक बार उपयोगकर्ता को प्रमाणीकृत किया गया है के साथ जुड़ा हुआ है।

  2. यह मानते हुए कि सर्वर के लिए अपने परिवहन HTTPS है और कुकी कभी नहीं खुला इंटरनेट पर यात्रा करता है, कोई भी है कि मूल्य पर छिप कर बातें सुनना और उस उपयोगकर्ता के लॉग इन होने का नाटक कर सकते हैं।

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

  4. AJAX API पर कॉल भी प्रमाणित करने के लिए जब आप कर एक कुकी उन्हें कई कारणों से के लिए के साथ ( सत्र समाप्त हो गया है, सर्वर को पुन: प्रारंभ करने के लिए था और उपयोगकर्ता के सत्र भूल गया है है विफल हो सकता है, व्यवस्थापक ने उपयोगकर्ता, आदि को मजबूती से लॉग आउट किया)।हमारी राय में, यह महत्वपूर्ण है कि सर्वर अभी भी कुछ लौटाएं (यानी, खाली प्रतिक्रिया नहीं है) और यह लॉगिन पृष्ठ (जो AJAX अनुरोध के लिए बेकार है) पर रीडायरेक्ट की तरह कुछ नहीं होना चाहिए। तो हम हमेशा हमारे सभी कार्यों से JSend protocol प्रतिक्रियाओं को लौटते हैं और उपयोगकर्ता लॉग इन नहीं है, तो सर्वलेट फ़िल्टर किसी विशेष कोड के साथ एक मानक JSend "त्रुटि" प्रतिक्रिया देता है। इससे हमें हमारे क्लाइंट साइड कोड (जिसे आप को कस्टम सिंक में डाल सकते हैं) नोटिस कर सकते हैं कि उपयोगकर्ता लॉग इन नहीं है और लॉगिन के लिए संकेत देता है। यह भी संभव है कि आप लॉग इन करने के बाद स्वचालित रूप से फ़ंक्शन को फिर से प्रयास कर सकें लेकिन यह हमारे पास से अधिक परिष्कृत है।

  5. सिंक नोटिस होने से उपयोगकर्ता लॉग इन नहीं हुआ है या सुरक्षा उल्लंघन आपको दृश्यों में कुछ विशेष नहीं रखना है। वे जो भी अनुरोध करते हैं, वे सोचते हैं कि यह उचित है और यह या तो सफल होता है या नहीं। यदि कोई नया लॉगिन आवश्यक है, जो निम्न स्तर पर ट्रिगर हो जाता है।

  6. लॉग आउट कर वास्तव में आप सर्वर के निशान है कि लंबे समय तक के रूप में कोई में लॉग इन या सत्र रिकॉर्ड को छोड़ देता है सत्र को देखते हुए, तब तक स्थानीय कुकी को मारने के लिए की आवश्यकता नहीं है।

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

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

+0

धन्यवाद जॉन यह समझ में आता है। बस डेरिक के जवाब पर मेरी टिप्पणी देखें और मुझे बताएं कि आपके विचार क्या हैं। –

+0

यह एक शानदार जवाब है। मैं इन मुद्दों के बारे में सोच रहा हूं। धन्यवाद @ जॉन। अरे, स्थानीय कुकी या सत्र को सिर्फ नुक्सान करने के बजाय सर्वर पर लॉगआउट को मजबूर करना क्यों महत्वपूर्ण है? मैं वहां एक लाभ के बारे में सोच नहीं सकता। – SimplGy

+0

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

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

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