Szukaj…
Pakiet kont Meteor
Masz kilka opcji logowania do Meteora. Najpopularniejszą metodą jest używanie accounts
dla Meteor.
Konta-hasło
Jeśli chcesz, aby użytkownicy mogli tworzyć i rejestrować się w Twojej witrynie, możesz użyć accounts-password
.
Zainstaluj pakiet za pomocą meteor add accounts-password
.
Aby utworzyć użytkownika, musisz użyć Accounts.createUser(options, [callback])
options
musi być obiektem o następujących właściwościach:
-
username
: nazwa użytkownika jako ciąg .. -
email
:email
użytkownika jako ciąg. -
password
:password
użytkownika (nieszyfrowane) jako ciąg. -
profile
: opcjonalne dodatkowe dane użytkownika jako obiekt. Może to być na przykład imię i nazwisko użytkownika.profile
jest jednak opcjonalny.
Funkcja zwrotna zwraca 1 zmienną, jeśli wystąpi błąd, którym jest obiekt Meteor.Error.
Wymagane jest tylko podanie username
lub email
, dzięki czemu można utworzyć użytkownika o nazwie użytkownika, ale bez adresu e-mail i odwrotnie. Możesz także użyć obu.
Zwraca nowo utworzony identyfikator użytkownika, jeśli wszystko poszło poprawnie.
Możesz na przykład użyć tego:
// server side
var id = Accounts.createUser({
username: "JohnDoe",
email: "[email protected]",
password: "TheRealJohn123",
profile: {
firstName: "John",
lastName: "Doe"
}
}, function(err) {
console.log(err.reason);
});
Automatycznie zaloguje się również, jeśli użytkownik został pomyślnie utworzony.
To jest część tworząca. Aby się zalogować, musisz użyć Meteor.loginWithPassword(identifier, password, [callback])
po stronie klienta.
identifier
jest username
, email
lub userId
jako ciąg ze swojego użytkownika. password
to (nieszyfrowane) password
użytkownika.
Funkcja zwrotna zwraca jedną zmienną, jeśli wystąpi błąd, którym jest obiekt Meteor.Error.
Przykład:
// client side
Meteor.loginWithPassword("JohnDoe", "TheRealJohn123", function(err) {
console.log(err.reason);
});
I to jest to do podstawowego tworzenia kont i logowania.
Dostęp do danych użytkownika
Możesz sprawdzić po stronie klienta, czy użytkownik jest zalogowany, wywołując Meteor.userId()
który zwróci jego userId
jeśli jest zalogowany, i undefined
jeśli nie będzie zalogowany.
Możesz uzyskać niektóre informacje z Meteor.user()
. Zwróci niezdefiniowane, jeśli użytkownik nie jest zalogowany, a niektóre dane użytkownika, jeśli są. Domyślnie nie poda żadnych haseł, domyślnie wyświetli identyfikator użytkownika, nazwę użytkownika i obiekt profilu.
Jeśli chcesz sprawdzić, czy użytkownik jest zalogowany na stronie, możesz również użyć currentUser
pomocniczego Użytkownika. Meteor.user()
zawartość Meteor.user()
. Przykład:
{{#if currentUser}}
<h1>Hello there, {{currentUser.username}}!</h1>
{{else}}
<h1>Please log in.</h1>
{{/if}}
Inne funkcje kont
Istnieje kilka innych funkcji, które działają dla każdego pakietu kont.
Możesz się wylogować za pomocą Meteor.logout()
Nie używaj domyślnego pola profilu
Istnieje kuszące istniejące pole o nazwie profile
które jest dodawane domyślnie podczas rejestracji nowego użytkownika. To pole było historycznie przeznaczone do użycia jako notatnik dla danych specyficznych dla użytkownika - być może ich awatara, nazwy, tekstu wprowadzającego itp. Z tego powodu pole profile
dla każdego użytkownika jest automatycznie zapisywane przez tego użytkownika od klienta . Jest również automatycznie publikowany w kliencie dla tego konkretnego użytkownika.
Okazuje się, że domyślnie zapisywanie pola bez uczynienia tego super oczywistym może nie być najlepszym pomysłem. Istnieje wiele historii o nowych isAdmin
Meteor przechowujących pola takie jak isAdmin
w profile
… a następnie złośliwy użytkownik może łatwo ustawić to na prawdziwe, kiedy tylko chce, stając się administratorem. Nawet jeśli nie przejmujesz się tym, nie jest dobrym pomysłem, aby złośliwi użytkownicy mogli przechowywać dowolne ilości danych w bazie danych.
Zamiast zajmować się specyfiką tego pola, pomocne może być całkowite zignorowanie jego istnienia. Możesz to zrobić bezpiecznie, dopóki nie odrzucisz wszystkich zapisów od klienta:
// Deny all client-side updates to user documents
Meteor.users.deny({
update() { return true; }
});
Nawet ignorując wpływ profilu na bezpieczeństwo, nie jest dobrym pomysłem umieszczenie wszystkich niestandardowych danych aplikacji w jednym polu. Protokół przesyłania danych Meteor nie powoduje głęboko zagnieżdżonego różnicowania pól, więc dobrym pomysłem jest spłaszczenie obiektów w wielu polach najwyższego poziomu w dokumencie.