Trwałość stanu uwierzytelniania

Korzystając z pakietu SDK JavaScript Firebase, możesz określić sposób zachowania stanu uwierzytelniania. Obejmuje to możliwość określenia, czy zalogowany użytkownik ma być przechowywany przez nieokreślony czas do momentu wylogowania, czy ma być usuwany po zamknięciu okna lub po ponownym załadowaniu strony.

W przypadku aplikacji internetowej domyślne zachowanie polega na przechowywaniu sesji użytkownika nawet po zamknięciu przez niego przeglądarki. Jest to wygodne, ponieważ użytkownik nie musi logować się za każdym razem, gdy otwiera stronę internetową na tym samym urządzeniu. Może to wymagać ponownego wpisania hasła, wysłania SMS-a z weryfikacją itp., co może znacznie utrudnić korzystanie z aplikacji.

Są jednak sytuacje, w których takie działanie może nie być idealne:

• Aplikacje zawierające dane wrażliwe mogą wyczyścić stan po zamknięciu okna lub karty. Jest to ważne, jeśli użytkownik zapomni się wylogować.
• Aplikacje używane na urządzeniu współdzielonym przez wielu użytkowników. Typowym przykładem jest aplikacja działająca na komputerze w bibliotece.
• Aplikacja na współdzielonym urządzeniu, do której może mieć dostęp wielu użytkowników. Deweloperzy nie mogą określić, w jaki sposób użytkownik uzyskuje dostęp do aplikacji, i mogą chcieć dać mu możliwość wyboru, czy chce zachować sesję. Może to być możliwe dzięki dodaniu opcji „Zapamiętaj mnie” podczas logowania.
• W niektórych przypadkach deweloper może nie przechowywać danych anonimowego użytkownika, dopóki nie zostanie on przeniesiony na konto nieanonimowe (federowane, z hasłem, z numeru telefonu itp.).
• Deweloperzy mogą chcieć zezwolić na logowanie się różnych użytkowników w aplikacji na różnych kartach. Domyślnie stan jest zachowywany na kartach w ramach tej samej domeny.

Jak już wspomnieliśmy, w wielu sytuacjach może być konieczne zastąpienie domyślnej trwałej trwałości.

Uwaga: nie myl trwałości stanu uwierzytelniania z trwałością danych w Firestore w trybie offline. Trwałość stanu uwierzytelniania określa, jak sesja użytkownika jest przechowywana na urządzeniu. Natomiast Firestore enablePersistence umożliwia buforowanie danych Cloud Firestore, gdy urządzenie jest offline.

Obsługiwane typy trwałości stanu autoryzacji

W zależności od wymagań aplikacji lub użytkownika możesz wybrać jeden z 3 typów trwałości stanu uwierzytelniania w określonym wystąpieniu Firebase Auth.

Typ wyliczeniowy	Wartość	Opis
firebase.auth.Auth.Persistence.LOCAL	'local'	Wskazuje, że stan będzie zachowany nawet wtedy, gdy okno przeglądarki zostanie zamknięte lub aktywność zostanie zniszczona w React Native. Aby usunąć ten stan, musisz się wylogować. Pamiętaj, że sesje internetowe Firebase Auth mają pojedynczy host i są przechowywane tylko w jednej domenie.
firebase.auth.Auth.Persistence.SESSION	„session”	Wskazuje, że stan będzie zachowany tylko w bieżącej sesji lub karcie i zostanie wyczyszczony po zamknięciu karty lub okna, w których użytkownik się uwierzytelnił. Dotyczy to tylko aplikacji internetowych.
firebase.auth.Auth.Persistence.NONE	'none'	Wskazuje, że stan będzie przechowywany tylko w pamięci i wyczyści się, gdy okno lub aktywność zostaną odświeżone.

Modyfikowanie trwałości stanu uwierzytelniania

Możesz określić lub zmodyfikować istniejący typ trwałości, wywołując metodę firebase.auth().setPersistence:

Web

import { getAuth, setPersistence, signInWithEmailAndPassword, browserSessionPersistence } from "firebase/auth";

const auth = getAuth();
setPersistence(auth, browserSessionPersistence)
  .then(() => {
    // Existing and future Auth states are now persisted in the current
    // session only. Closing the window would clear any existing state even
    // if a user forgets to sign out.
    // ...
    // New sign-in will be persisted with session persistence.
    return signInWithEmailAndPassword(auth, email, password);
  })
  .catch((error) => {
    // Handle Errors here.
    const errorCode = error.code;
    const errorMessage = error.message;
  });
auth_set_persistence_session.js

Web

firebase.auth().setPersistence(firebase.auth.Auth.Persistence.SESSION)
  .then(() => {
    // Existing and future Auth states are now persisted in the current
    // session only. Closing the window would clear any existing state even
    // if a user forgets to sign out.
    // ...
    // New sign-in will be persisted with session persistence.
    return firebase.auth().signInWithEmailAndPassword(email, password);
  })
  .catch((error) => {
    // Handle Errors here.
    var errorCode = error.code;
    var errorMessage = error.message;
  });
auth-state-persistence.js

Spowoduje to zmianę typu trwałości w przypadku określonej instancji Auth w przypadku bieżącej zapisanej sesji Auth i zastosuje ten typ trwałości do przyszłych żądań logowania, w tym żądań logowania z przekierowaniem. Zwróci to obietnicę, która zostanie spełniona, gdy stan skopiuje się z jednego typu pamięci do drugiego. Wywołanie metody logowania po zmianie trwałości spowoduje oczekiwanie na zakończenie tej zmiany trwałości przed zastosowaniem jej w nowym stanie uwierzytelniania.

Domyślnie w przypadku przeglądarek internetowych i aplikacji natywnych w ramach React Native jest to local (o ile przeglądarka obsługuje ten mechanizm przechowywania, np. W przypadku aplikacji serwera Node.js jest to none.

Omówienie zachowania trwałego

Podczas określania bieżącego stanu trwałości będą stosowane te kryteria.

• Najpierw SDK sprawdza, czy istnieje uwierzytelniony użytkownik. Jeśli nie zostanie wywołana funkcja setPersistence, w przyszłych próbach logowania będzie stosowany bieżący typ trwałości tego użytkownika. Jeśli więc stan użytkownika został zachowany w session na poprzedniej stronie internetowej, a użytkownik odwiedził nową stronę, zalogowanie się ponownie z użyciem innego konta spowoduje, że stan tego użytkownika również zostanie zachowany w session.
• Jeśli żaden użytkownik nie jest zalogowany i nie jest określona trwałość, zostanie zastosowane ustawienie domyślne (local w aplikacji w przeglądarce).
• Jeśli żaden użytkownik nie jest zalogowany, a nowy typ trwałości jest ustawiony, wszystkie przyszłe próby logowania będą używać tego typu trwałości.
• Jeśli użytkownik jest zalogowany i zmodyfikujesz typ trwałości, ten użytkownik zmieni trwałość na nową. Wszystkie przyszłe próby logowania będą używać tej nowej trwałości.

• Gdy wywoływana jest metoda signInWithRedirect, zachowany zostaje bieżący typ trwałości i zastosowany na końcu procesu OAuth do nowo zalogowanego użytkownika, nawet jeśli trwałość wynosi none. Jeśli trwałość jest wyraźnie określona na tej stronie, zastąpi trwałość stanu autoryzacji z poprzedniej strony, która rozpoczęła przekierowanie.

  Web

  import { getAuth, setPersistence, signInWithRedirect, inMemoryPersistence, GoogleAuthProvider } from "firebase/auth";
  
  const auth = getAuth();
  setPersistence(auth, inMemoryPersistence)
    .then(() => {
      const provider = new GoogleAuthProvider();
      // In memory persistence will be applied to the signed in Google user
      // even though the persistence was set to 'none' and a page redirect
      // occurred.
      return signInWithRedirect(auth, provider);
    })
    .catch((error) => {
      // Handle Errors here.
      const errorCode = error.code;
      const errorMessage = error.message;
    });
  auth_set_persistence_none.js

  Web

  firebase.auth().setPersistence(firebase.auth.Auth.Persistence.NONE)
    .then(() => {
      var provider = new firebase.auth.GoogleAuthProvider();
      // In memory persistence will be applied to the signed in Google user
      // even though the persistence was set to 'none' and a page redirect
      // occurred.
      return firebase.auth().signInWithRedirect(provider);
    })
    .catch((error) => {
      // Handle Errors here.
      var errorCode = error.code;
      var errorMessage = error.message;
    });
  auth-state-persistence.js

Oczekiwane działanie na kartach przeglądarki

Gdy na różnych kartach używasz różnych typów trwałości, występuje następujące oczekiwane działanie: Wymaganie polega na tym, że w żadnym momencie nie może być zapisanych jednocześnie stanów różnych typów (np. stanu autoryzacji zapisanego w typach pamięci session i local):

• Użytkownicy mogą logować się za pomocą session lub none z różnymi użytkownikami na różnych kartach. Każda karta nie może widzieć stanu innej karty.
• Każda próba zalogowania się za pomocą local zostanie wykryta i zsynchronizowana na wszystkich kartach. Jeśli użytkownik był wcześniej zalogowany na konkretnej karcie przy użyciu trwałości session lub none, ten stan zostanie wyczyszczony.
• Jeśli użytkownik był wcześniej zalogowany z wykorzystaniem trwałości local z wieloma otwartymi kartami, a potem przełączył się na trwałość none lub session na jednej karcie, stan tej karty zostanie zmieniony na trwałość session lub none, a na wszystkich pozostałych kartach użytkownik zostanie wylogowany.