Collegare l'app all'emulatore Authentication

Prima di utilizzare l'emulatore Authentication con la tua app, assicurati di comprendere il flusso di lavoro complessivo di Firebase Local Emulator Suite e di installare e configurare Local Emulator Suite e di esaminare i relativi comandi CLI.

Questo argomento presuppone che tu abbia già familiarità con lo sviluppo di soluzioni Firebase Authentication per la produzione. Se necessario, consulta la documentazione per la tua combinazione di piattaforma e tecnica di autenticazione.

Che cosa posso fare con l'emulatore Authentication?

L'emulatore Authentication fornisce un'emulazione locale ad alta fedeltà dei servizi Firebase Authentication, offrendo gran parte delle funzionalità disponibili nella Firebase Authentication di produzione. Insieme agli SDK Firebase per le piattaforme Apple, Android e web, l'emulatore ti consente di:

  • Crea, aggiorna e gestisci account utente emulati per testare l'autenticazione con email/password, numero di telefono/SMS, SMS multifattoriale e provider di identità di terze parti (ad es. Google)
  • Visualizzare e modificare gli utenti emulati
  • Prototipare sistemi di autenticazione con token personalizzati
  • Controlla i messaggi relativi all'autenticazione nella scheda Log dell'interfaccia utente dell'emulatore.

Scegliere un progetto Firebase

Firebase Local Emulator Suite emula i prodotti per un singolo progetto Firebase.

Per selezionare il progetto da utilizzare, prima di avviare gli emulatori, esegui firebase use nella CLI nella directory di lavoro. In alternativa, puoi passare il flag --project a ogni comando dell'emulatore.

Local Emulator Suite supporta l'emulazione di progetti Firebase reali e dimostrativi.

Tipo di progetto Funzionalità Utilizzo con emulatori
Reale

Un progetto Firebase reale è un progetto che hai creato e configurato (molto probabilmente tramite la console Firebase).

I progetti reali hanno risorse attive, come istanze di database, bucket di archiviazione, funzioni o qualsiasi altra risorsa configurata per quel progetto Firebase.

Quando lavori con progetti Firebase reali, puoi eseguire emulatori per uno o tutti i prodotti supportati.

Per i prodotti che non emuli, le tue app e il tuo codice interagiranno con la risorsa live (istanza di database, bucket di archiviazione, funzione e così via).

Demo

Un progetto Firebase dimostrativo non ha una configurazione Firebase reale e nessuna risorsa live. In genere, si accede a questi progetti tramite codelab o altri tutorial.

Gli ID progetto per i progetti demo hanno il prefisso demo-.

Quando lavori con i progetti demo Firebase, le tue app e il tuo codice interagiscono solo con gli emulatori. Se la tua app tenta di interagire con una risorsa per cui non è in esecuzione un emulatore, il codice non funzionerà.

Ti consigliamo di utilizzare i progetti demo, se possibile. I vantaggi includono:

  • Configurazione più semplice, in quanto puoi eseguire gli emulatori senza creare un progetto Firebase
  • Maggiore sicurezza, perché se il codice richiama accidentalmente risorse non emulate (di produzione), non c'è possibilità di modifica dei dati, utilizzo e fatturazione
  • Migliore supporto offline, in quanto non è necessario accedere a internet per scaricare la configurazione dell'SDK.

Strumentare l'app per comunicare con l'emulatore

SDK per Android, iOS e web

Configura le classi di test o la configurazione in-app per interagire con l'emulatore Authentication nel seguente modo.

Kotlin
Firebase.auth.useEmulator("10.0.2.2", 9099)
Java
FirebaseAuth.getInstance().useEmulator("10.0.2.2", 9099);
Swift
Auth.auth().useEmulator(withHost:"127.0.0.1", port:9099)

Web

import { getAuth, connectAuthEmulator } from "firebase/auth";

const auth = getAuth();
connectAuthEmulator(auth, "http://127.0.0.1:9099");
auth_emulator_connect.js

Web

const auth = firebase.auth();
auth.useEmulator("http://127.0.0.1:9099");
emulator-suite.js

Non è necessaria alcuna configurazione aggiuntiva per prototipare e testare le interazioni tra Authentication e Cloud Functions o Firebase Security Rules per Cloud Firestore o Realtime Database. Quando l'emulatore Authentication è configurato e altri emulatori sono in esecuzione, funzionano automaticamente insieme.

Admin SDK s

Firebase Admin SDK si connettono automaticamente all'emulatore Authentication quando è impostata la variabile di ambiente FIREBASE_AUTH_EMULATOR_HOST.

export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"

Tieni presente che l'emulatore Cloud Functions riconosce automaticamente l'emulatore Authentication, quindi puoi saltare questo passaggio durante il test delle integrazioni tra gli emulatori Cloud Functions e Authentication. La variabile di ambiente verrà impostata automaticamente per Admin SDK in Cloud Functions.

Con la variabile di ambiente impostata, Firebase Admin SDKs accetterà token ID senza firma e cookie di sessione emessi dall'emulatore Authentication (rispettivamente tramite i metodi verifyIdToken e createSessionCookie) per facilitare lo sviluppo e i test locali. Assicurati di non impostare la variabile di ambiente in produzione.

Se vuoi che il codice Admin SDK si connetta a un emulatore condiviso in esecuzione in un altro ambiente, devi specificare lo stesso ID progetto impostato utilizzando la CLI Firebase. Puoi trasmettere un ID progetto a initializeApp direttamente o impostare la variabile di ambiente GCLOUD_PROJECT.

SDK Node.js Admin
admin.initializeApp({ projectId: "your-project-id" });
Variabile di ambiente
export GCLOUD_PROJECT="your-project-id"

Token ID

Per motivi di sicurezza, l'emulatore Authentication emette token ID non firmati, che vengono accettati solo da altri emulatori Firebase o dall'SDK Firebase Admin se configurato. Questi token verranno rifiutati dai servizi Firebase di produzione o dall'SDK Firebase Admin in esecuzione in modalità di produzione (ad es. il comportamento predefinito senza i passaggi di configurazione descritti sopra).

Avvia l'emulatore

Puoi utilizzare l'emulatore Authentication in modo interattivo tramite Emulator Suite UI e in modo non interattivo tramite la sua interfaccia REST locale. Le sezioni seguenti riguardano casi d'uso interattivi e non interattivi.

Per avviare l'emulatore Authentication, la relativa interfaccia REST e Emulator Suite UI, esegui:

firebase emulators:start

Per l'autenticazione anonima, la tua app può esercitare la logica di accesso per la tua piattaforma (iOS, Android, web).

Per l'autenticazione tramite email/password, puoi iniziare a creare prototipi aggiungendo account utente all'emulatore Authentication dalla tua app utilizzando i metodi dell'SDK Authentication o utilizzando Emulator Suite UI.

  1. In Emulator Suite UI, fai clic sulla scheda Autenticazione.
  2. Fai clic sul pulsante Aggiungi utente.
  3. Segui la procedura guidata di creazione dell'account utente, compilando i campi di autenticazione email.

Con un utente di test creato, la tua app può accedere e uscire con la logica dell'SDK per la tua piattaforma (iOS, Android, web).

Per testare i flussi di verifica dell'email/accesso con link email, l'emulatore stampa un URL nel terminale in cui è stato eseguito firebase emulators:start.

i  To verify the email address customer@ex.com, follow this link:
http://127.0.0.1:9099/emulator/action?mode=verifyEmail&lang=en&oobCode=XYZ123&apiKey=fake-api-key

Incolla il link nel browser per simulare l'evento di verifica e controlla se la verifica è andata a buon fine.

{
  "authEmulator": {
    "success": "The email has been successfully verified.",
    "email": "customer@example.com"
  }
}

Per testare i reimpostazioni della password, l'emulatore stampa un URL simile, incluso un parametro newPassword (che puoi modificare in base alle esigenze), nel terminale.

http://127.0.0.1:9099/emulator/action?mode=resetPassword&oobCode=XYZ!23&apiKey=fake-api-key&newPassword=YOUR_NEW_PASSWORD

Test non interattivo

Anziché utilizzare il codice Emulator Suite UI o il codice client per gestire gli account utente email/password, puoi scrivere script di configurazione dei test che chiamano le API REST per creare ed eliminare gli account utente e recuperare i codici di verifica email fuori banda per compilare l'URL di verifica email dell'emulatore. In questo modo, il codice della piattaforma e quello di test rimangono separati e puoi eseguire test non interattivi.

Per i flussi di test non interattivi di email e password, la sequenza tipica è la seguente.

  1. Crea utenti con l'endpoint REST signUp Authentication.
  2. Accedi agli utenti utilizzando le email e le password per eseguire i test.
  3. Se applicabile ai tuoi test, recupera i codici di verifica email out-of-band disponibili dall'endpoint REST specifico dell'emulatore.
  4. Elimina i record utente con l'endpoint REST specifico dell'emulatore per cancellare i dati.

Autenticazione tramite telefono/SMS emulato

Per l'autenticazione telefonica, l'emulatore Auth non supporta:

  • reCAPTCHA e flussi APN. Una volta configurati per interagire con l'emulatore, gli SDK client disattivano questi metodi di verifica in modo simile a quello descritto per i test di integrazione (iOS, Android, web).
  • Numeri di telefono di test con codici preconfigurati nella console Firebase.

In caso contrario, in termini di codice client, il flusso di autenticazione tramite telefono/SMS è identico a quello descritto per la produzione (iOS, Android, web).

Utilizzo di Emulator Suite UI:

  1. In Emulator Suite UI, fai clic sulla scheda Autenticazione.
  2. Fai clic sul pulsante Aggiungi utente.
  3. Segui la procedura guidata per la creazione dell'account utente, compilando i campi di autenticazione del telefono.

Tuttavia, per i flussi di autenticazione telefonica, l'emulatore NON attiverà la consegna di alcun messaggio, poiché il contatto con un operatore non è incluso e non è adatto ai test locali. L'emulatore stampa invece il codice che sarebbe stato inviato via SMS allo stesso terminale su cui hai eseguito firebase emulators:start; inserisci questo codice nell'app per simulare gli utenti che controllano i loro messaggi di testo.

Test non interattivo

Per i test di autenticazione telefonica non interattivi, utilizza l'API REST dell'emulatore Authentication per recuperare i codici SMS disponibili. Tieni presente che il codice è diverso ogni volta che avvii il flusso.

La sequenza tipica è la seguente.

  1. Chiama la piattaforma signInWithPhoneNumber per avviare la procedura di verifica.
  2. Recupera il codice di verifica utilizzando l'endpoint REST specifico dell'emulatore.
  3. Chiama il numero confirmationResult.confirm(code) come di consueto con il codice di verifica.

Autenticazione a più fattori con SMS

L'emulatore Authentication supporta la prototipazione e il test dei flussi di autenticazione a più fattori (MFA) tramite SMS disponibili in produzione per iOS, Android e web.

Quando aggiungi un utente simulato all'emulatore, puoi attivare l'autenticazione a più fattori e configurare uno o più numeri di telefono a cui verranno inviati i messaggi SMS del secondo fattore. I messaggi vengono inviati allo stesso terminale in cui hai eseguito firebase emulators:start e sono disponibili dall'interfaccia REST.

Autenticazione del provider di identità (IdP) di terze parti emulato

L'emulatore Authentication ti consente di testare molti flussi di autenticazione di terze parti nelle tue app web, iOS o Android senza modifiche al codice di produzione. Per esempi di flussi di autenticazione, consulta la documentazione relativa alle varie combinazioni di provider e piattaforme che puoi utilizzare nella tua app.

In generale, puoi utilizzare l'SDK Firebase per l'autenticazione in uno dei due modi seguenti:

  • La tua app consente all'SDK di gestire l'intero processo end-to-end, incluse tutte le interazioni con i fornitori di IDP di terze parti per recuperare le credenziali.
  • La tua app recupera manualmente le credenziali da un provider di terze parti utilizzando l'SDK di questa terza parte e le trasmette all'SDK Authentication.

Ancora una volta, controlla il link alla documentazione riportato sopra e assicurati di conoscere il flusso che vuoi utilizzare, ovvero quello gestito dall'SDK Firebase o il recupero manuale delle credenziali. L'emulatore Authentication supporta il test di entrambi gli approcci.

Testare i flussi IDP basati sull'SDK Firebase

Se la tua app utilizza un flusso end-to-end dell'SDK Firebase, ad esempio OAuthProvider per l'accesso con Microsoft, GitHub o Yahoo, per i test interattivi, l'emulatore Authentication fornisce una versione locale della pagina di accesso corrispondente per aiutarti a testare l'autenticazione dalle app web che chiamano il metodo signinWithPopup o signInWithRedirect. Questa pagina di accesso pubblicata localmente viene visualizzata anche nelle app mobile, renderizzata dalla libreria WebView della piattaforma.

L'emulatore crea account utente e credenziali di terze parti simulati in base alle necessità man mano che i flussi procedono.

Testare i flussi IdP con il recupero manuale delle credenziali

Se utilizzi tecniche di accesso "manuali" e chiami il metodo signInWithCredentials della tua piattaforma, la tua app richiederà l'accesso di terze parti reale e recupererà le credenziali di terze parti reali.

Tieni presente che l'emulatore supporta solo l'autenticazione signInWithCredential per le credenziali recuperate da Accedi con Google, Apple e altri provider che utilizzano token ID implementati come token web JSON (JWT). I token di accesso (ad es. quelli forniti da Facebook o Twitter, che non sono JWT) non sono supportati. La sezione successiva illustra un'alternativa in questi casi.

Test non interattivo

Un approccio al test non interattivo consiste nell'automatizzare i clic degli utenti sulla pagina di accesso fornita dall'emulatore. Per le app web, utilizza un'interfaccia di controllo come WebDriver. Per il mobile, utilizza gli strumenti di test della UI della tua piattaforma, come Espresso o Xcode.

In alternativa, puoi aggiornare il codice per utilizzare signInWithCredential (ad es. in un ramo di codice) e utilizzare un flusso di autenticazione con token con token ID simulati per gli account anziché credenziali reali.

  1. Ricollega o commenta la parte di codice che recupera gli idToken dall'IdP. In questo modo, non sarà necessario inserire nomi utente e password reali durante i test e questi non saranno soggetti a quote e limiti di frequenza dell'API dell'IdP.
  2. In secondo luogo, utilizza una stringa JSON letterale al posto del token per signInWithCredential. Utilizzando l'SDK web come esempio, puoi modificare il codice in modo che sia:
firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
  '{"sub": "abc123", "email": "foo@example.com", "email_verified": true}'
));

Se utilizzato con l'emulatore, questo codice autenticherà correttamente un utente con l'email foo@example.com su Google. Considera il campo secondario come una chiave primaria, che può essere modificata in qualsiasi stringa, simulando l'accesso di utenti diversi. Puoi sostituire firebase.auth.GoogleAuthProvider con, ad esempio, new firebase.auth.OAuthProvider('yahoo.com') o qualsiasi altro ID fornitore che vuoi simulare.

Autenticazione con token personalizzato emulato

L'emulatore Authentication gestisce l'autenticazione con token web JSON personalizzati utilizzando chiamate al metodo signInWithCustomToken sulle piattaforme supportate, come descritto nella documentazione di Authenticationproduzione.

Differenze tra l'emulatore Authentication e la produzione

L'emulatore Firebase Authentication simula molte funzionalità del prodotto di produzione. Tuttavia, poiché qualsiasi tipo di sistema di autenticazione si basa fortemente sulla sicurezza a più livelli (dispositivo, fornitori di terze parti, Firebase, ecc.), è difficile per l'emulatore ricreare correttamente tutti i flussi.

Cloud IAM

Firebase Emulator Suite non tenta di replicare o rispettare alcun comportamento correlato a IAM per l'esecuzione. Gli emulatori rispettano le regole di sicurezza di Firebase fornite, ma nelle situazioni in cui normalmente viene utilizzato IAM, ad esempio per impostare il service account di chiamata di Cloud Functions e quindi le autorizzazioni, l'emulatore non è configurabile e utilizzerà l'account disponibile a livello globale sulla macchina dello sviluppatore, in modo simile all'esecuzione diretta di uno script locale.

Poiché sulle piattaforme mobile l'accesso tramite link via email si basa su Firebase Dynamic Links, tutti questi link verranno aperti sulla piattaforma web (mobile).

Accesso di terze parti

Per i flussi di accesso di terze parti, Firebase Authentication si basa su credenziali sicure di provider di terze parti come Twitter e GitHub.

Le credenziali reali di provider OpenID Connect come Google e Apple sono accettate dall'emulatore Authentication. Le credenziali di provider non OpenID Connect non sono supportate.

Accesso tramite email / SMS

Nelle app di produzione, i flussi di accesso tramite email e SMS prevedono un'operazione asincrona in cui l'utente controlla un messaggio ricevuto e inserisce un codice di accesso in un'interfaccia di accesso. L'emulatore Authentication non invia email o messaggi SMS, ma, come descritto sopra, genera codici di accesso e li restituisce al terminale per essere utilizzati nei test.

L'emulatore non supporta la possibilità di definire numeri di telefono di test con codici di accesso fissi, come si può fare utilizzando la console Firebase.

Autenticazione con token personalizzato

L'emulatore Authentication non convalida la firma o la scadenza dei token personalizzati. In questo modo puoi utilizzare token creati manualmente e riutilizzarli indefinitamente in scenari di prototipazione e test.

Limitazione di frequenza / anti-abuso

L'emulatore Authentication non replica le funzionalità di limitazione della frequenza di produzione o anti-abuso.

Funzioni di blocco

In produzione, gli utenti vengono scritti nello spazio di archiviazione una sola volta dopo l'attivazione degli eventi beforeCreate e beforeSignIn. Tuttavia, a causa di limitazioni tecniche, l'emulatore Authentication scrive due volte nello store, una volta dopo la creazione dell'utente e un'altra dopo l'accesso. Ciò significa che per i nuovi utenti puoi chiamare correttamente getAuth().getUser() in beforeSignIn nell'emulatore Authentication, ma si verificherà un errore se lo fai in produzione.

Che cosa succede ora?