खोज…
उल्का खाते पैकेज
जब आपके पास उल्का के साथ प्रवेश करने की बात आती है तो आपके पास कुछ विकल्प होते हैं। सबसे आम तरीका उल्का के लिए accounts का उपयोग कर रहा है।
लेखा-पासवर्ड
यदि आप चाहते हैं कि उपयोगकर्ता आपकी साइट पर बनाने और पंजीकरण करने में सक्षम हों, तो आप accounts-password उपयोग कर सकते accounts-password ।
meteor add accounts-password का उपयोग कर पैकेज स्थापित करें।
उपयोगकर्ता बनाने के लिए, आपको Accounts.createUser(options, [callback]) का उपयोग करने की आवश्यकता है
options में निम्नलिखित गुणों के साथ एक वस्तु होनी चाहिए:
-
username: एक स्ट्रिंग के रूप में उपयोगकर्ता का उपयोगकर्ता नाम .. -
email: एक स्ट्रिंग के रूप में उपयोगकर्ता का ईमेल। -
password: एक स्ट्रिंग के रूप में उपयोगकर्ता (एन्क्रिप्टेड नहीं) पासवर्ड। -
profile: उपयोगकर्ता का वैकल्पिक अतिरिक्त डेटा एक वस्तु के रूप में। यह उदाहरण के लिए उपयोगकर्ता का पहला और अंतिम नाम हो सकता है।profileवैकल्पिक है, हालांकि।
कॉलबैक 1 चर देता है यदि कोई त्रुटि होती है, जो एक Meteor.Error ऑब्जेक्ट है।
आपको केवल username या email का उपयोग करने की आवश्यकता है, इसलिए आप उपयोगकर्ता नाम वाला कोई उपयोगकर्ता बना सकते हैं, लेकिन कोई ईमेल नहीं, और इसके विपरीत। आप दोनों का उपयोग भी कर सकते हैं।
यदि सब कुछ सही ढंग से चला गया तो यह नव निर्मित उपयोगकर्ता आईडी लौटाता है।
तो, आप उदाहरण के लिए इसका उपयोग कर सकते हैं:
// server side
var id = Accounts.createUser({
username: "JohnDoe",
email: "[email protected]",
password: "TheRealJohn123",
profile: {
firstName: "John",
lastName: "Doe"
}
}, function(err) {
console.log(err.reason);
});
यह स्वचालित रूप से आपको लॉग इन करेगा यदि उपयोगकर्ता ने सफलतापूर्वक बनाया था।
वह बनाने वाला हिस्सा है। लॉग इन करने के लिए आपको क्लाइंट पक्ष पर Meteor.loginWithPassword(identifier, password, [callback]) करना होगा।
identifier है username , email या userId अपने उपयोगकर्ता के किसी स्ट्रिंग के रूप में। password उपयोगकर्ता का (एन्क्रिप्टेड नहीं) password है।
कॉलबैक एक चर देता है यदि कोई त्रुटि है, जो एक Meteor.Error ऑब्जेक्ट है।
उदाहरण:
// client side
Meteor.loginWithPassword("JohnDoe", "TheRealJohn123", function(err) {
console.log(err.reason);
});
और यह खातों के मूल निर्माण और लॉग इन करने के लिए है।
उपयोगकर्ता डेटा तक पहुंच
आप क्लाइंट की तरफ देख सकते हैं कि उपयोगकर्ता को फोन करके में लॉग ऑन है Meteor.userId() जो उनके वापस आ जाएगी userId अगर वे में लॉग इन किया है, और undefined अगर वे में लॉग इन नहीं कर रहे हैं।
आप Meteor.user() से कुछ जानकारी प्राप्त कर सकते हैं। यदि उपयोगकर्ता लॉग इन नहीं है और यह कुछ उपयोगकर्ता डेटा है तो यह अपरिभाषित वापस आ जाएगा। यह आपको डिफ़ॉल्ट रूप से कोई पासवर्ड नहीं देगा, डिफ़ॉल्ट रूप से यह उपयोगकर्ता का उपयोगकर्ता आईडी, उपयोगकर्ता नाम और प्रोफ़ाइल ऑब्जेक्ट दिखाएगा।
यदि आप जांचना चाहते हैं कि उपयोगकर्ता किसी पृष्ठ पर लॉग इन है, तो आप currentUser हेल्पर का भी उपयोग कर सकते हैं। यह Meteor.user() की सामग्री को लौटा देगा। उदाहरण:
{{#if currentUser}}
<h1>Hello there, {{currentUser.username}}!</h1>
{{else}}
<h1>Please log in.</h1>
{{/if}}
अन्य खातों के कार्य
कुछ अन्य कार्य हैं जो हर खाते के पैकेज के लिए काम करते हैं।
आप Meteor.logout() का उपयोग करके लॉग आउट कर सकते हैं
डिफ़ॉल्ट प्रोफ़ाइल फ़ील्ड का उपयोग न करें
एक आकर्षक मौजूदा क्षेत्र है जिसे profile कहा जाता है जो डिफ़ॉल्ट रूप से तब जोड़ा जाता है जब एक नया उपयोगकर्ता पंजीकरण करता है। इस क्षेत्र को ऐतिहासिक रूप से उपयोगकर्ता-विशिष्ट डेटा के लिए एक स्क्रैच पैड के रूप में उपयोग करने का इरादा था - शायद उनकी छवि अवतार, नाम, परिचय पाठ आदि। इस वजह से, प्रत्येक उपयोगकर्ता पर profile फ़ील्ड क्लाइंट से उस उपयोगकर्ता द्वारा स्वचालित रूप से लिखने योग्य है । यह उस विशेष उपयोगकर्ता के लिए क्लाइंट के लिए स्वचालित रूप से प्रकाशित होता है।
यह पता चलता है कि डिफ़ॉल्ट रूप से बिना किसी सुपर स्पष्ट के फील्ड राइट होने का सबसे अच्छा विचार नहीं हो सकता है। नए Meteor Developers की कई कहानियां हैं जो फ़ील्ड्स को स्टोर कर रहे हैं जैसे कि profile पर isAdmin ... और फिर एक दुर्भावनापूर्ण उपयोगकर्ता आसानी से सेट कर सकता है कि जब भी वह चाहे, खुद को एडमिन बना सके। यहां तक कि अगर आप इस बारे में चिंतित नहीं हैं, तो दुर्भावनापूर्ण उपयोगकर्ताओं को आपके डेटाबेस में डेटा की मनमानी मात्रा को स्टोर करने देना अच्छा नहीं है।
इस क्षेत्र की बारीकियों से निपटने के बजाय, इसके अस्तित्व को पूरी तरह से नजरअंदाज करने में मदद मिल सकती है। आप सुरक्षित रूप से तब तक कर सकते हैं जब तक कि आप क्लाइंट से सभी लिखने से इनकार करते हैं:
// Deny all client-side updates to user documents
Meteor.users.deny({
update() { return true; }
});
यहां तक कि प्रोफ़ाइल के सुरक्षा निहितार्थों को अनदेखा करते हुए, अपने ऐप के सभी कस्टम डेटा को एक फ़ील्ड पर रखना अच्छा नहीं है। उल्का के डेटा ट्रांसफर प्रोटोकॉल में खेतों की गहराई से नेस्टिंग नहीं होती है, इसलिए दस्तावेज़ पर कई शीर्ष-स्तरीय फ़ील्ड में अपनी वस्तुओं को समतल करना एक अच्छा विचार है।