Trwałość stanu uwierzytelniania

Możesz określić sposób utrzymywania stanu uwierzytelnienia podczas korzystania z pakietu SDK Firebase JS. Obejmuje to możliwość określenia, czy zalogowany użytkownik powinien być utrzymywany na czas nieokreślony aż do jawnego wylogowania, wyczyszczenia po zamknięciu okna lub wyczyszczenia przy ponownym załadowaniu strony.

W przypadku aplikacji internetowej domyślnym zachowaniem jest utrzymywanie sesji użytkownika nawet po zamknięciu przez niego przeglądarki. Jest to wygodne, ponieważ użytkownik nie musi się ciągle logować za każdym razem, gdy odwiedza stronę internetową na tym samym urządzeniu. Może to wymagać od użytkownika konieczności ponownego wprowadzenia hasła, wysłania SMS-a weryfikacyjnego itp., co może znacznie utrudnić użytkownikowi korzystanie z witryny.

Są jednak przypadki, w których takie zachowanie może nie być idealne:

  • Aplikacje zawierające wrażliwe dane mogą chcieć wyczyścić stan po zamknięciu okna lub karty. Jest to istotne w przypadku, gdy 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 bibliotecznym.
  • Aplikacja na współdzielonym urządzeniu, do której może mieć dostęp wielu użytkowników. Programista nie jest w stanie określić, w jaki sposób uzyskiwany jest dostęp do tej aplikacji i może chcieć zapewnić użytkownikowi możliwość wyboru, czy sesja ma być kontynuowana, czy nie. Można to zrobić, dodając opcję „Zapamiętaj mnie” podczas logowania.
  • W niektórych sytuacjach programista może nie chcieć utrzymywać anonimowego użytkownika, dopóki nie zostanie on uaktualniony do konta nieanonimowego (federalnego, z hasłem, telefonem itp.).
  • Deweloper może zezwolić różnym użytkownikom na logowanie się do aplikacji na różnych kartach. Domyślnym zachowaniem jest utrzymywanie stanu na różnych kartach dla tego samego źródła.

Jak wspomniano powyżej, istnieje wiele sytuacji, w których może zaistnieć potrzeba zastąpienia domyślnej trwałej trwałości.

Obsługiwane typy trwałości stanu uwierzytelniania

Możesz wybrać jeden z trzech typów trwałości stanu uwierzytelniania w określonej instancji Firebase Auth w zależności od aplikacji lub wymagań użytkownika.

Wyliczenie Wartość Opis
firebase.auth.Auth.Persistence.LOCAL 'lokalny' Wskazuje, że stan będzie trwały nawet po zamknięciu okna przeglądarki lub zniszczeniu działania w React Native. Aby wyczyścić ten stan, wymagane jest wyraźne wylogowanie. Pamiętaj, że sesje internetowe Firebase Auth pochodzą z jednego hosta i będą utrwalane tylko dla jednej domeny.
firebase.auth.Auth.Persistence.SESSION 'sesja' Wskazuje, że stan będzie się utrzymywał tylko w bieżącej sesji lub karcie i zostanie wyczyszczony po zamknięciu karty lub okna, w którym uwierzytelniono użytkownika. Dotyczy tylko aplikacji internetowych.
firebase.auth.Auth.Persistence.NONE 'nic' Wskazuje, że stan będzie przechowywany tylko w pamięci i zostanie wyczyszczony po odświeżeniu okna lub działania.

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 modular API

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;
  });

Web namespaced API

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;
  });

Spowoduje to zmianę typu trwałości w określonej instancji Auth dla aktualnie zapisanej sesji Auth i zastosowanie tego typu trwałości do przyszłych żądań logowania, w tym logowania z żądaniami przekierowania. Spowoduje to zwrócenie obietnicy, która zostanie rozpatrzona, gdy stan zakończy kopiowanie 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ślnym ustawieniem dla przeglądarki internetowej i aplikacji React Native jest local (pod warunkiem, że przeglądarka obsługuje ten mechanizm przechowywania, np. włączone są pliki cookie/dane innych firm), natomiast w przypadku aplikacji zaplecza Node.js nie jest to none .

Przegląd zachowań związanych z trwałością

Przy określaniu aktualnego stanu trwałości stosowane będą następujące kryteria.

  • Początkowo zestaw SDK sprawdzi, czy istnieje uwierzytelniony użytkownik. O ile nie zostanie wywołana setPersistence , bieżący typ trwałości tego użytkownika zostanie zastosowany przy przyszłych próbach logowania. Jeśli zatem użytkownik pozostawał w session na poprzedniej stronie internetowej i odwiedzono nową stronę, ponowne zalogowanie się na innego użytkownika spowoduje, że stan tego użytkownika zostanie również zapisany z zachowaniem trwałości session .
  • Jeśli żaden użytkownik nie jest zalogowany i nie określono trwałości, zastosowane zostanie ustawienie domyślne ( local w aplikacji przeglądarki).
  • Jeśli żaden użytkownik nie jest zalogowany i ustawiony jest nowy typ trwałości, wszelkie przyszłe próby logowania będą korzystać z tego typu trwałości.
  • Jeśli użytkownik jest zalogowany i typ trwałości zostanie zmodyfikowany, istniejący zalogowany użytkownik zmieni trwałość na nową. Wszystkie przyszłe próby logowania będą korzystać z tej nowej trwałości.
  • Po wywołaniu metody SignInWithRedirect bieżący typ trwałości zostaje zachowany i zastosowany na końcu przepływu OAuth do nowo zalogowanego użytkownika, nawet jeśli trwałość miała wartość none . Jeśli trwałość jest wyraźnie określona na tej stronie, zastąpi ona trwałość stanu uwierzytelnienia z poprzedniej strony, która rozpoczęła przepływ 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;
      });

    Web namespaced API

    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;
      });

Oczekiwane zachowanie na kartach przeglądarki

Poniższe oczekiwane zachowanie będzie miało zastosowanie, gdy na różnych kartach używane są różne typy trwałości. Wymagane jest, aby w żadnym momencie nie było jednocześnie wielu typów zapisanych stanów (np. stan autoryzacji zapisany w session i local typach pamięci):

  • Użytkownicy mogą logować się przy użyciu session lub none trwałości z różnymi użytkownikami na wielu kartach. Żadna karta nie może zobaczyć stanu drugiej karty.
  • Każda próba zalogowania się przy użyciu trwałości local zostanie wykryta i zsynchronizowana na wszystkich kartach. Jeśli użytkownik był wcześniej zalogowany na określonej karcie przy użyciu session lub none trwałości, stan ten zostanie wyczyszczony.
  • Jeśli użytkownik był wcześniej zalogowany przy użyciu trwałości local z otwartymi wieloma kartami, a następnie przełączył się na none lub trwałość session na jednej karcie, stan tej karty zostanie zmodyfikowany, gdy użytkownik będzie utrzymywany w session lub na none , a na wszystkich pozostałych kartach użytkownik zostanie wylogowany.