Trwałość stanu uwierzytelniania

Za pomocą pakietu SDK Firebase JS możesz określić, jak ma być zachowany stan uwierzytelniania. Obejmuje to możliwość określenia, czy zalogowany użytkownik ma być bezterminowo zachowywany do momentu jednoznacznego wylogowania, wyczyszczenia po zamknięciu okna lub wyczyszczenia przy ponownym załadowaniu strony.

W przypadku aplikacji internetowej domyślnie sesja użytkownika zostaje zachowana nawet po zamknięciu przeglądarki przez użytkownika. Jest to wygodne, ponieważ użytkownik nie musi logować się za każdym razem, gdy odwiedza stronę internetową na tym samym urządzeniu. W takiej sytuacji użytkownik będzie musiał ponownie wpisać hasło, wysłać SMS-a weryfikacyjnego itp., co utrudni użytkownikom korzystanie z internetu.

W niektórych przypadkach takie zachowanie może jednak nie być idealne:

• Aplikacje z danymi wrażliwymi mogą chcieć wyczyścić stan, gdy okno lub karta są zamknięte. Jest to ważne, jeśli użytkownik zapomni się wylogować.
• Aplikacje używane na urządzeniu współużytkowanym przez wielu użytkowników. Typowym przykładem jest aplikacja uruchomiona na komputerze w bibliotece.
• Aplikacja na współdzielonym urządzeniu, z którego może korzystać wielu użytkowników. Deweloper nie jest w stanie określić, w jaki sposób uzyskuje się dostęp do aplikacji, dlatego powinien dać użytkownikowi możliwość określenia, czy sesja ma zostać zachowana, czy nie. Można to zrobić, dodając opcję „Zapamiętaj mnie” podczas logowania.
• W niektórych sytuacjach deweloper może zechcieć nie pozostawać anonimowego użytkownika, dopóki nie zostanie on przełączony na nieanonimowe konto (sfederowane, z hasłem, numerem telefonu itp.).
• Programista może zezwolić różnym użytkownikom na logowanie się w aplikacji na różnych kartach. Domyślnym działaniem jest zachowywanie stanu na różnych kartach tego samego źródła.

Jak wspomnieliśmy powyżej, jest wiele sytuacji, w których domyślna trwała trwałość może wymagać zmiany.

Obsługiwane typy trwałości stanu uwierzytelniania

W zależności od wymagań aplikacji lub użytkownika możesz wybrać 1 z 3 typów zachowywania stanu uwierzytelniania w konkretnej instancji uwierzytelniania Firebase.

Modyfikowanie trwałości stanu uwierzytelniania

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

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

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 określonej instancji uwierzytelniania dla obecnie zapisanej sesji uwierzytelniania i stosowanie tego typu trwałości w przypadku przyszłych żądań logowania, w tym logowania z żądaniami przekierowania. Spowoduje to zwrócenie obietnicy, która zostanie zrealizowana, gdy stan zakończy kopiowanie z jednego typu pamięci masowej do drugiego. Wywołanie metody logowania po zmianie trwałości będzie czekać na zakończenie tej zmiany, zanim zostanie zastosowana do nowego stanu uwierzytelniania.

Domyślne ustawienie przeglądarki i aplikacji natywnych React to local (pod warunkiem, że przeglądarka obsługuje ten mechanizm przechowywania, np. pliki cookie/dane innych firm są włączone), a w przypadku aplikacji backendu Node.js jest to none.

Omówienie zachowania trwałości

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

• Na początek pakiet SDK sprawdzi, czy istnieje uwierzytelniony użytkownik. Jeśli nie zostanie wywołana zasada setPersistence, bieżący typ trwałości tego użytkownika będzie stosowany do przyszłych prób logowania. Jeśli więc użytkownik był aktywny na koncie session na poprzedniej stronie internetowej i odwiedzono nową stronę, ponowne zalogowanie się przez innego użytkownika spowoduje, że stan tego użytkownika również zostanie zapisany z trwałością session.
• Jeśli żaden użytkownik nie jest zalogowany, a trwałość nie jest określona, zastosowane zostanie ustawienie domyślne (local w przypadku przeglądarki).
• Jeśli żaden użytkownik nie jest zalogowany i ustawiono nowy typ trwałości, każda w przyszłości próba logowania będzie z niego korzystać.
• Jeśli użytkownik jest zalogowany, a typ trwałości zostanie zmieniony, istniejący zalogowany użytkownik zmieni trwałość na nowego. Wszystkie kolejne próby logowania będą z niego korzystać.

• Po wywołaniu metody signInWithRedirect bieżący typ trwałości jest zachowywany i stosowany na końcu procesu OAuth do nowo zalogowanego użytkownika, nawet jeśli trwałość wynosi none. Jeśli trwałość jest bezpośrednio określona na tej stronie, zastąpi ona zachowanie zapisanego stanu uwierzytelniania z poprzedniej strony, która rozpoczęła proces przekierowania.

  Web Modular API

  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

  Interfejs API internetowej przestrzeni nazw

  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 różnych kartach przeglądarki

Poniższe oczekiwane działanie będzie stosowane w przypadku użycia różnych typów trwałości na różnych kartach. Wymagamy, aby w żadnym momencie nie można było w danym momencie mieć kilku typów zapisanych stanów (np. stanu uwierzytelniania zapisanego w typach pamięci session i local):

• Użytkownicy mogą logować się za pomocą funkcji session lub none przy pomocy różnych użytkowników na wielu kartach. Żadna z kart nie widzi stanu drugiej.
• Każda próba zalogowania się z wykorzystaniem trwałości local zostanie wykryta i zsynchronizowana na wszystkich kartach. Jeśli użytkownik był wcześniej zalogowany na określonej karcie za pomocą trwałości session lub none, stan ten zostanie wyczyszczony.
• Jeśli użytkownik był wcześniej zalogowany za pomocą trwałości local z otwartymi wieloma kartami, a potem w jednej karcie przełączył się na trwałość none lub session, stan tej karty zostanie zmodyfikowany, a użytkownik zostanie wylogowany w session lub none i na wszystkich pozostałych kartach.