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, di installare e configurare Local Emulator Suite e di esaminare i relativi comandi CLI.

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

Cosa posso fare con l'emulatore Authentication?

L'emulatore Authentication fornisce un'emulazione locale ad alta fedeltà dei servizi Firebase Authentication, offrendo molte delle funzionalità disponibili in Firebase Authenticationdi produzione. Se abbinato alle piattaforme Apple, gli SDK Firebase per Android e web, l'emulatore ti consente di:

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

Scegli 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 directory di lavoro in CLI. In alternativa, puoi passare il flag --project a ogni comando dell'emulatore.

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

Tipo di progetto Funzionalità Utilizzo con emulatori
Reale

Un progetto Firebase reale è quello 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 il progetto Firebase.

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

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

Demo

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

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

Quando utilizzi progetti Firebase di prova, le tue app e il tuo codice interagiscono solo con gli emulatori. Se la tua app tenta di interagire con una risorsa per la quale non è in esecuzione un emulatore, il codice non andrà a buon fine.

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

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

Instrumenta l'app in modo che comunichi con l'emulatore

SDK per Android, iOS e web

Configura la configurazione in-app o le classi di test per interagire con l'emulatore Authentication come segue.

Kotlin+KTX
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 creare un prototipo 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

I 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 è automaticamente consapevole dell'emulatore Authentication, quindi puoi saltare questo passaggio quando testi le 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 SDK accetterà token ID non firmati e cookie di sessione emessi dall'emulatore Authentication (rispettivamente tramite i metodi verifyIdToken e createSessionCookie) per facilitare lo sviluppo e il test locale. Assicurati di non impostare la variabile di ambiente in produzione.

Se vuoi che il codice Admin SDK si connetta a un emulatore condiviso in un altro ambiente, devi specificare lo stesso ID progetto impostato utilizzando Firebase CLI. Puoi passare un ID progetto direttamente a initializeApp 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 non interattivo tramite la sua interfaccia REST locale. Le sezioni che seguono coprono casi d'uso interattivi e non interattivi.

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

firebase emulators:start

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

Per l'autenticazione email/password, puoi iniziare a creare la prototipazione aggiungendo account utente all'emulatore Authentication dalla tua app utilizzando i metodi 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 per la creazione dell'account utente, compilando i campi di autenticazione email.

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

Per testare la verifica email/l'accesso con i flussi di link email, l'emulatore stampa un URL sul 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 le reimpostazione delle password, l'emulatore stampa un URL simile, incluso un parametro newPassword (che puoi modificare in base alle esigenze), sul terminale.

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

Test non interattivi

Anziché utilizzare il codice Emulator Suite UI o client per gestire gli account utente email/password, puoi scrivere script di configurazione del test che richiamano le API REST per creare ed eliminare gli account utente e recuperare i codici di verifica email esterni 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 di email e password non interattivi, la sequenza tipica è la seguente.

  1. Crea gli utenti con l'Authentication endpoint REST signUp.
  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. Svuotare i record utente con l'endpoint REST specifico dell'emulatore per cancellare i dati.

Autenticazione telefonica/SMS simulata

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

  • Flussi reCAPTCHA e APN. Una volta configurati per interagire con l'emulatore, gli SDK client disattivano questi metodi di verifica in modo simile a quanto descritto per i test di integrazione (iOS, Android, web).
  • Prova i numeri di telefono con i 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 telefonica.

Tuttavia, per i flussi di autenticazione dello smartphone, l'emulatore NON attiverà l'invio di SMS, poiché contattare un operatore non rientra nell'ambito e non è agevole per i test locali. L'emulatore stampa invece il codice che sarebbe stato inviato tramite SMS allo stesso terminale su cui hai eseguito firebase emulators:start. Inserisci questo codice nell'app per simulare gli utenti che controllano i messaggi.

Test non interattivi

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 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 multifattoriale (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 di secondo fattore. I messaggi vengono visualizzati nello stesso terminale in cui hai eseguito firebase emulators:start e sono disponibili dall'interfaccia REST.

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

L'emulatore Authentication ti consente di testare molti flussi di autenticazione di terze parti nelle tue app web, per iOS o Android senza apportare 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 due modi:

  • L'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.
  • L'app recupera manualmente le credenziali da un fornitore di terze parti utilizzando l'SDK di terze parti e le passa all'SDK Authentication.

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

Test dei flussi IDP basati sull'SDK Firebase

Se la tua app utilizza un flusso end-to-end dell'SDK Firebase, ad esempio OAuthProvider per accedere 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, visualizzate dalla libreria webview della tua piattaforma.

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

Testare i flussi dell'identità provider con il recupero manuale delle credenziali

Se utilizzi tecniche di accesso "manuali" e chiami il metodo signInWithCredentials della tua piattaforma, come di consueto la tua app richiederà l'accesso a terze parti reali 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 interattivi

Un approccio ai test non interattivi è automatizzare i clic dell'utente sulla pagina di accesso gestita dall'emulatore. Per le app web, utilizza un'interfaccia di controllo come WebDriver. Per i dispositivi mobili, utilizza gli strumenti di test dell'interfaccia utente della tua piattaforma, come Espresso o Xcode.

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

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

Se utilizzato con l'emulatore, questo codice autentica un utente con indirizzo 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 simulata

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

Differenze tra l'emulatore Authentication e la produzione

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

Cloud IAM

Firebase Emulator Suite non tenta di replicare o rispettare alcun comportamento correlato all'IAM per l'esecuzione. Gli emulatori rispettano le Regole di sicurezza di Firebase fornite, ma nelle situazioni in cui normalmente verrebbe 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 tua macchina dello sviluppatore, in modo simile all'esecuzione diretta di uno script locale.

Poiché sulle piattaforme mobile l'accesso tramite link email si basa sui link dinamici Firebase, 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 fornitori di terze parti come Twitter e GitHub.

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

Accesso tramite email / SMS

Nelle app di produzione, i flussi di accesso via email e SMS comportano 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 invia al terminale per utilizzarli nei test.

L'emulatore non supporta la possibilità di definire numeri di telefono di test con codici di accesso fissi, come è possibile 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 volta attivati entrambi gli eventi beforeCreate e beforeSignIn. Tuttavia, a causa di limitazioni tecniche, l'emulatore Authentication scrive nello store due volte, una 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 in produzione riscontrerai un errore.

Che cosa succede ora?