Best practice per l'utilizzo di signInWithRedirect su browser che bloccano l'accesso allo spazio di archiviazione di terze parti

Questo documento descrive le best practice per l'utilizzo degli accessi in reindirizzamento sui browser che bloccano i cookie di terze parti. Devi seguire una delle opzioni elencate qui affinché signInWithRedirect() funzioni come previsto negli ambienti di produzione su tutti i browser.

Nota: a partire dal 24 giugno 2024, sarà necessario implementare una delle opzioni affinché l'accesso di reindirizzamento funzioni su Google Chrome M115 e versioni successive. Questa funzionalità è già richiesta su Firefox 109 e versioni successive e Safari 16.1 e versioni successive.

Panoramica

Per semplificare il flusso di signInWithRedirect() per te e per i tuoi utenti, l'SDK JavaScript di Firebase Authentication utilizza un iframe cross-origin che si connette al dominio Firebase Hosting della tua app. Tuttavia, questo meccanismo non funziona con i browser che bloccano i browser di terze parti. l'accesso allo spazio di archiviazione.

Poiché la richiesta agli utenti di disattivare le funzionalità di partizionamento dello spazio di archiviazione sul browser raramente è un'opzione, dovresti invece applicare una delle seguenti opzioni di configurazione alla tua app, a seconda delle specifiche del tuo caso d'uso.

• Se ospiti la tua app con Firebase Hosting su un sottodominio di firebaseapp.com, questo problema non ti riguarda e non devi fare nulla.
• Se ospiti la tua app con Firebase Hosting su un dominio personalizzato o su un sottodominio di web.app, utilizza l'opzione 1.
• Se ospiti la tua app con un servizio diverso da Firebase, utilizza l'opzione 2, l'opzione 3, l'opzione 4 o l'opzione 5.

Opzione 1: aggiorna la configurazione di Firebase per utilizzare il tuo dominio personalizzato come authDomain

Se ospiti la tua app su Firebase Hosting utilizzando un dominio personalizzato, puoi configurare l'SDK Firebase per utilizzare il tuo dominio personalizzato come authDomain. Questo assicura che l'app e l'iframe di autenticazione utilizzino lo stesso dominio, impedendo per risolvere il problema di accesso. Se non utilizzi Firebase Hosting, devi utilizzare un'opzione diversa. Assicurati di aver configurato il dominio personalizzato nello stesso progetto che utilizzi per l'autenticazione.

Per aggiornare la configurazione di Firebase in modo da utilizzare il dominio personalizzato come dominio di autenticazione, svolgi i seguenti passaggi:

1. Configura l'SDK Firebase JS in modo che utilizzi il tuo dominio personalizzato come authDomain:

   const firebaseConfig = {
     apiKey: "<api-key>",
     authDomain: "<the-domain-that-serves-your-app>",
     databaseURL: "<database-url>",
     projectId: "<project-id>",
     appId: "<app-id>"
   };
   

Importante: in genere, non dovresti modificare nessun altro campo nell'oggetto di configurazione di Firebase. Scopri di più sull'oggetto di configurazione di Firebase.

1. Aggiungi il nuovo authDomain all'elenco delle autorizzazioni del provider OAuth di reindirizzamento. La procedura dipende dal fornitore, ma in generale puoi seguire la sezione "Prima di iniziare" di qualsiasi fornitore per istruzioni precise (ad esempio, il fornitore Facebook). L'URI aggiornato da autorizzare ha il seguente aspetto:https://<the-domain-that-serves-your-app>/__/auth/handler. Il carattere finale/__/auth/handler è importante.

   Analogamente, se utilizzi un provider SAML, aggiungi il nuovo authDomain all'URL di ACS (Assertion Consumer Service) SAML.

2. Verifica che il tuo continue_uri sia nell'elenco dei domini autorizzati.

3. Esegui nuovamente il deployment con Firebase Hosting, se necessario, per recuperare il file di configurazione Firebase più aggiornato ospitato all'indirizzo /__/firebase/init.json.

Opzione 2: passa a signInWithPopup()

Utilizza signInWithPopup() al posto di signInWithRedirect(). La il resto del codice dell'app rimane lo stesso, ma l'oggetto UserCredential è recuperate in modo diverso.

Versione web 9

  // Before
  // ==============
  signInWithRedirect(auth, new GoogleAuthProvider());
  // After the page redirects back
  const userCred = await getRedirectResult(auth);

  // After
  // ==============
  const userCred = await signInWithPopup(auth, new GoogleAuthProvider());

Versione web 8

  // Before
  // ==============
  firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());
  // After the page redirects back
  var userCred = await firebase.auth().getRedirectResult();

  // After
  // ==============
  var userCred = await firebase.auth().signInWithPopup(
      new firebase.auth.GoogleAuthProvider());
```

L'accesso popup non è sempre ideale per gli utenti: a volte i popup vengono bloccati dal dispositivo o dalla piattaforma e il flusso è meno fluido per gli utenti di dispositivi mobili. Se utilizzi popup è un problema per la tua app, dovrai seguire una delle altre le opzioni di CPU e memoria disponibili.

Opzione 3: proxy delle richieste di autenticazione a firebaseapp.com

Il flusso signInWithRedirect inizia reindirizzando dal dominio dell'app al dominio specificato nel parametro authDomain nella configurazione di Firebase (".firebaseapp.com" per impostazione predefinita). authDomain ospita l'assistente per l'accesso che reindirizza al provider di identità che, se l'operazione ha esito positivo, al dominio dell'app.

Quando il flusso di autenticazione torna al dominio dell'app, viene eseguito l'accesso allo spazio di archiviazione del browser del dominio dell'helper per l'accesso. Questa opzione e L'utilizzo successivo (per ospitare autonomamente il codice) elimina l'accesso allo spazio di archiviazione multiorigine, che altrimenti viene bloccato dai browser.

1. Configura un proxy inverso sul server dell'app in modo che le richieste GET/POST a https://<app domain>/__/auth/ vengano inoltrate a https://<project>.firebaseapp.com/__/auth/. Assicurati che l'inoltro sia trasparente per il browser; questa operazione non può essere eseguita tramite un reindirizzamento 302.

   Se utilizzi nginx per pubblicare il tuo dominio personalizzato, la configurazione del proxy inverso sarà la seguente:

   # reverse proxy for signin-helpers for popup/redirect sign in.
   location /__/auth {
     proxy_pass https://<project>.firebaseapp.com;
   }
   

2. Segui i passaggi in Opzione 1 per aggiornare i redirect_uri autorizzati, l'URL ACS e il authDomain. Dopo aver eseguito nuovamente il deployment l'app, l'accesso allo spazio di archiviazione multiorigine non dovrebbe più essere eseguito.

Opzione 4: ospita autonomamente il codice di assistenza per l'accesso nel tuo dominio

Un altro modo per eliminare l'accesso allo spazio di archiviazione cross-origin è eseguire l'hosting autonomo del codice di assistenza per l'accesso di Firebase. Tuttavia, questo approccio non funziona per Apple o SAML. Utilizza questa opzione solo se la configurazione del proxy inverso l'opzione 3 non è fattibile.

L'hosting del codice helper prevede i seguenti passaggi:

1. Scarica i file da ospitare dalla posizione <project>.firebaseapp.com eseguendo i seguenti comandi:

   mkdir signin_helpers/ && cd signin_helpers
   wget https://<project>.firebaseapp.com/__/auth/handler
   wget https://<project>.firebaseapp.com/__/auth/handler.js
   wget https://<project>.firebaseapp.com/__/auth/experiments.js
   wget https://<project>.firebaseapp.com/__/auth/iframe
   wget https://<project>.firebaseapp.com/__/auth/iframe.js
   wget https://<project>.firebaseapp.com/__/firebase/init.json
   

2. Ospita i file sopra indicati nel dominio della tua app. Assicurati che il tuo server web può rispondere a https://<app domain>/__/auth/<filename> e https://<app domain>/__/firebase/init.json.

   Ecco un'implementazione server di esempio che scarica e ospita i file. Ti consigliamo di scaricare e sincronizzare i file periodicamente per assicurarti che vengano rilevate le funzionalità e le correzioni di bug più recenti.

3. Segui i passaggi descritti nella Opzione 1 per aggiornare redirect_uri autorizzato e authDomain. Dopo aver eseguito nuovamente il deployment l'app, l'accesso allo spazio di archiviazione multiorigine non dovrebbe più essere eseguito.

Opzione 5: gestisci l'accesso al fornitore in modo indipendente

Importante: si tratta di un approccio complesso che utilizza SDK aggiuntivi e possono essere molto coinvolti per i provider SAML.

L'SDK Firebase Authentication fornisce metodi di comodità come signInWithPopup() e signInWithRedirect() per eseguire il wrapping di una logica complicata ed evitare di dover coinvolgere un altro SDK. Puoi evitare di utilizzare completamente uno dei due metodi accedendo autonomamente al tuo provider e poi utilizzando signInWithCredential() per scambiare le credenziali del provider con una credenziale di Firebase Authentication. Ad esempio, puoi utilizzare l'SDK di Accesso Google, il codice di esempio per ottenere una credenziale dell'Account Google, quindi creare una nuova credenziale Google, eseguendo il seguente codice:

Versione web 9

  // `googleUser` from the onsuccess Google Sign In callback.
  //  googUser = gapi.auth2.getAuthInstance().currentUser.get();
  const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);
  const result = await signInWithCredential(auth, credential);

Versione web 8

  // `googleUser` from the onsuccess Google Sign In callback.
  const credential = firebase.auth.GoogleAuthProvider.credential(
      googleUser.getAuthResponse().id_token);
  const result = await firebase.auth().signInWithCredential(credential);

Dopo aver chiamato signInWithCredential(), il resto dell'app funziona come in precedenza.

Le istruzioni per ottenere una credenziale Apple sono disponibili qui.