App mit dem Authentication Emulator verbinden

Bevor Sie den Authentication Emulator mit Ihrer App verwenden, sollten Sie sich mit dem allgemeinen Firebase Local Emulator Suite Workflow vertraut machen, die Local Emulator Suite installieren und konfigurieren und die CLI-Befehle überprüfen.

In diesem Thema wird davon ausgegangen, dass Sie bereits mit der Entwicklung Firebase Authentication Lösungen für die Produktion vertraut sind. Falls erforderlich, lesen Sie die Dokumentation für Ihre Kombination aus Plattform und Authentifizierungsmethode.

Was kann ich mit dem Authentication Emulator tun?

Der Authentication Emulator bietet eine genaue lokale Emulation von Firebase Authentication Diensten und stellt einen Großteil der Funktionen bereit, die in Produktionsumgebung Firebase Authentication verfügbar sind. In Kombination mit den Firebase SDKs für Apple-Plattformen, Android und Web bietet der Emulator folgende Möglichkeiten:

  • Emulierte Nutzerkonten zum Testen der Authentifizierung mit E‑Mail/Passwort, Telefonnummer/SMS, SMS-Multi-Faktor-Authentifizierung und Authentifizierung über Drittanbieter (z.B. Google) erstellen, aktualisieren und verwalten
  • Emulierte Nutzer ansehen und bearbeiten
  • Benutzerdefinierte Token-Authentifizierungssysteme prototypisieren
  • Authentifizierungsbezogene Nachrichten auf dem Tab „Logs“ der Emulator-UI prüfen

Firebase-Projekt auswählen

Die Firebase Local Emulator Suite emuliert Produkte für ein einzelnes Firebase-Projekt.

Wenn Sie das zu verwendende Projekt auswählen möchten, führen Sie vor dem Starten der Emulatoren im Arbeitsverzeichnis in der CLI firebase use aus. Alternativ können Sie das Flag an jeden Emulator Befehl übergeben.--project

Local Emulator Suite unterstützt die Emulation von echten Firebase-Projekten und Demoprojekten.

Projekttyp Funktionen Mit Emulatoren verwenden
Echt

Ein echtes Firebase-Projekt ist ein Projekt, das Sie erstellt und konfiguriert haben (wahrscheinlich über die Firebase Konsole).

Echte Projekte haben aktive 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 oder alle unterstützten Produkte ausführen.

Für alle Produkte, die Sie nicht emulieren, interagieren Ihre Apps und Ihr Code mit der aktiven Ressource (Datenbankinstanz, Storage-Bucket, Funktion usw.).

Demo

Ein Firebase-Demoprojekt hat keine echte Firebase-Konfiguration und keine aktiven Ressourcen. Auf diese Projekte wird in der Regel über Codelabs oder andere Anleitungen zugegriffen.

Projekt-IDs für Demoprojekte haben das Präfix demo-.

Wenn Sie mit Firebase-Demoprojekten arbeiten, interagieren Ihre Apps und Ihr Code mit Emulatoren nur. Wenn Ihre App versucht, mit einer Ressource für die kein Emulator ausgeführt wird, zu interagieren, schlägt dieser Code fehl.

Wir empfehlen, Demoprojekte nach Möglichkeit zu verwenden. Dies sind 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 von nicht emulierten (Produktions-)Ressourcen durch Ihren Code keine Datenänderungen, Nutzung und Abrechnung erfolgen
  • 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 Prototyping und 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, funktionieren sie automatisch zusammen.

Admin SDKs

Die Firebase Admin SDKs stellen automatisch eine Verbindung zum Authentication Emulator her, wenn die FIREBASE_AUTH_EMULATOR_HOST Umgebungsvariable 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 das Admin SDK in Cloud Functions festgelegt.

Wenn die Umgebungsvariable festgelegt ist, akzeptieren Firebase Admin SDKs unsignierte ID Tokens und Sitzungscookies, die vom Authentication Emulator ausgegeben werden (über die Methoden verifyIdToken und createSessionCookie bzw.), um die lokale Entwicklung und das Testen zu erleichtern. Legen Sie die Umgebungsvariable nicht in der Produktionsumgebung fest.

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.

Admin SDK für Node.js
admin.initializeApp({ projectId: "your-project-id" });
Umgebungsvariable
export GCLOUD_PROJECT="your-project-id"

ID-Tokens

Aus Sicherheitsgründen gibt der Authentication Emulator unsignierte ID-Tokens aus, die nur von anderen Firebase-Emulatoren oder dem Firebase Admin SDK akzeptiert werden, wenn konfiguriert sind. Diese Tokens werden von Firebase-Produktionsdiensten oder dem Firebase Admin SDK im Produktionsmodus abgelehnt (z.B. das Standardverhalten ohne die oben beschriebenen Einrichtungsschritte).

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, die REST-Schnittstelle und die Emulator Suite UI zu starten:

firebase emulators:start

Bei der anonymen Authentifizierung kann Ihre App die Anmeldelogik für Ihre Plattform (iOS, Android, Web) nutzen.

Für die Authentifizierung mit E‑Mail/Passwort können Sie mit dem Prototyping beginnen, indem Sie Nutzerkonten über die Authentication SDK-Methoden oder die Emulator Suite UI zum Authentication Emulator hinzufügen.

  1. Klicken Sie in der Emulator Suite UI auf den Tab Authentication.
  2. Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
  3. Folgen Sie der Anleitung zum Erstellen von Nutzerkonten und füllen Sie die Felder für die E‑Mail-Authentifizierung aus.

Nachdem ein Testnutzer erstellt wurde, kann Ihre App den Nutzer mit der SDK-Logik für Ihre Plattform (iOS, Android, Web) an- und abmelden.

Zum Testen der E‑Mail-Bestätigung/Anmeldung mit E‑Mail-Link-Abläufen gibt der Emulator eine URL an das Terminal aus, auf 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 prüfen Sie, ob die Bestätigung erfolgreich war.

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

Zum Testen von Passwortzurücksetzungen gibt der Emulator eine ähnliche URL mit dem Parameter newPassword (den Sie nach Bedarf ändern können) an das Terminal aus.

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

Nicht interaktives Testen

Anstatt die Emulator Suite UI oder den Clientcode zum Verwalten von E‑Mail-/Passwort Nutzerkonten zu verwenden, können Sie Testeinrichtungsskripts schreiben, die REST APIs aufrufen, um zu erstellen und Nutzerkonten zu löschen und E‑Mail-Bestätigungscodes außerhalb des Bandes abzurufen, um zu füllen die E‑Mail-Bestätigungs-URL des Emulators. So bleiben Plattform- und Testcode getrennt und Sie können nicht interaktiv testen.

Für nicht interaktive E‑Mail- und Passworttestabläufe ist die typische Reihenfolge wie folgt:

  1. Nutzer mit dem Authentication REST-Endpunkt für die Registrierung erstellen.
  2. Nutzer mit den E‑Mail-Adressen und Passwörtern anmelden, um Tests durchzuführen.
  3. Falls für Ihre Tests erforderlich, verfügbare E‑Mail-Bestätigungscodes außerhalb des Bandes vom emulatorspezifischen REST-Endpunkt abrufen.
  4. Nutzerdatensätze mit dem emulatorspezifischen REST-Endpunkt zum Löschen von Daten leeren.

Emulierte Telefon-/SMS-Authentifizierung

Bei der Telefonauthentifizierung unterstützt der Auth-Emulator Folgendes nicht:

  • reCAPTCHA- und APN-Abläufe. Sobald die Interaktion mit dem Emulator konfiguriert ist, deaktivieren Client SDKs diese Bestätigungsmethoden ähnlich wie beim Integrationstest (iOS, Android, Web).
  • Testtelefonnummern mit in der Firebase Konsole vorkonfigurierten Codes.

Ansonsten ist der Telefon-/SMS-Authentifizierungsablauf im Hinblick auf den Clientcode mit dem für die Produktion beschriebenen Ablauf identisch (iOS, Android, Web).

Mit der Emulator Suite UI:

  1. Klicken Sie in der Emulator Suite UI auf den Tab Authentication.
  2. Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
  3. Folgen Sie der Anleitung zum Erstellen von Nutzerkonten und füllen Sie die Felder für die Telefonauthentifizierung aus.

Bei Telefonauthentifizierungsabläufen löst der Emulator jedoch KEINE SMS-Zustellung 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 interaktives Testen

Verwenden Sie für nicht interaktive Tests der Telefonauthentifizierung die Authentication emulator REST API, um verfügbare SMS-Codes abzurufen. Der Code ist bei jedem Start des Ablaufs anders.

Die typische Reihenfolge ist wie folgt:

  1. signInWithPhoneNumber der Plattform aufrufen, um den Bestätigungsprozess zu starten.
  2. Bestätigungscode mit dem emulatorspezifischen REST-Endpunkt abrufen.
  3. confirmationResult.confirm(code) wie gewohnt mit dem Bestätigungscode aufrufen.

Multi-Faktor-Authentifizierung per SMS

Der Authentication Emulator unterstützt das Prototyping und Testen der SMS-Multi-Faktor Authentifizierungsabläufe (MFA), die in der Produktionsumgebung 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-Nachrichten für den zweiten Faktor gesendet werden. Nachrichten werden an dasselbe Terminal ausgegeben, auf dem Sie firebase emulators:start ausgeführt haben, und sind über die REST-Schnittstelle verfügbar.

Emulierte Authentifizierung über Drittanbieter (IdP)

Mit dem Authentication Emulator können Sie viele Authentifizierungsabläufe von Drittanbietern 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.

Im Allgemeinen können Sie das Firebase SDK auf zwei Arten zur Authentifizierung verwenden:

  • Ihre App lässt das SDK den gesamten Prozess von Anfang bis Ende abwickeln, einschließlich aller Interaktionen mit Drittanbietern, um Anmeldedaten abzurufen.
  • Ihre App ruft Anmeldedaten manuell von einem Drittanbieter ab, indem sie das SDK dieses Anbieters verwendet, und übergibt diese Anmeldedaten an das Authentication SDK.

Sehen Sie sich noch einmal den Link zur Dokumentation oben an und machen Sie sich mit dem gewünschten Ablauf vertraut – Firebase SDK-verwalteter oder manueller Abruf von Anmeldedaten. Der Authentication Emulator unterstützt das Testen beider Ansätze.

Firebase SDK-gesteuerte IDP-Abläufe testen

Wenn Ihre App einen beliebigen Firebase SDK-End-to-End-Ablauf verwendet, z. B. OAuthProvider für die Anmeldung mit Microsoft, GitHub oder Yahoo, stellt der Authentication Emulator für interaktive Tests eine lokale Version der entsprechenden Anmeldeseite bereit, damit Sie die Authentifizierung von Web-Apps testen können, die die Methode signinWithPopup oder signInWithRedirect aufrufen. Diese lokal bereitgestellte Anmeldeseite wird auch in mobilen Apps angezeigt, gerendert von der WebView-Bibliothek Ihrer Plattform.

Der Emulator erstellt nach Bedarf Testnutzerkonten und ‑anmeldedaten von Drittanbietern, während die Abläufe ausgeführt werden.

IDP-Abläufe mit manuellem Abruf von Anmeldedaten testen

Wenn Sie manuelle Anmeldemethoden verwenden und die Methode signInWithCredentials 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 Log-in, Apple und anderen Anbietern abgerufen wurden, 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 interaktives Testen

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 Code-Branch), und einen Token-Authentifizierungsablauf mit Test-ID-Tokens für Konten anstelle von echten Anmeldedaten verwenden.

  1. Verbinden Sie den Teil Ihres Codes neu, 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 sind nicht von API-Kontingenten und Ratenbegrenzungen beim IDP betroffen.
  2. Verwenden Sie anstelle des Tokens für signInWithCredential einen Literal-JSON-String. Wenn Sie beispielsweise das Web SDK 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 authentifiziert dieser Code einen Nutzer mit der E‑Mail-Adresse foo@example.com bei Google. Das Feld „sub“ kann als Primärschlüssel betrachtet werden, der in eine beliebige Zeichenfolge geändert werden kann, um die Anmeldung verschiedener Nutzer zu simulieren. Sie können beispielsweise firebase.auth.GoogleAuthProvider 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 mithilfe von Aufrufen der Methode signInWithCustomToken auf unterstützten Plattformen, wie beschrieben in der Produktionsumgebung Authentication Dokumentation.

Unterschiede zwischen dem Authentication Emulator und der Produktionsumgebung

Der Firebase Authentication Emulator simuliert viele Funktionen des Produktions produkts. Da jedoch jede Art von Authentifizierungssystem stark auf Sicherheit auf mehreren Ebenen (Gerät, Drittanbieter, Firebase usw.) basiert, ist es für den Emulator schwierig, alle Abläufe korrekt 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, das Cloud Functions aufruft, und damit der Berechtigungen, ist der Emulator jedoch nicht konfigurierbar und verwendet das global verfügbare Konto auf Ihrem Entwicklercomputer, ähnlich wie beim direkten Ausführen eines lokalen Skripts.

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

Für Anmeldeabläufe über Drittanbieter verwendet Firebase Authentication 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, generiert aber wie oben beschrieben Anmeldecodes und gibt sie an das Terminal aus, um sie zum Testen zu verwenden.

Der Emulator unterstützt nicht die Möglichkeit, Testtelefonnummern mit festen Anmeldecodes zu definieren, wie es über die Firebase Console möglich ist.

Benutzerdefinierte Token-Authentifizierung

Der Authentication Emulator validiert die Signatur oder das Ablaufdatum von benutzerdefinierten Tokens nicht. So können Sie handgefertigte Tokens verwenden und Tokens in Prototyping- und Testszenarien unbegrenzt wiederverwenden.

Ratenbegrenzung / Missbrauchsschutz

Der Authentication Emulator repliziert keine Ratenbegrenzungen oder Missbrauchsschutz funktionen der Produktionsumgebung.

Blockierfunktionen

In der Produktionsumgebung werden Nutzer einmal in den Speicher geschrieben, nachdem sowohl das Ereignis beforeCreate als auch das Ereignis beforeSignIn ausgelöst wurde. Aus technischen Gründen 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 in der Authentication erfolgreich aufrufen können, in der Produktionsumgebung jedoch ein Fehler auftritt.

Nächste Schritte