Questo documento descrive le best practice per l'utilizzo degli accessi di reindirizzamento sui browser che bloccano i cookie di terze parti. È necessario seguire una delle opzioni elencate qui affinché signInWithRedirect() funzioni come previsto negli ambienti di produzione, su tutti i browser.
Panoramica
Per rendere il flusso signInWithRedirect() fluido per te e i tuoi utenti, l'SDK JavaScript di Firebase Authentication utilizza un iframe multiorigine che si connette al dominio di hosting Firebase della tua app. Tuttavia, questo meccanismo non funziona con i browser che bloccano l'accesso allo spazio di archiviazione di terze parti.
Poiché chiedere agli utenti di disabilitare le funzionalità di partizionamento dell'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, non sei interessato da questo problema e non è necessaria alcuna azione. - 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 tuo dominio personalizzato come authDomain
Se stai ospitando la tua app con Firebase Hosting utilizzando un dominio personalizzato, puoi configurare l'SDK Firebase in modo che utilizzi il tuo dominio personalizzato come authDomain . Ciò garantisce che la tua app e l'iframe di autenticazione utilizzino lo stesso dominio, il che impedisce il problema di accesso. (Se non utilizzi Firebase Hosting, devi utilizzare un'opzione diversa.)
Per aggiornare la configurazione di Firebase per utilizzare il tuo dominio personalizzato come dominio di autenticazione, procedi come segue:
Configura l'SDK Firebase JS per utilizzare 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>" };Aggiungi il nuovo
authDomainall'elenco degli URI di reindirizzamento autorizzati del tuo provider OAuth. Il modo in cui lo fai dipenderà dal provider, ma in generale puoi seguire la sezione "Prima di iniziare" in qualsiasi provider per le istruzioni esatte (ad esempio, il provider Facebook ). L'URI aggiornato per autorizzare è simile ahttps://<the-domain-that-serves-your-app>/__/auth/handler— il finale/__/auth/handlerè importante.Analogamente, se utilizzi un provider SAML, aggiungi il nuovo
authDomainall'URL ACS (Assertion Consumer Service) SAML.
Opzione 2: passa a signInWithPopup()
Usa signInWithPopup() invece di signInWithRedirect() . Il resto del codice dell'app rimane lo stesso, ma l'oggetto UserCredential viene recuperato in modo diverso.
Web version 9
// Before
// ==============
signInWithRedirect(auth, new GoogleAuthProvider());
// After the page redirects back
const userCred = await getRedirectResult(auth);
// After
// ==============
const userCred = await signInWithPopup(auth, new GoogleAuthProvider());
Web version 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 tramite 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 mobili. Se l'utilizzo dei popup è un problema per la tua app, dovrai 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 ("authDomain ospita il codice helper di accesso che reindirizza al provider di identità, che, in caso di successo, 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 dell'assistente di accesso. Questa opzione e quella successiva (per ospitare autonomamente il codice) eliminano l'accesso allo storage cross-origin, che altrimenti viene bloccato dai browser.
Imposta un proxy inverso sul server dell'app in modo che le richieste GET/POST a
https://<app domain>/__/auth/vengano inoltrate ahttps://<project>.firebaseapp.com/__/auth/. Assicurati che questo inoltro sia trasparente per il browser; questo non può essere fatto tramite un reindirizzamento 302.Se stai utilizzando nginx per servire 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; }Segui i passaggi nell'opzione 1 per aggiornare
redirect_uriautorizzato, l'URL ACS e il tuoauthDomain. Dopo aver ridistribuito la tua app, l'accesso all'archiviazione tra le origini non dovrebbe più verificarsi.
Opzione 4: ospita autonomamente il codice di supporto per l'accesso nel tuo dominio
Un altro modo per eliminare l'accesso all'archiviazione multiorigine consiste nell'ospitare autonomamente il codice di supporto per l'accesso Firebase. Tuttavia, questo approccio non funziona per l'accesso Apple o SAML. Utilizzare questa opzione solo se l'impostazione del proxy inverso nell'opzione 3 non è fattibile.
L'hosting del codice helper prevede i seguenti passaggi:
Scarica i file da ospitare dalla posizione
<project>.firebaseapp.comeseguendo 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.jsOspita i file precedenti nel dominio dell'app. Assicurati che il tuo server web possa rispondere a
https://<app domain>/__/auth/<filename>.Ecco un esempio di implementazione del server che scarica e ospita i file. Si consiglia di scaricare e sincronizzare periodicamente i file per assicurarsi che vengano rilevate le correzioni di bug e le funzionalità più recenti.
Segui i passaggi nell'opzione 1 per aggiornare
redirect_uriautorizzato e il tuoauthDomain. Dopo aver ridistribuito la tua app, l'accesso all'archiviazione tra le origini non dovrebbe più verificarsi.
Opzione 5: gestire l'accesso del provider in modo indipendente
L'SDK di autenticazione Firebase fornisce signInWithPopup() e signInWithRedirect() come metodi pratici per eseguire il wrapping di una logica complicata ed evitare la necessità di coinvolgere un altro SDK. Puoi evitare di utilizzare entrambi i metodi accedendo in modo indipendente al tuo provider, quindi utilizzando signInWithCredential() per scambiare le credenziali del provider con una credenziale di autenticazione Firebase. Ad esempio, puoi utilizzare Google Sign In SDK , codice di esempio per ottenere le credenziali di un account Google, quindi creare un'istanza di una nuova credenziale Google eseguendo il seguente codice:
Web version 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);
Web version 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 .