Meteor.userId बदल सकता है

Question

उल्का के साथ खेलना, मैंने पाया है कि असुरक्षित पैकेज को हटाकर भी, ग्राहक Meteor.userId फ़ंक्शन को बदल सकता है। उदाहरण के लिए,

Meteor.userId=function() {return "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"} 

रूप Meteor.default_connection.userId() (पुनः निर्देशित समारोह) के साथ किया जा सकता है। मैं इसे कैसे सुरक्षित करूं?

Answer 1

यह एक अच्छा सवाल है क्योंकि यह दिखाता है कि उल्का सुरक्षा मॉडल कैसे काम करता है।

यहां कोई सुरक्षा समस्या नहीं है क्योंकि उल्का कभी क्लाइंट कोड पर भरोसा करता है।

उल्का में, केवल सर्वर तय करता है कि प्रत्येक क्लाइंट के पास किस डेटा तक पहुंच है (Meteor.publish देखें) और प्रत्येक क्लाइंट को कौन सा डेटा बदलने की अनुमति है (Meteor.allow देखें)। जब कोई ग्राहक सर्वर को प्रमाणित करता है, तो सर्वर उपयोगकर्ता की आईडी संग्रहीत करता है। जब तक कि ग्राहक लॉग आउट नहीं करता है, यह उस URL को आपके Meteor.publish और Meteor.allow सर्वर पर userId के रूप में प्रदान करता है।

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

यह तो आपको सुरक्षित दलों एप्लिकेशन का उपयोग करके कर सकते हैं:

1. $ meteor create --example parties
2. के साथ एक पार्टियों ऐप्स बनाएं एक पार्टी बनाने के लिए एक उपयोगकर्ता खाते और डबल क्लिक बनाएं नक्शे पर। इसे एक निजी पार्टी बनाने के लिए बॉक्स को चेक करें।
3. जावास्क्रिप्ट कंसोल खोलें और Meteor.userId() टाइप करें ताकि उपयोगकर्ता का आईडी प्राप्त हो सके।
4. लॉग आउट करें। पार्टी स्क्रीन से गायब हो जाएगी क्योंकि सर्वर इसे किसी अन्य उपयोगकर्ता को प्रकाशित नहीं करेगा।
5. अब, कंसोल में जाएं और Meteor.userId() को एक नए फ़ंक्शन के साथ ओवरराइट करें जो आपके इच्छित आईडी लौटाता है।

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

वास्तव में, क्लाइंट उपयोगकर्ता आईडी को अपनी इच्छानुसार सेट करने के लिए यह पूरी तरह से सुरक्षित है! आप खाते की प्रणाली में सीधे पहुंच सकते हैं और Meteor.default_connection.setUserId("aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"); पर कॉल कर सकते हैं। इसे आज़माएं, और आप देखेंगे कि ऊपरी दाएं कोने में लॉगिन बटन एनीमेशन में बदल जाता है। ऐसा इसलिए है क्योंकि क्लाइंट आपके द्वारा सेट किए गए लॉग इन उपयोगकर्ता का ईमेल पता दिखाने के लिए Meteor.user() पर कॉल कर रहा है। लेकिन चूंकि आपने उस उपयोगकर्ता के रूप में सर्वर में लॉग इन नहीं किया है, यह उस उपयोगकर्ता के बारे में कोई जानकारी प्रकाशित नहीं कर रहा है और आप केवल स्पिनी प्राप्त करते हैं।

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

Answer 2

मैंने दो ब्राउज़र का उपयोग करके उल्का का परीक्षण किया और स्थानीय ब्राउज़र Meteor.userId और Meteor.loginToken प्रत्येक ब्राउज़र के बीच कॉपी किया और दोनों ने मुझे एक ही व्यक्ति के रूप में लॉग इन किया। जब मैंने एक से लॉग आउट किया तो मैं अभी भी दूसरे में प्रकाशित करने में सक्षम था।

मुझे नहीं लगता कि यह उतना सुरक्षित है जितना बाहर किया जा रहा है।

यदि मैं इन मानों की प्रतिलिपि बना सकता हूं और फिर भी एक ही उपयोगकर्ता के रूप में देखा जा सकता है, तब भी जब मैं एक अलग ब्राउज़र का उपयोग कर रहा हूं, तो यह बिल्कुल सुरक्षित नहीं है।

---

अद्यतन

प्रतिबिंब पर ...

मैं इसे उपयोगकर्ता की IP address लॉग इन करने के लिए जब वे के लिए लॉग इन संभव होगा लगता है। फिर यदि कोई उपयोगकर्ता एक्सेस करने का प्रयास करता है और आईपी पता समान नहीं है तो आप उन्हें फिर से लॉग इन करने के लिए कह सकते हैं।