Persistenza dello stato di autenticazione

Puoi specificare in che modo persiste lo stato di autenticazione quando utilizzi Firebase JS SDK. Ciò include la possibilità di specificare se un utente connesso deve essere persistente a tempo indeterminato fino alla disconnessione esplicita, cancellato quando la finestra viene chiusa o cancellato al ricaricamento della pagina.

Per un'applicazione Web, il comportamento predefinito consiste nel rendere persistente la sessione di un utente anche dopo che l'utente ha chiuso il browser. Ciò è comodo poiché all'utente non è richiesto di accedere continuamente ogni volta che la pagina Web viene visitata sullo stesso dispositivo. Ciò potrebbe richiedere all'utente di reinserire la propria password, inviare un SMS di verifica, ecc., Il che potrebbe aggiungere molti attriti all'esperienza dell'utente.

Tuttavia, ci sono casi in cui questo comportamento potrebbe non essere ideale:

• Le applicazioni con dati sensibili potrebbero voler cancellare lo stato quando la finestra o la scheda viene chiusa. Questo è importante nel caso in cui l'utente dimentichi di disconnettersi.
• Applicazioni utilizzate su un dispositivo condiviso da più utenti. Un esempio comune qui è un'app in esecuzione su un computer della biblioteca.
• Un'applicazione su un dispositivo condiviso a cui possono accedere più utenti. Lo sviluppatore non è in grado di indicare come si accede all'applicazione e potrebbe voler fornire a un utente la possibilità di scegliere se mantenere o meno la propria sessione. Questo può essere fatto aggiungendo l'opzione "Ricordami" durante l'accesso.
• In alcune situazioni, uno sviluppatore potrebbe voler non rendere persistente un utente anonimo finché tale utente non viene aggiornato a un account non anonimo (federato, password, telefono, ecc.).
• Uno sviluppatore potrebbe voler consentire a diversi utenti di accedere a un'applicazione su schede diverse. Il comportamento predefinito consiste nel rendere persistente lo stato tra le schede per la stessa origine.

Come affermato in precedenza, esistono molteplici situazioni in cui potrebbe essere necessario sovrascrivere la persistenza permanente predefinita.

Tipi supportati di persistenza dello stato di autenticazione

Puoi scegliere uno dei tre tipi di persistenza dello stato di autenticazione su un'istanza di autenticazione Firebase specificata in base all'applicazione o ai requisiti dell'utente.

Modifica della persistenza dello stato di autenticazione

Puoi specificare o modificare il tipo di persistenza esistente chiamando il metodo 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

Ciò modificherà il tipo di persistenza sull'istanza di autenticazione specificata per la sessione di autenticazione attualmente salvata e applicherà questo tipo di persistenza per le future richieste di accesso, incluso l'accesso con richieste di reindirizzamento. Ciò restituirà una promessa che verrà risolta una volta che lo stato avrà terminato la copia da un tipo di archiviazione all'altro. La chiamata a un metodo di accesso dopo la modifica della persistenza attenderà il completamento della modifica della persistenza prima di applicarla al nuovo stato di autenticazione.

L'impostazione predefinita per il browser Web e le app React Native è local (a condizione che il browser supporti questo meccanismo di archiviazione, ad esempio i cookie/dati di terze parti siano abilitati) mentre none lo è per le app backend Node.js.

Panoramica del comportamento di persistenza

I seguenti criteri verranno applicati per determinare lo stato attuale di persistenza.

• Inizialmente, l'SDK controllerà se esiste un utente autenticato. A meno che non venga chiamato setPersistence , il tipo di persistenza corrente dell'utente verrà applicato per i futuri tentativi di accesso. Pertanto, se l'utente è stato persistente nella session di una pagina Web precedente ed è stata visitata una nuova pagina, l'accesso successivo con un utente diverso comporterà il salvataggio anche dello stato di quell'utente con la persistenza session .
• Se nessun utente ha effettuato l'accesso e non è specificata alcuna persistenza, verrà applicata l'impostazione predefinita ( local in un'app browser).
• Se nessun utente ha effettuato l'accesso ed è impostato un nuovo tipo di persistenza, qualsiasi tentativo di accesso futuro utilizzerà quel tipo di persistenza.
• Se l'utente ha effettuato l'accesso e il tipo di persistenza viene modificato, l'utente esistente che ha effettuato l'accesso cambierà la persistenza con quella nuova. Tutti i futuri tentativi di accesso utilizzeranno la nuova persistenza.

• Quando viene chiamato signInWithRedirect, il tipo di persistenza corrente viene mantenuto e applicato alla fine del flusso OAuth all'utente appena connesso, anche se la persistenza era none . Se la persistenza è specificata esplicitamente in quella pagina, sovrascriverà la persistenza dello stato di autenticazione mantenuta dalla pagina precedente che ha avviato il flusso di reindirizzamento.

  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

  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;
    });
  auth-state-persistence.js

Comportamento previsto nelle schede del browser

Il seguente comportamento previsto si applicherà quando vengono utilizzati tipi di persistenza diversi in schede diverse. Il requisito è che in qualsiasi momento non dovrebbero mai esserci più tipi di stati salvati contemporaneamente (ad esempio, stato di autenticazione salvato nella session e tipi di archiviazione local ):

• Gli utenti possono accedere utilizzando session o none persistenza con utenti diversi su più schede. Ciascuna scheda non può vedere lo stato dell'altra scheda.
• Qualsiasi tentativo di accesso utilizzando la persistenza local verrà rilevato e sincronizzato su tutte le schede. Se l'utente ha precedentemente effettuato l'accesso a una scheda specifica utilizzando session o none persistenza, tale stato verrà cancellato.
• Se l'utente ha effettuato l'accesso in precedenza utilizzando la persistenza local con più schede aperte e poi passa a none o alla persistenza session in una scheda, lo stato di quella scheda verrà modificato con l'utente persistente in session o none e su tutte le altre schede, l'utente verrà disconnesso.