Bevor Sie den Authentication-Emulator mit Ihrer App verwenden, müssen Sie den allgemeinen Firebase Local Emulator Suite-Workflow kennen und die Local Emulator Suite installieren und konfigurieren. Außerdem sollten Sie sich die CLI-Befehle ansehen.
In diesem Thema wird davon ausgegangen, dass Sie bereits mit der Entwicklung von Firebase Authentication-Lösungen für die Produktion vertraut sind. Sehen Sie sich bei Bedarf die Dokumentation für Ihre Kombination aus Plattform und Authentifizierungsmethode an.
Was kann ich mit dem Authentication-Emulator tun?
Der Authentication-Emulator bietet eine genaue lokale Emulation von Firebase Authentication-Diensten und damit einen Großteil der Funktionen, die in der Produktionsumgebung von Firebase Authentication verfügbar sind. In Kombination mit den Firebase SDKs für Apple-Plattformen, Android und das Web bietet der Emulator folgende Möglichkeiten:
- Erstellen, aktualisieren und verwalten Sie emulierte Nutzerkonten zum Testen der Authentifizierung mit E-Mail-Adresse/Passwort, Telefonnummer/SMS, SMS-Multi-Faktor und externen (z. B. Google) Identitätsanbietern.
- Emulierte Nutzer ansehen und bearbeiten
- Prototypen für benutzerdefinierte Tokenauthentifizierungssysteme erstellen
- Prüfen Sie auf dem Tab „Emulator UI Logs“ (Emulator-UI-Logs) nachrichtenbezogene Authentifizierungsnachrichten.
Firebase-Projekt auswählen
Mit Firebase Local Emulator Suite werden Produkte für ein einzelnes Firebase-Projekt emuliert.
Wenn Sie das zu verwendende Projekt auswählen möchten, führen Sie vor dem Starten der Emulatoren firebase use
in Ihrem Arbeitsverzeichnis aus. Alternativ können Sie das Flag --project
an jeden Emulatorbefehl übergeben.
Local Emulator Suite unterstützt die Emulation von echten Firebase-Projekten und Demoprojekten.
Projekttyp | Funktionen | Mit Emulatoren verwenden |
---|---|---|
Real |
Ein echtes Firebase-Projekt ist ein Projekt, das Sie erstellt und konfiguriert haben (wahrscheinlich über die Firebase Console). Echte Projekte haben Live-Ressourcen wie Datenbankinstanzen, Storage-Buckets, Funktionen oder andere Ressourcen, die Sie für dieses Firebase-Projekt eingerichtet haben. |
Wenn Sie mit echten Firebase-Projekten arbeiten, können Sie Emulatoren für alle unterstützten Produkte ausführen. Bei allen Produkten, die Sie nicht emulieren, interagieren Ihre Apps und Ihr Code mit der Live-Ressource (Datenbankinstanz, Speicher-Bucket, Funktion usw.). |
Demo |
Ein Firebase-Demoprojekt hat keine echte Firebase-Konfiguration und keine Live-Ressourcen. Auf diese Projekte wird in der Regel über Codelabs oder andere Tutorials zugegriffen. Projekt-IDs für Demoprojekte haben das Präfix |
Wenn Sie mit Firebase-Demoprojekten arbeiten, interagieren Ihre Apps und Ihr Code nur mit Emulatoren. Wenn Ihre App versucht, mit einer Ressource zu interagieren, für die kein Emulator ausgeführt wird, schlägt dieser Code fehl. |
Wir empfehlen, nach Möglichkeit Demoprojekte zu verwenden. Die wichtigsten Vorteile:
- Einfachere Einrichtung, da Sie die Emulatoren ausführen können, ohne ein Firebase-Projekt erstellen zu müssen
- Höhere Sicherheit, da bei versehentlichem Aufrufen nicht emulierter (Produktions-)Ressourcen durch Ihren Code keine Datenänderung, Nutzung und Abrechnung erfolgt.
- Bessere Offlineunterstützung, da Sie nicht auf das Internet zugreifen müssen, um Ihre SDK-Konfiguration herunterzuladen.
App für die Kommunikation mit dem Emulator instrumentieren
Android-, iOS- und Web-SDKs
Richten Sie Ihre In-App-Konfiguration oder Testklassen so ein, dass sie mit dem Authentication-Emulator interagieren.
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");
Web
const auth = firebase.auth(); auth.useEmulator("http://127.0.0.1:9099");
Für das Erstellen von Prototypen und das Testen von Interaktionen zwischen Authentication und Cloud Functions oder Firebase Security Rules für Cloud Firestore oder Realtime Database ist keine zusätzliche Einrichtung erforderlich. Wenn der Authentication-Emulator konfiguriert ist und andere Emulatoren ausgeführt werden, arbeiten sie automatisch zusammen.
Admin SDK Sek.
Die Firebase Admin SDKs stellen automatisch eine Verbindung zum Authentication-Emulator her, wenn die Umgebungsvariable FIREBASE_AUTH_EMULATOR_HOST
festgelegt ist.
export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"
Der Cloud Functions-Emulator erkennt den Authentication-Emulator automatisch. Sie können diesen Schritt also überspringen, wenn Sie Integrationen zwischen Cloud Functions- und Authentication-Emulatoren testen. Die Umgebungsvariable wird automatisch für Admin SDK in Cloud Functions festgelegt.
Wenn die Umgebungsvariable festgelegt ist, akzeptieren Firebase Admin SDKs unsignierte ID-Tokens und Sitzungscookies, die vom Authentication-Emulator (über die Methoden verifyIdToken
bzw. createSessionCookie
) ausgestellt wurden, um die lokale Entwicklung und das Testen zu erleichtern. Achten Sie darauf, die Umgebungsvariable nicht in der Produktionsumgebung festzulegen.
Wenn Ihr Admin SDK-Code eine Verbindung zu einem freigegebenen Emulator herstellen soll, der in einer anderen Umgebung ausgeführt wird, müssen Sie dieselbe Projekt-ID angeben, die Sie mit der Firebase-CLI festgelegt haben. Sie können eine Projekt-ID direkt an initializeApp
übergeben oder die Umgebungsvariable GCLOUD_PROJECT
festlegen.
Node.js Admin SDK
admin.initializeApp({ projectId: "your-project-id" });
Umgebungsvariable
export GCLOUD_PROJECT="your-project-id"
ID-Tokens
Aus Sicherheitsgründen gibt der Authentication-Emulator nicht signierte ID-Tokens aus, die nur von anderen Firebase-Emulatoren oder dem Firebase Admin SDK akzeptiert werden, wenn sie konfiguriert sind. Diese Tokens werden von Firebase-Produktionsdiensten oder dem Firebase Admin SDK, das im Produktionsmodus ausgeführt wird (z.B. das Standardverhalten ohne die oben beschriebenen Einrichtungsschritte), abgelehnt.
Emulator starten
Sie können den Authentication-Emulator interaktiv über die Emulator Suite UI und nicht interaktiv über die lokale REST-Schnittstelle verwenden. In den folgenden Abschnitten werden interaktive und nicht interaktive Anwendungsfälle behandelt.
Führen Sie Folgendes aus, um den Authentication-Emulator, seine REST-Schnittstelle und die Emulator Suite UI zu starten:
firebase emulators:start
Emulierte E‑Mail-Adresse, E‑Mail-Link und anonyme Authentifizierung
Bei der anonymen Authentifizierung kann Ihre App die Anmeldelogik für Ihre Plattform (iOS, Android, Web) verwenden.
Für die E-Mail-/Passwort-Authentifizierung können Sie mit dem Prototyping beginnen, indem Sie Nutzerkonten über Authentication-SDK-Methoden oder über die Emulator Suite UI in der Authentication-Emulation hinzufügen.
- Klicken Sie in der Emulator Suite UI auf den Tab Authentifizierung.
- Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
- Folgen Sie dem Assistenten zum Erstellen von Nutzerkonten und füllen Sie die Felder für die E-Mail-Authentifizierung aus.
Nachdem Sie einen Testnutzer erstellt haben, kann sich dieser in Ihrer App mit der SDK-Logik für Ihre Plattform (iOS, Android, Web) an- und abmelden.
Beim Testen der E-Mail-Bestätigung/Anmeldung mit E-Mail-Link-Abläufen gibt der Emulator eine URL im Terminal aus, in dem firebase emulators:start
ausgeführt wurde.
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
Fügen Sie den Link in Ihren Browser ein, um das Bestätigungsereignis zu simulieren und zu prüfen, ob die Bestätigung erfolgreich war.
{
"authEmulator": {
"success": "The email has been successfully verified.",
"email": "customer@example.com"
}
}
Beim Testen von Passwortzurücksetzungen gibt der Emulator eine ähnliche URL mit dem Parameter newPassword (den Sie nach Bedarf ändern können) im Terminal aus.
http://127.0.0.1:9099/emulator/action?mode=resetPassword&oobCode=XYZ!23&apiKey=fake-api-key&newPassword=YOUR_NEW_PASSWORD
Nicht interaktive Tests
Anstatt Emulator Suite UI oder Clientcode zum Verwalten von Nutzerkonten mit E-Mail-Adresse und Passwort zu verwenden, können Sie Testeinrichtungsskripts schreiben, die REST APIs aufrufen, um Nutzerkonten zu erstellen und zu löschen und Out-of-Band-E-Mail-Bestätigungscodes abzurufen, um die E-Mail-Bestätigungs-URL des Emulators zu füllen. Dadurch bleiben Plattform- und Testcode getrennt und Sie können nicht interaktiv testen.
Bei nicht interaktiven Testläufen für E-Mail-Adresse und Passwort sieht die typische Reihenfolge so aus:
- Erstellen Sie Nutzer mit dem Authentication-REST-Endpunkt „signUp“.
- Melden Sie Nutzer mit den E-Mail-Adressen und Passwörtern an, um Tests durchzuführen.
- Wenn für Ihre Tests zutreffend, rufen Sie verfügbare Out-of-Band-E-Mail-Bestätigungscodes über den emulator-specific REST endpoint ab.
- Löschen Sie Nutzerdatensätze mit dem emulator-specific REST endpoint (emulatorspezifischer REST-Endpunkt) zum Löschen von Daten.
Emulierte Telefon-/SMS-Authentifizierung
Für die Telefonauthentifizierung unterstützt der Auth-Emulator Folgendes nicht:
- reCAPTCHA- und APN-Abläufe. Wenn die Client-SDKs für die Interaktion mit dem Emulator konfiguriert sind, werden diese Bestätigungsmethoden auf ähnliche Weise wie bei Integrationstests deaktiviert (iOS, Android, Web).
- Testen Sie Telefonnummern mit Codes, die in der Firebase-Konsole vorkonfiguriert sind.
Ansonsten ist der Ablauf der Telefon-/SMS-Authentifizierung im Hinblick auf den Clientcode identisch mit dem für die Produktion beschriebenen Ablauf (iOS, Android, Web).
Emulator Suite UI verwenden:
- Klicken Sie in der Emulator Suite UI auf den Tab Authentifizierung.
- Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
- Folgen Sie dem Assistenten zum Erstellen von Nutzerkonten und füllen Sie die Felder für die Telefonauthentifizierung aus.
Bei der Telefonauthentifizierung löst der Emulator jedoch KEINE Zustellung von SMS aus, da die Kontaktaufnahme mit einem Mobilfunkanbieter nicht im Umfang enthalten und für lokale Tests nicht geeignet ist. Stattdessen gibt der Emulator den Code aus, der per SMS an dasselbe Terminal gesendet worden wäre, auf dem Sie firebase emulators:start
ausgeführt haben. Geben Sie diesen Code in die App ein, um zu simulieren, dass Nutzer ihre SMS-Nachrichten prüfen.
Nicht interaktive Tests
Verwenden Sie für nicht interaktive Tests der Telefonauthentifizierung die Authentication-Emulator-REST API, um verfügbare SMS-Codes abzurufen. Der Code ist jedes Mal anders, wenn Sie den Ablauf starten.
Der typische Ablauf sieht so aus:
- Rufen Sie die Plattform
signInWithPhoneNumber
auf, um den Bestätigungsprozess zu starten. - Rufen Sie den Bestätigungscode über den emulator-specific REST endpoint ab.
- Rufen Sie
confirmationResult.confirm(code)
wie gewohnt mit dem Bestätigungscode an.
Multi-Faktor-Authentifizierung per SMS
Der Authentication-Emulator unterstützt das Prototyping und Testen der SMS-MFA-Abläufe (Multi-Faktor-Authentifizierung), die in der Produktion für iOS, Android und Web verfügbar sind.
Wenn Sie dem Emulator einen Testnutzer hinzufügen, können Sie die MFA aktivieren und eine oder mehrere Telefonnummern konfigurieren, an die SMS mit dem zweiten Faktor gesendet werden. Meldungen werden im selben Terminal ausgegeben, in dem Sie firebase emulators:start
ausgeführt haben, und sind über die REST-Schnittstelle verfügbar.
Emulierte Authentifizierung über einen externen Identitätsanbieter (IdP)
Mit dem Authentication-Emulator können Sie viele Drittanbieter-Authentifizierungsabläufe in Ihren iOS-, Android- oder Web-Apps testen, ohne Änderungen am Produktionscode vornehmen zu müssen. Beispiele für Authentifizierungsabläufe finden Sie in der Dokumentation für verschiedene Kombinationen von Anbietern und Plattformen, die Sie in Ihrer App verwenden können.
Grundsätzlich haben Sie zwei Möglichkeiten, sich mit dem Firebase SDK zu authentifizieren:
- In Ihrer App wird der gesamte Prozess vom SDK übernommen, einschließlich aller Interaktionen mit Drittanbieter-IDP-Anbietern zum Abrufen von Anmeldedaten.
- Ihre App ruft Anmeldedaten manuell von einem Drittanbieter mithilfe des SDK dieses Anbieters ab und übergibt diese Anmeldedaten an das Authentication SDK.
Sehen Sie sich noch einmal den Dokumentationslink oben an und machen Sie sich mit dem gewünschten Ablauf vertraut – Firebase SDK-verwaltet oder manueller Abruf von Anmeldedaten. Der Authentication-Emulator unterstützt das Testen beider Ansätze.
Firebase SDK-basierte IDP-Abläufe testen
Wenn in Ihrer App ein End-to-End-Ablauf des Firebase SDK verwendet wird, z. B. OAuthProvider
für die Anmeldung mit Microsoft, GitHub oder Yahoo, wird für interaktive Tests im Authentication-Emulator eine lokale Version der entsprechenden Anmeldeseite bereitgestellt. So können Sie die Authentifizierung über Web-Apps testen, die die Methode signinWithPopup
oder signInWithRedirect
aufrufen. Diese lokal bereitgestellte Anmeldeseite wird auch in mobilen Apps angezeigt, die von der Webview-Bibliothek Ihrer Plattform gerendert werden.
Der Emulator erstellt bei Bedarf Mock-Nutzerkonten und ‑Anmeldedaten von Drittanbietern, während die Abläufe durchlaufen werden.
IDP-Abläufe mit manuellem Abrufen von Anmeldedaten testen
Wenn Sie die manuelle Anmeldung verwenden und die signInWithCredentials
-Methode Ihrer Plattform aufrufen, fordert Ihre App wie gewohnt die Anmeldung über einen Drittanbieter an und ruft die Anmeldedaten des Drittanbieters ab.
Der Emulator unterstützt die signInWithCredential
-Authentifizierung nur für Anmeldedaten, die von Google Sign-In, Apple und anderen Anbietern abgerufen werden, die ID-Tokens verwenden, die als JSON Web Tokens (JWTs) implementiert sind. Zugriffstokens (z.B. von Facebook oder Twitter, die keine JWTs sind) werden nicht unterstützt. Im nächsten Abschnitt wird eine Alternative für diese Fälle beschrieben.
Nicht interaktive Tests
Ein Ansatz für nicht interaktive Tests besteht darin, Nutzerklicks auf der vom Emulator bereitgestellten Anmeldeseite zu automatisieren. Verwenden Sie für Web-Apps eine Steuerungsschnittstelle wie WebDriver. Verwenden Sie für Mobilgeräte die UI-Testtools Ihrer Plattform, z. B. Espresso oder Xcode.
Alternativ können Sie Ihren Code so aktualisieren, dass signInWithCredential
verwendet wird (z.B. in einem Codezweig), und einen Token-Authentifizierungsablauf mit Mock-ID-Tokens für Konten anstelle von echten Anmeldedaten verwenden.
- Verändern Sie den Teil Ihres Codes, der ID-Tokens vom IDP abruft, oder kommentieren Sie ihn aus. So müssen Sie bei Ihren Tests keine echten Nutzernamen und Passwörter eingeben und Ihre Tests unterliegen nicht den API-Kontingenten und Ratenbeschränkungen des IDP.
- Zweitens: Verwenden Sie anstelle des Tokens für
signInWithCredential
einen Literal-JSON-String. Wenn Sie das Web-SDK als Beispiel verwenden, können Sie den Code so ändern:
firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
'{"sub": "abc123", "email": "foo@example.com", "email_verified": true}'
));
Bei Verwendung mit dem Emulator wird mit diesem Code ein Nutzer mit der E‑Mail-Adresse foo@example.com
bei Google authentifiziert. Das Unterfeld kann als Primärschlüssel betrachtet werden, der in einen beliebigen String geändert werden kann, um die Anmeldung verschiedener Nutzer zu simulieren. Sie können firebase.auth.GoogleAuthProvider
beispielsweise durch new firebase.auth.OAuthProvider('yahoo.com')
oder eine andere Anbieter-ID ersetzen, die Sie simulieren möchten.
Emulierte benutzerdefinierte Token-Authentifizierung
Der Authentication-Emulator verarbeitet die Authentifizierung mit benutzerdefinierten JSON-Web-Tokens über Aufrufe der Methode signInWithCustomToken
auf unterstützten Plattformen, wie in der Dokumentation zur Produktionsumgebung für Authentication beschrieben.
Unterschiede zwischen dem Authentication-Emulator und der Produktion
Der Firebase-Emulator für Authentication simuliert viele Funktionen des Produktionsprodukts. Da jedoch jedes Authentifizierungssystem stark auf Sicherheit auf mehreren Ebenen (Gerät, Drittanbieter, Firebase usw.) beruht, ist es für den Emulator schwierig, alle Abläufe richtig nachzubilden.
Cloud IAM
Die Firebase Emulator Suite versucht nicht, IAM-bezogenes Verhalten für die Ausführung zu replizieren oder zu berücksichtigen. Emulatoren halten sich an die bereitgestellten Firebase-Sicherheitsregeln. In Situationen, in denen normalerweise IAM verwendet würde, z. B. zum Festlegen des Dienstkontos und damit der Berechtigungen für den Aufruf von Cloud Functions, ist der Emulator jedoch nicht konfigurierbar. Er verwendet das global verfügbare Konto auf Ihrem Entwicklercomputer, ähnlich wie beim direkten Ausführen eines lokalen Skripts.
Anmeldung über E‑Mail-Link auf Mobilgeräten
Da die Anmeldung über E‑Mail-Links auf mobilen Plattformen auf Firebase Dynamic Links basiert, werden alle entsprechenden Links stattdessen auf der (mobilen) Webplattform geöffnet.
Anmeldung über Drittanbieter
Bei Anmeldevorgängen von Drittanbietern stützt sich Firebase Authentication auf sichere Anmeldedaten von Drittanbietern wie Twitter und GitHub.
Echte Anmeldedaten von OpenID Connect-Anbietern wie Google und Apple werden vom Authentication-Emulator akzeptiert. Anmeldedaten von Nicht-OpenID Connect-Anbietern werden nicht unterstützt.
Anmeldung per E-Mail / SMS
In Produktions-Apps umfassen E‑Mail- und SMS-Anmeldeabläufe einen asynchronen Vorgang, bei dem der Nutzer eine empfangene Nachricht prüft und einen Anmeldecode in eine Anmeldeschnittstelle eingibt. Der Authentication-Emulator sendet keine E‑Mails oder SMS-Nachrichten. Wie oben beschrieben, werden jedoch Anmeldecodes generiert und zur Verwendung bei Tests im Terminal ausgegeben.
Im Emulator können keine Test-Telefonnummern mit festen Anmeldecodes definiert werden, wie es über die Firebase-Konsole möglich ist.
Benutzerdefinierte Tokenauthentifizierung
Der Authentication-Emulator validiert die Signatur oder das Ablaufdatum von benutzerdefinierten Tokens nicht. So können Sie manuell erstellte Tokens verwenden und Tokens in Prototyping- und Testszenarien unbegrenzt wiederverwenden.
Ratenbegrenzung / Schutz vor Missbrauch
Der Authentication-Emulator repliziert keine Ratenbegrenzungen oder Anti-Abuse-Funktionen für die Produktion.
Blockierfunktionen
In der Produktionsumgebung werden Nutzer einmal in den Speicher geschrieben, nachdem sowohl das beforeCreate
- als auch das beforeSignIn
-Ereignis ausgelöst wurden. Aufgrund technischer Einschränkungen schreibt der Authentication-Emulator jedoch zweimal in den Speicher: einmal nach der Nutzererstellung und einmal nach der Anmeldung. Das bedeutet, dass Sie für neue Nutzer getAuth().getUser()
in beforeSignIn
im Authentication-Emulator erfolgreich aufrufen können, in der Produktion jedoch ein Fehler auftritt.
Und jetzt?
Eine Auswahl an Videos und detaillierten Beispielen finden Sie in der Playlist zum Training von Firebase Emulators.
Da ausgelöste Funktionen eine typische Integration mit Authentication sind, finden Sie weitere Informationen zum Cloud Functions for Firebase-Emulator unter Funktionen lokal ausführen.