Obiekt user w usłudze Firebase reprezentuje konto użytkownika, które podpisało do aplikacji na Twoim w projektach AI. Aplikacje mają zwykle wielu zarejestrowanych użytkowników, a każda aplikacja projekt współużytkuje bazę danych użytkownika.
Instancje użytkownika są niezależne od instancji Firebase Authentication, więc możesz mieć wiele odwołań do różnych użytkowników w tym samym kontekście i nadal wywołuje wszystkie ich metod.
Właściwości użytkownika
Firebase użytkowników ma stały zestaw właściwości podstawowych – unikalną dokumentu tożsamości, podstawowego adresu e-mail, imienia i nazwiska oraz adresu URL zdjęcia – przechowywanych w baza danych użytkownika projektu, którą użytkownik może aktualizować (na urządzeniach z systemem iOS, Android sieć). Nie możesz dodać innych właściwości bezpośrednio do obiektu użytkownika. zamiast tego możesz przechowywać dodatkowe usługi w innych usługach pamięci masowej, takich jak Google Cloud. Firestore.
Gdy użytkownik po raz pierwszy zarejestruje się w Twojej aplikacji, jego dane profilowe zostaną wypełnione przy użyciu dostępnych informacji:
- Jeśli użytkownik zarejestrował się za pomocą adresu e-mail i hasła, tylko podstawowy adres e-mail właściwość adresu e-mail jest wypełniona
- Jeśli użytkownik zarejestrował się u dostawcy tożsamości sfederowanego, takiego jak Google lub Facebook, informacje o koncie udostępniane przez dostawcę są wykorzystywane do wypełnij profil użytkownika
- Jeśli użytkownik zarejestrował się za pomocą niestandardowego systemu uwierzytelniania, musisz samodzielnie dodać wybrane informacje dla profilu użytkownika
Po utworzeniu konta użytkownika możesz ponownie załadować informacje o nim, aby uwzględnianie zmian, które użytkownik mógł wprowadzić na innym urządzeniu.
Dostawcy logowania
Możesz logować użytkowników w aplikacjach na kilka sposobów: adres e-mail i hasło, dostawców tożsamości sfederowanej oraz niestandardowe uwierzytelnianie systemu. 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; za pomocą Logowania przez Google.
Instancje użytkownika śledzą każdego dostawcę połączonego z użytkownikiem. Dzięki temu możesz: , aby zaktualizować właściwości pustego profilu przy użyciu informacji podanych przez dostawcę. Zobacz Zarządzanie użytkownikami (iOS, Android sieć).
Bieżący użytkownik
Gdy użytkownik zarejestruje się lub zaloguje, staje się aktualnym użytkownikiem Instancja uwierzytelniania. Instancja utrwala stan użytkownika, więc odświeżenie pliku (w przeglądarce) lub ponowne uruchomienie aplikacji nie powoduje utraty danych i informacjami o nich.
Gdy użytkownik się wyloguje, instancja uwierzytelniania przestaje zapisywać odniesienie do użytkownika obiektu i nie utrzymuje już swojego stanu; nie ma bieżącego użytkownika. Jednak instancja użytkownika jest w pełni funkcjonalna: jeśli zachowasz odniesienie do nadal możesz uzyskiwać dostęp do jego danych i je aktualizować.
Cykl życia użytkownika
Zalecanym sposobem śledzenia bieżącego stanu instancji Auth jest użycie detektory (w JavaScripcie nazywane też „obserwatorami”). Detektor Auth otrzymuje powiadomienie za każdym razem, gdy z obiektem Auth stanie się coś istotnego. Zobacz zarządzanie Użytkownicy (iOS, Android sieć).
Detektor uwierzytelniania otrzymuje powiadomienia w tych sytuacjach:
- Rozpocznie się inicjowanie obiektu Auth, a użytkownik był już zalogowany w poprzedniej sesji lub nastąpiło przekierowanie z logowania dostawcy tożsamości przepływ
- Użytkownik loguje się (ustawiony został bieżący użytkownik)
- Użytkownik wyloguje się (obecny użytkownik otrzyma wartość null)
- Token dostępu bieżącego użytkownika zostanie odświeżony. Może się tak zdarzyć w
następujące warunki:
- Token dostępu wygasa – to typowa sytuacja. Token odświeżania to: użyte do uzyskania nowego prawidłowego zestawu tokenów.
- Użytkownik zmienił hasło. Firebase przyzna nowy dostęp i odśwież tokeny, a stare tokeny wygasły. Automatycznie wygasa token użytkownika i/lub zostanie wylogowany na każdym urządzeniu, zabezpieczeń.
- Użytkownik ponownie uwierzytelnia się: niektóre działania wymagają dane logowania zostały wydane; takie działania obejmują usunięcie konta, ustawiając podstawowy adres e-mail i zmieniając hasło. Zamiast wylogowanie użytkownika i zalogowanie go ponownie, pobranie nowego konta dane logowania użytkownika i przekazać je do uwierzytelniania obiektu użytkownika.
Samoobsługa użytkownika
Domyślnie Firebase umożliwia użytkownikom rejestrowanie się i usuwanie kont bez interwencji administracyjnej. W wielu okolicznościach pozwala to użytkownikom do odkrywania Twojej aplikacji lub usługi i wprowadzenia (lub rezygnacji) w jej ramach jak najmniej tarć.
Istnieją jednak sytuacje, w których użytkownicy powinni być konfigurowani ręcznie utworzone automatycznie przez administratora przy użyciu pakietu Admin SDK lub Konsola Firebase. W takich przypadkach możesz wyłączyć działania użytkowników w Ustawieniach Firebase Authentication , która uniemożliwia użytkownikom tworzenie i usuwanie kont. Jeśli korzystasz ze środowiska wielu najemców, musisz wysłać żądanie HTTP aby wyłączyć te funkcje dla najemcy.
Jeśli użytkownik spróbuje utworzyć lub usunąć konto w systemie,
Usługa Firebase zwróci kod błędu:
auth/admin-restricted-operation w przypadku wywołań interfejsu Web API lub ERROR_ADMIN_RESTRICTED_OPERATION w przypadku Androida i iOS. Należy z gracją
naprawić błąd w interfejsie, prosząc użytkownika o wybranie
dla Twojej usługi.
Tokeny uwierzytelniania
Podczas uwierzytelniania za pomocą Firebase dostępne są trzy rodzaje tokenów uwierzytelniania, które możesz napotkać:
| Firebase tokenów tożsamości | Utworzone przez Firebase, gdy użytkownik zaloguje się w aplikacji. Te to podpisane tokeny JWT, które bezpiecznie identyfikują użytkownika w Firebase projekt. Te tokeny zawierają podstawowe informacje profilowe łącznie z ciągiem identyfikatora użytkownika, który jest unikalny dla parametru Firebase projekt. Ponieważ integralności tokenów tożsamości można zweryfikować, możesz wysłać je do serwera backendu, aby zidentyfikować aktualnie zalogowanego użytkownika. |
| Tokeny dostawcy tożsamości | Tworzone przez dostawców tożsamości sfederowanych, takich jak Google czy Facebook. Tokeny te mogą mieć różne formaty, ale często są to tokeny dostępu OAuth 2.0 tokeny. Aplikacje używają tych tokenów, aby weryfikować, czy użytkownicy uwierzytelnionych przy użyciu dostawcy tożsamości, a następnie przekonwertować je na dane logowania do wykorzystania przez usługi Firebase. |
| Firebase tokenów niestandardowych | utworzone przez Twój niestandardowy system uwierzytelniania, aby umożliwić użytkownikom logowanie się w aplikacji. za pomocą systemu uwierzytelniania. Tokeny niestandardowe to tokeny JWT podpisywane za pomocą klucza prywatnego konta usługi. Aplikacje używają tych tokenów w podobny sposób jak tokeny zwrócone z dostawców tożsamości sfederowanej. |
Zweryfikowane adresy e-mail
Firebase uznaje adres e-mail za zweryfikowany, jeśli spełnia 2 warunki:
- Użytkownik przechodzi proces weryfikacji Firebase.
- Adres e-mail jest weryfikowany przez zaufanego dostawcę tożsamości (w skrócie „dostawcę tożsamości”).
Dostawcy tożsamości, którzy raz weryfikują adres e-mail, a następnie zezwalają użytkownikom na zmianę adresu e-mail bez konieczności ponownej weryfikacji, nie są zaufanymi. Dostawcy tożsamości, którzy są właścicielami domeny lub zawsze wymagają weryfikacji, są uważani za zaufanych.
Zaufani usługodawcy:
- 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 zweryfikowane i uwierzytelnianie wielopoziomowe)
Niezaufani dostawcy:
- GitHub
- Google, Yahoo i Microsoft w przypadku domen, które nie zostały wydane przez tego Dostawcę tożsamości
- Adres e-mail / hasło bez potwierdzania adresu e-mail
W niektórych sytuacjach Firebase będzie automatycznie łączyć konta, gdy użytkownik zaloguje się za pomocą tego samego adresu e-mail u innych dostawców usług. Może się to jednak zdarzyć tylko wtedy, gdy zostaną spełnione określone kryteria. Aby poznać przyczynę, rozpatrzmy następującą sytuację: użytkownik loguje się przez Google za pomocą konta @gmail.com, a haker tworzy konto przy użyciu tego samego adresu w domenie @gmail.com, ale loguje się przez Facebooka. Gdyby oba konta zostały automatycznie połączone, osoba przeprowadzająca atak mogłaby uzyskać dostęp do konta użytkownika.
W tych przypadkach opisujemy, kiedy automatycznie łączymy konta i kiedy pojawia się błąd wymagający działania użytkownika lub dewelopera:
- Użytkownik loguje się przez niezaufanego dostawcę, a potem korzysta z tego samego adresu e-mail innego niezaufanego dostawcy (np. Facebook, a potem GitHub). Powoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się przez zaufanego dostawcę, a potem loguje się za pomocą tego samego adresu e-mail (np. Google i Facebook). Powoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się przez niezaufanego dostawcę, a następnie korzysta z usług zaufanego dostawcy, używając tego samego adresu e-mail (np. Facebook, a potem Google). Zaufany dostawca zastępuje niezaufanego dostawcę. Jeśli użytkownik spróbuje ponownie zalogować się przez Facebooka, spowoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się przez zaufanego dostawcę, a następnie za pomocą tego samego adresu e-mail korzysta z konta innego zaufanego dostawcy (np. 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 wykonanie tej czynności tylko wtedy, gdy masz pewność, że użytkownik rzeczywiście jest właścicielem tego adresu.