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.



Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow