Best practice per l'utilizzo di signInWith competenza sui browser che bloccano l'accesso allo spazio di archiviazione di terze parti

Questo documento descrive le best practice per l'utilizzo degli accessi di 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 18 giugno 2024, per il corretto funzionamento dell'accesso di reindirizzamento su Google Chrome M115 e versioni successive sarà necessario implementare una delle opzioni. Questa operazione è già obbligatoria su Firefox 109 e versioni successive e Safari 16.1 e versioni successive.

Panoramica

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

Poiché raramente è possibile chiedere agli utenti di disabilitare le funzionalità di partizionamento dello spazio di archiviazione nel browser, dovresti applicare alla tua app una delle seguenti opzioni di configurazione, 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 niente.
• Se ospiti la tua app con Firebase Hosting su un dominio personalizzato o 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 dominio personalizzato come authDomain

Se ospiti la tua app con Firebase Hosting utilizzando un dominio personalizzato, puoi configurare l'SDK Firebase in modo che utilizzi il dominio personalizzato come authDomain. Questo garantisce che la tua app e l'iframe di autenticazione utilizzino lo stesso dominio, evitando così il problema di accesso. Se non utilizzi Firebase Hosting, devi utilizzare un'opzione diversa. Assicurati di aver configurato il dominio personalizzato sullo stesso progetto che utilizzi per l'autenticazione.

Per aggiornare la configurazione di Firebase in modo da utilizzare il dominio personalizzato come dominio di autenticazione, segui questi passaggi:

1. Configura l'SDK Firebase JS in modo che utilizzi il 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: normalmente, non dovresti modificare altri campi nell'oggetto Firebase Config. Scopri di più sull'oggetto Firebase Config.

1. Aggiungi il nuovo authDomain all'elenco degli URI di reindirizzamento autorizzati del tuo provider OAuth. La procedura dipende dal provider, ma in generale puoi seguire la sezione "Prima di iniziare" in qualsiasi provider per istruzioni esatte (ad esempio, il provider Facebook). L'URI aggiornato da autorizzare è simile a https://<the-domain-that-serves-your-app>/__/auth/handler: il valore /__/auth/handler finale è importante.

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

2. Assicurati che continue_uri sia nell'elenco dei domini autorizzati.

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

Opzione 2: passa a signInWithPopup()

Usa signInWithPopup() anziché signInWithRedirect(). Il resto del codice dell'app rimane invariato, ma l'oggetto UserCredential viene recuperato 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 l'ideale per gli utenti: i popup vengono occasionalmente bloccati dal dispositivo o dalla piattaforma e il flusso è meno fluido per gli utenti dei dispositivi mobili. Se l'utilizzo dei popup è un problema per la tua app, devi seguire una delle altre opzioni.

Opzione 3: richieste di autenticazione proxy 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 il codice helper per l'accesso che reindirizza al provider di identità, che, se l'operazione ha esito positivo, reindirizza al dominio dell'app.

Quando il flusso di autenticazione torna al dominio dell'app, viene eseguito l'accesso all'archiviazione del browser del dominio helper per l'accesso. Questa opzione e quella successiva (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 delle app in modo che le richieste GET/POST a https://<app domain>/__/auth/ vengano inoltrate a https://<project>.firebaseapp.com/__/auth/. Assicurati che questo inoltro sia trasparente per il browser; questa operazione non può essere eseguita tramite un reindirizzamento 302.

   Se utilizzi nginx per gestire il tuo dominio personalizzato, la configurazione del proxy inverso sarà simile a questa:

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

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

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

Un altro modo per eliminare l'accesso allo spazio di archiviazione multiorigine è ospitare autonomamente il codice helper per l'accesso a Firebase. Tuttavia, questo approccio non funziona per l'accesso Apple o SAML. Utilizza questa opzione solo se la configurazione del proxy inverso nell'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 questi 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 precedenti nel dominio dell'app. Assicurati che il tuo server web risponda a https://<app domain>/__/auth/<filename> e https://<app domain>/__/firebase/init.json.

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

3. Segui la procedura descritta in Opzione 1 per aggiornare i redirect_uri autorizzati e i tuoi authDomain. Dopo aver eseguito nuovamente il deployment dell'app, l'accesso allo spazio di archiviazione multiorigine non dovrebbe più essere eseguito.

Opzione 5: gestire l'accesso del provider in modo indipendente

Importante: questo è un approccio complesso che utilizza SDK aggiuntivi e potenzialmente può essere molto utile per i provider SAML.

L'SDK Firebase Authentication fornisce signInWithPopup() e signInWithRedirect() come metodi comodi per eseguire il wrapping di logica complicata ed evitare la necessità di coinvolgere un altro SDK. Puoi evitare di utilizzare del tutto entrambi i metodi accedendo in modo indipendente al provider e poi utilizzando signInWithCredential() per scambiare le credenziali del provider con quelle di Firebase Authentication. Ad esempio, puoi utilizzare l'SDK Accedi con Google, un codice campione per ottenere una credenziale dell'Account Google, quindi creare un'istanza di una nuova credenziale di Google eseguendo questo 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 della tua app funziona come prima.

Le istruzioni per ottenere una credenziale Apple sono disponibili qui.