Obiekt użytkownika Firebase reprezentuje konto użytkownika, które zarejestrowało się w aplikacji w Twoim 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 Firebase Authentication, więc możesz mieć kilka odwołań do różnych użytkowników w tym samym kontekście i nadal wywoływać dowolne z ich metod.
Właściwości użytkownika
Użytkownicy Firebase mają ustalony zestaw podstawowych właściwości — unikalny identyfikator, główny adres e-mail, imię i nazwisko oraz adres URL zdjęcia — przechowywanych w bazie danych użytkowników projektu, które mogą być aktualizowane przez użytkownika ( iOS , Android , web ). 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 po raz pierwszy rejestruje się w Twojej aplikacji, dane profilu użytkownika są wypełniane na podstawie 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 federacyjnego 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ę przy użyciu Twojego niestandardowego systemu uwierzytelniania, musisz wyraźnie dodać żądane informacje do profilu użytkownika
Po utworzeniu konta użytkownika można 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 przy użyciu kilku metod: adresu e-mail i hasła, federacyjnych dostawców tożsamości i niestandardowego systemu uwierzytelniania. Możesz powiązać więcej niż jedną metodę logowania z użytkownikiem: na przykład użytkownik może zalogować się na to samo konto, używając adresu e-mail i hasła lub logując się przez Google.
Instancje użytkowników śledzą każdego dostawcę powiązanego z użytkownikiem. Pozwala to na aktualizację właściwości pustego profilu przy użyciu informacji podanych przez dostawcę. Zobacz Zarządzanie użytkownikami ( iOS , Android , web ).
Bieżący użytkownik
Gdy użytkownik rejestruje się lub loguje, 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 powoduje utraty informacji o użytkowniku.
Kiedy użytkownik się wyloguje, instancja Auth przestaje zachowywać odwołanie do obiektu użytkownika i nie zachowuje 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 uzyskiwać dostęp do danych użytkownika i aktualizować je.
Cykl życia użytkownika
Zalecanym sposobem śledzenia bieżącego stanu instancji Auth jest użycie detektorów (zwanych także „obserwatorami” w języku JavaScript). Odbiornik Auth otrzymuje powiadomienie za każdym razem, gdy coś istotnego dzieje się z obiektem Auth. Zobacz Zarządzanie użytkownikami ( iOS , Android , web ).
Odbiornik uwierzytelniania otrzymuje powiadomienie w następujących sytuacjach:
- Obiekt Auth kończy inicjowanie, a użytkownik był już zalogowany z poprzedniej sesji lub został przekierowany z procesu logowania dostawcy tożsamości
- Użytkownik loguje się (bieżący 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 się zdarzyć w następujących warunkach:
- Token dostępu wygasa: jest to typowa sytuacja. Token odświeżania służy do uzyskania nowego prawidłowego zestawu tokenów.
- Użytkownik zmienia swoje hasło: Firebase wydaje nowe tokeny dostępu i odświeżania, a stare tokeny wygasają. Spowoduje to automatyczne wygaśnięcie tokena użytkownika i/lub wylogowanie użytkownika na każdym urządzeniu ze względów bezpieczeństwa.
- Użytkownik ponownie uwierzytelnia się: niektóre działania 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ć go ponownie, uzyskaj od użytkownika nowe poświadczenia i przekaż je do metody ponownego uwierzytelniania obiektu użytkownika.
Samoobsługa użytkownika
Domyślnie Firebase umożliwia użytkownikom rejestrowanie i usuwanie kont bez interwencji administracyjnej. W wielu przypadkach umożliwia to użytkownikom końcowym odkrycie Twojej aplikacji lub usługi i dołączenie (lub poza nią) przy minimalnym tarciu.
Są jednak sytuacje, w których chcesz, aby użytkownicy byli tworzeni ręcznie lub programowo przez administratora przy użyciu pakietu Admin SDK lub konsoli Firebase. W takich przypadkach możesz wyłączyć działania użytkownika na stronie Ustawienia uwierzytelniania Firebase , co uniemożliwi tworzenie i usuwanie kont przez użytkowników końcowych. W przypadku korzystania z wielu dzierżawców konieczne będzie wysłanie żądania HTTP w celu wyłączenia tych funkcji dla poszczególnych dzierżawców.
Jeśli użytkownik końcowy spróbuje utworzyć lub usunąć konto w Twoim systemie, usługa Firebase zwróci kod błędu: auth/admin-restricted-operation dla wywołań Web API lub ERROR_ADMIN_RESTRICTED_OPERATION dla Androida i iOS. Powinieneś z wdziękiem obsłużyć błąd na swoim interfejsie użytkownika, prosząc użytkownika o podjęcie odpowiednich działań dla Twojej usługi.
Tokeny autoryzacji
Podczas uwierzytelniania w Firebase możesz napotkać trzy rodzaje tokenów uwierzytelniających:
| Tokeny identyfikacyjne Firebase | Tworzone przez Firebase, gdy użytkownik loguje się do aplikacji. Te tokeny to podpisane tokeny 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 identyfikacyjnych można zweryfikować , możesz wysłać je do serwera zaplecza, aby zidentyfikować aktualnie zalogowanego użytkownika. |
| Tokeny dostawcy tożsamości | Tworzone 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 uwierzytelniające, z których mogą korzystać usługi Firebase. |
| Niestandardowe tokeny 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 to tokeny JWT podpisane przy użyciu klucza prywatnego konta usługi . Aplikacje używają tych tokenów podobnie jak tokenów zwracanych przez federacyjnych dostawców tożsamości. |
Zweryfikowane adresy e-mail
Firebase uznaje wiadomość e-mail za zweryfikowaną, jeśli spełnia dwa warunki:
- Użytkownik kończy proces weryfikacji Firebase
- Adres e-mail jest weryfikowany przez zaufanego dostawcę tożsamości, w skrócie IdP.
Dostawcy tożsamości, którzy jednorazowo weryfikują adres e-mail, a następnie umożliwiają użytkownikom zmianę adresu 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ą uznawani 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 weryfikowane, ponieważ konta są zawsze weryfikowane i uwierzytelniane wieloskładnikowo)
Niewiarygodni dostawcy:
- Świergot
- GitHub
- Google, Yahoo i Microsoft w przypadku domen niewystawionych przez tego dostawcę tożsamości
- Adres e-mail / hasło bez weryfikacji adresu e-mail
W niektórych sytuacjach Firebase automatycznie łączy konta, gdy użytkownik loguje się u różnych dostawców przy użyciu tego samego adresu e-mail. Może się to jednak zdarzyć tylko wtedy, gdy zostaną spełnione określone kryteria. Aby zrozumieć, dlaczego, rozważmy następującą sytuację: użytkownik loguje się za pomocą Google przy użyciu konta @gmail.com, a złośliwy aktor tworzy konto przy użyciu tego samego adresu @gmail.com, ale loguje się przez Facebooka. Gdyby te dwa konta zostały automatycznie połączone, złośliwy aktor 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ę u niezaufanego dostawcy, a następnie loguje się u innego niezaufanego dostawcy przy użyciu tego samego adresu e-mail (na przykład Facebook, a następnie GitHub). Powoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się u zaufanego dostawcy, a następnie loguje się u niezaufanego dostawcy przy użyciu tego samego adresu e-mail (na przykład Google, a następnie Facebook). Powoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się u niezaufanego dostawcy, a następnie loguje się u zaufanego dostawcy przy użyciu 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 powiązania konta.
- Użytkownik loguje się u zaufanego dostawcy, a następnie loguje się u innego zaufanego dostawcy przy użyciu tego samego adresu e-mail (na przykład Apple, a następnie Google). Obaj dostawcy zostaną połączeni bez błędów.
Możesz ręcznie ustawić adres e-mail jako zweryfikowany za pomocą pakietu Admin SDK, ale zalecamy robienie tego tylko wtedy, gdy wiesz, że użytkownik naprawdę jest właścicielem tego adresu e-mail.