Użytkownicy w projektach Firebase

Przedmiotem użytkownik Firebase reprezentuje konto użytkownika, który zapisał się do aplikacji w projekcie. Aplikacje mają zwykle wielu zarejestrowanych użytkowników, a każda aplikacja w projekcie współdzieli bazę danych użytkowników.

Instancje użytkowników są niezależne od instancji uwierzytelniania Firebase, więc możesz mieć kilka odwołań do różnych użytkowników w tym samym kontekście i nadal wywoływać ich metody.

Właściwości użytkownika

Firebase użytkownicy mają stały zestaw podstawowych właściwości-unikatowy identyfikator, podstawowy adres e-mail, nazwę i adres URL zdjęcia przechowywane w bazie danych użytkownika projektu, które mogą być aktualizowane przez użytkownika ( iOS , Android , WWW ). Nie można bezpośrednio dodawać innych właściwości do obiektu użytkownika; zamiast tego możesz przechowywać dodatkowe właściwości w dowolnych innych usługach przechowywania, takich jak Google Cloud Firestore.

Gdy użytkownik zarejestruje się w Twojej aplikacji po raz pierwszy, dane profilu użytkownika są wypełniane przy użyciu dostępnych informacji:

  • Jeśli użytkownik zarejestrował się przy użyciu adresu e-mail i hasła, wypełniana jest tylko właściwość podstawowego adresu e-mail
  • Jeśli użytkownik zarejestrował się u sfederowanego dostawcy tożsamości, takiego jak Google lub Facebook, informacje o koncie udostępnione przez dostawcę są wykorzystywane do wypełniania profilu użytkownika
  • Jeśli użytkownik zarejestrował się w Twoim niestandardowym systemie uwierzytelniania, musisz wyraźnie dodać żądane informacje do profilu użytkownika

Po utworzeniu konta użytkownika możesz ponownie załadować informacje o użytkowniku, aby uwzględnić wszelkie zmiany, które użytkownik mógł wprowadzić na innym urządzeniu.

Dostawcy logowania

Możesz logować użytkowników do swoich aplikacji, używając kilku metod: adresu e-mail i hasła, dostawców tożsamości federacyjnych i niestandardowego systemu uwierzytelniania. Z użytkownikiem możesz powiązać więcej niż jedną metodę logowania: na przykład użytkownik może zalogować się na to samo konto przy użyciu adresu e-mail i hasła lub przy użyciu funkcji Google Sign-In.

Instancje użytkownika śledzą każdego dostawcę powiązanego z użytkownikiem. Pozwala to aktualizować właściwości pustego profilu przy użyciu informacji podanych przez dostawcę. Zobacz zarządzania użytkownikami ( iOS , Android , WWW ).

Bieżący użytkownik

Gdy użytkownik zarejestruje się lub zaloguje, staje się bieżącym użytkownikiem instancji Auth. Instancja utrzymuje stan użytkownika, dzięki czemu odświeżenie strony (w przeglądarce) lub ponowne uruchomienie aplikacji nie spowoduje utraty informacji o użytkowniku.

Gdy użytkownik się wyloguje, wystąpienie Auth przestaje utrzymywać odwołanie do obiektu użytkownika i nie utrzymuje już swojego stanu; nie ma bieżącego użytkownika. Jednak instancja użytkownika nadal jest w pełni funkcjonalna: jeśli zachowasz do niej odniesienie, nadal możesz uzyskać dostęp i aktualizować dane użytkownika.

Cykl życia użytkownika

Zalecanym sposobem śledzenia bieżącego stanu instancji Auth jest użycie detektorów (zwanych również „obserwatorami” w JavaScript). Odbiornik Auth otrzymuje powiadomienie za każdym razem, gdy coś istotnego dzieje się z obiektem Auth. Zobacz zarządzania użytkownikami ( iOS , Android , WWW ).

Odbiornik Auth otrzymuje powiadomienia w następujących sytuacjach:

  • Inicjowanie obiektu Auth kończy się, a użytkownik był już zalogowany z poprzedniej sesji lub został przekierowany z procesu logowania dostawcy tożsamości
  • Użytkownik loguje się (obecny użytkownik jest ustawiony)
  • Użytkownik wylogowuje się (bieżący użytkownik staje się pusty)
  • Token dostępu bieżącego użytkownika zostanie odświeżony. Ten przypadek może mieć miejsce w następujących warunkach:
    • Token dostępu wygasa: jest to powszechna sytuacja. Token odświeżania służy do uzyskania nowego prawidłowego zestawu tokenów.
    • Użytkownik zmienia hasło: Firebase wydaje nowe tokeny dostępu i odświeżania, a stare traci ważność. To automatycznie wygaśnie token użytkownika i/lub wyloguje użytkownika na każdym urządzeniu ze względów bezpieczeństwa.
    • Użytkownik ponownie uwierzytelnia się: niektóre akcje wymagają, aby poświadczenia użytkownika zostały niedawno wydane; takie działania obejmują usunięcie konta, ustawienie podstawowego adresu e-mail i zmianę hasła. Zamiast wylogowywać użytkownika, a następnie logować się ponownie, pobierz nowe poświadczenia od użytkownika i przekaż nowe poświadczenia do metody ponownego uwierzytelnienia obiektu użytkownika.

Tokeny uwierzytelniania

Podczas uwierzytelniania w Firebase możesz napotkać trzy rodzaje tokenów uwierzytelniania:

Tokeny Firebase ID Tworzone przez Firebase, gdy użytkownik loguje się w aplikacji. Te tokeny są podpisanymi tokenami JWT, które bezpiecznie identyfikują użytkownika w projekcie Firebase. Te tokeny zawierają podstawowe informacje o profilu użytkownika, w tym ciąg identyfikatora użytkownika, który jest unikalny dla projektu Firebase. Ponieważ integralność tokenów ID może zostać zweryfikowana , można wysłać je do serwera backend zidentyfikować aktualnie zalogowanego użytkownika.
Tokeny dostawcy tożsamości Utworzony przez federacyjnych dostawców tożsamości, takich jak Google i Facebook. Te tokeny mogą mieć różne formaty, ale często są tokenami dostępu OAuth 2.0. Aplikacje używają tych tokenów do sprawdzania, czy użytkownicy pomyślnie uwierzytelnili się u dostawcy tożsamości, a następnie konwertują je na dane logowania używane przez usługi Firebase.
Tokeny niestandardowe Firebase Utworzony przez Twój niestandardowy system uwierzytelniania, aby umożliwić użytkownikom logowanie się do aplikacji przy użyciu Twojego systemu uwierzytelniania. Tokeny niestandardowe są JWTs podpisany przy użyciu klucza prywatnego konta usługi jest . Aplikacje używają tych tokenów podobnie jak tokeny zwracane przez federacyjnych dostawców tożsamości.

Zweryfikowane adresy e-mail

Firebase uznaje wiadomość e-mail za zweryfikowaną, jeśli spełnia dwa warunki: 1. Użytkownik kończy proces weryfikacji Firebase 2. Wiadomość e-mail jest weryfikowana przez zaufanego dostawcę tożsamości, w skrócie IdP.

Dostawcy tożsamości, którzy raz weryfikują pocztę e-mail, ale następnie umożliwiają użytkownikom zmianę adresów e-mail bez konieczności ponownej weryfikacji, nie są zaufani. Dostawcy tożsamości, którzy są właścicielami domeny lub zawsze wymagają weryfikacji, są uważani za zaufanych.

Zaufani dostawcy:

  • Google (dla adresów @gmail.com)
  • Yahoo (dla adresów @yahoo.com)
  • Microsoft (dla adresów @outlook.com i @hotmail.com)
  • Apple (zawsze zweryfikowane, ponieważ konta są zawsze weryfikowane i uwierzytelniane wieloskładnikowo)

Niezaufani dostawcy:

  • Facebook
  • Świergot
  • GitHub
  • Google, Yahoo i Microsoft w przypadku domen nie wydanych przez tego dostawcę tożsamości
  • E-mail/hasło bez weryfikacji adresu e-mail

W niektórych sytuacjach Firebase automatycznie połączy konta, gdy użytkownik zaloguje się u różnych dostawców przy użyciu tego samego adresu e-mail. Może się to jednak zdarzyć tylko wtedy, gdy spełnione są określone kryteria. Aby zrozumieć dlaczego, rozważ następującą sytuację: użytkownik loguje się za pomocą Google przy użyciu konta @gmail.com, a złośliwy gracz tworzy konto przy użyciu tego samego adresu @gmail.com, ale loguje się przez Facebook. Gdyby te dwa konta zostały automatycznie połączone, złośliwy gracz uzyskałby dostęp do konta użytkownika.

Poniższe przypadki opisują, kiedy automatycznie łączymy konta i kiedy zgłaszamy błąd wymagający działania użytkownika lub programisty:

  • Użytkownik loguje się za pomocą niezaufanego dostawcy, a następnie loguje się za pomocą innego niezaufanego dostawcy za pomocą tego samego adresu e-mail (na przykład Facebook, a następnie GitHub). Spowoduje to zgłoszenie błędu wymagającego połączenia kont.
  • Użytkownik loguje się za pomocą zaufanego dostawcy, a następnie loguje się za pomocą niezaufanego dostawcy za pomocą tego samego adresu e-mail (na przykład Google, a następnie Facebook). Spowoduje to zgłoszenie błędu wymagającego połączenia kont.
  • Użytkownik loguje się za pomocą niezaufanego dostawcy, a następnie loguje się za pomocą zaufanego dostawcy za pomocą tego samego adresu e-mail (na przykład Facebook, a następnie Google). Zaufany dostawca zastępuje niezaufanego dostawcę. Jeśli użytkownik spróbuje ponownie zalogować się za pomocą Facebooka, spowoduje to błąd wymagający połączenia konta.
  • Użytkownik loguje się za pomocą zaufanego dostawcy, a następnie loguje się za pomocą innego zaufanego dostawcy za pomocą tego samego adresu e-mail (na przykład Apple, a następnie Google). Obaj dostawcy zostaną powiązani bez błędów.

Możesz ręcznie ustawić e-mail jako zweryfikowany za pomocą pakietu Admin SDK, ale zalecamy to zrobić tylko wtedy, gdy wiesz, że użytkownik naprawdę jest właścicielem tego e-maila.