App mit dem Authentication Emulator verbinden

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

In diesem Thema wird davon ausgegangen, dass Sie bereits mit der Entwicklung von Firebase Authentication-Lösungen für die Produktion vertraut sind. Lesen Sie bei Bedarf die Dokumentation zur Kombination aus Plattform und Authentifizierungstechnik.

Was kann ich mit dem Authentication-Emulator tun?

Der Authentication-Emulator bietet eine High-Fidelity-Lokalisierung der Firebase Authentication-Dienste und bietet viele der Funktionen, die in der Produktionsversion von Firebase Authentication verfügbar sind. In Kombination mit den Firebase SDKs für Apple-Plattformen, Android und Web können Sie mit dem Emulator Folgendes tun:

  • Emulierte Nutzerkonten erstellen, aktualisieren und verwalten, um E-Mail-Adresse/Passwort, Telefonnummer/SMS, SMS-Multi-Faktor-Authentifizierung und Authentifizierung durch Drittanbieter (z.B. Google) zu testen
  • Emulierte Nutzer ansehen und bearbeiten
  • Prototyping benutzerdefinierter Token-Authentifizierungssysteme
  • Prüfen Sie die authentifizierungsbezogenen Meldungen auf dem Tab „Emulator UI Logs“.

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 in der Befehlszeile 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 realen Firebase-Projekten und Demoprojekten.

Projekttyp Funktionen Mit Emulatoren verwenden
Real

Ein echtes Firebase-Projekt ist ein Projekt, das Sie erstellt und konfiguriert haben, höchstwahrscheinlich über die Firebase Console.

Echte Projekte haben Liveressourcen wie Datenbankinstanzen, Speicher-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 eines oder alle unterstützten Produkte ausführen.

Bei Produkten, die Sie nicht emulieren, interagieren Ihre Apps und Ihr Code mit der Live-Ressource (Datenbankinstanz, Speicher-Bucket, Funktion usw.).

Demo

Ein Demo-Firebase-Projekt hat keine echte Firebase-Konfiguration und keine Liveressourcen. Normalerweise wird über Codelabs oder andere Tutorials auf diese Projekte zugegriffen.

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

Wenn Sie mit Demo-Firebase-Projekten 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
  • Erhöhte Sicherheit, da für den Fall, dass Ihr Code versehentlich nicht emulierte (Produktions-)Ressourcen aufruft, keine Chance auf Datenänderungen, -nutzung und -abrechnung besteht
  • Bessere Offlineunterstützung, da kein Zugriff auf das Internet erforderlich ist, um die SDK-Konfiguration herunterzuladen.

App so instrumentieren, dass sie mit dem Emulator kommuniziert

Android-, iOS- und Web-SDKs

Richten Sie Ihre In-App-Konfigurations- oder Testklassen so ein, dass sie mit dem Authentication-Emulator interagieren.

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

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, 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 automatisch den Authentication-Emulator. Sie können diesen Schritt also überspringen, wenn Sie Integrationen zwischen Cloud Functions- und Authentication-Emulatoren testen. Die Umgebungsvariable wird automatisch für die Admin SDK in Cloud Functions festgelegt.

Wenn die Umgebungsvariable festgelegt ist, akzeptieren Firebase Admin SDKs signaturlose ID-Tokens und Sitzungscookies, die vom Authentication-Emulator (über die Methoden verifyIdToken bzw. createSessionCookie) ausgestellt wurden, um die lokale Entwicklung und Tests zu erleichtern. Achten Sie darauf, dass die Umgebungsvariable nicht in der Produktion festgelegt wird.

Wenn Sie mit dem Admin SDK-Code eine Verbindung zu einem freigegebenen Emulator herstellen möchten, der in einer anderen Umgebung ausgeführt wird, müssen Sie dieselbe Projekt-ID angeben, die Sie über die 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 unsignierte ID-Tokens aus, die nur von anderen Firebase-Emulatoren oder dem Firebase Admin SDK akzeptiert werden, wenn es konfiguriert ist. Diese Tokens werden von Firebase-Produktionsdiensten oder dem Firebase Admin SDK, die im Produktionsmodus ausgeführt werden (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

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 dem Authentication-Emulator über die Authentication SDK-Methoden oder über die Emulator Suite UI Nutzerkonten aus Ihrer App hinzufügen.

  1. Klicken Sie in der Emulator Suite UI auf den Tab Authentifizierung.
  2. Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
  3. 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 Ihre App den Nutzer mit der SDK-Logik für Ihre Plattform (iOS, Android, Web) anmelden und abmelden.

Zum Testen der E-Mail-Bestätigung/Anmeldung über E-Mail-Links druckt der Emulator eine URL in das Terminal, 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 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 an das Terminal aus, einschließlich des Parameters newPassword, den Sie bei Bedarf ändern können.

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 den Emulator Suite UI- oder Clientcode zum Verwalten von E-Mail-/Passwort-Nutzerkonten zu verwenden, können Sie Testeinrichtungsscripts schreiben, die REST APIs aufrufen, um Nutzerkonten zu erstellen und zu löschen, und Out-of-Band-E-Mail-Bestätigungscodes abrufen, um die E-Mail-Bestätigungs-URL des Emulators zu füllen. So bleiben Plattform- und Testcode getrennt und Sie können nicht interaktiv testen.

Bei nicht interaktiven Testabläufen für E-Mails und Passwörter sieht der Ablauf normalerweise so aus.

  1. Erstelle Nutzer mit dem Authentication REST-Endpunkt „signUp“.
  2. Melden Sie Nutzer mit den E-Mail-Adressen und Passwörtern an, um Tests durchzuführen.
  3. Rufen Sie gegebenenfalls die verfügbaren Out-of-Band-E-Mail-Bestätigungscodes vom emulatorspezifischen REST-Endpunkt ab.
  4. Löschen Sie Nutzerdaten mit dem emulatorspezifischen REST-Endpunkt.

Authentifizierung per emuliertem Smartphone/SMS

Für die Telefonauthentifizierung unterstützt der Auth-Emulator Folgendes nicht:

  • reCAPTCHA- und APN-Abläufe Nachdem Client-SDKs für die Interaktion mit dem Emulator konfiguriert wurden, werden diese Bestätigungsmethoden ähnlich wie für Integrationstests deaktiviert (iOS, Android, Web).
  • Testen Sie Telefonnummern mit Codes, die in der Firebase-Konsole vorab konfiguriert wurden.

Ansonsten entspricht der Ablauf der Telefon-/SMS-Authentifizierung im Clientcode dem für die Produktion beschriebenen Ablauf (iOS, Android, Web).

Mit dem Emulator Suite UI:

  1. Klicken Sie in der Emulator Suite UI auf den Tab Authentifizierung.
  2. Klicken Sie auf die Schaltfläche Nutzer hinzufügen.
  3. Folgen Sie dem Assistenten zum Erstellen eines Nutzerkontos und füllen Sie die Felder für die Telefonauthentifizierung aus.

Bei der Authentifizierung per Smartphone löst der Emulator jedoch KEINE Zustellung von SMS aus, da die Kontaktaufnahme mit einem Mobilfunkanbieter nicht in den Zuständigkeitsbereich fällt 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, an dem Sie firebase emulators:start ausgeführt haben. Geben Sie diesen Code in die App ein, um zu simulieren, dass Nutzer ihre SMS abrufen.

Nicht interaktive Tests

Für nicht interaktive Tests der Telefonauthentifizierung können Sie die Authentication-Emulator-REST API verwenden, um verfügbare SMS-Codes abzurufen. Hinweis: Der Code ist jedes Mal, wenn Sie den Ablauf starten, unterschiedlich.

Der typische Ablauf sieht so aus:

  1. Rufe die Plattform signInWithPhoneNumber auf, um den Bestätigungsprozess zu starten.
  2. Rufen Sie den Bestätigungscode über den emulatorspezifischen REST-Endpunkt ab.
  3. Rufen Sie wie gewohnt confirmationResult.confirm(code) mit dem Bestätigungscode an.

Multi-Faktor-Authentifizierung per SMS

Der Authentication-Emulator unterstützt das Prototyping und das Testen der in der Produktion verfügbaren Abläufe für die Multi-Faktor-Authentifizierung von SMS für iOS, Android und das Web.

Wenn Sie dem Emulator einen Testnutzer hinzufügen, können Sie die Multi-Faktor-Authentifizierung aktivieren und eine oder mehrere Telefonnummern konfigurieren, an die SMS mit dem zweiten Faktor gesendet werden. Die Meldungen werden im selben Terminal ausgegeben, in dem Sie firebase emulators:start ausgeführt haben, und sind über die REST-Benutzeroberfläche verfügbar.

Emulierte Authentifizierung über einen externen Identitätsanbieter (Identity Provider, IdP)

Mit dem Authentication-Emulator können Sie viele Authentifizierungsabläufe von Drittanbietern in Ihren iOS-, Android- oder Webanwendungen testen, ohne den Produktionscode ändern 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:

  • Über Ihre App übernimmt das SDK den gesamten Prozess, einschließlich aller Interaktionen mit externen IdP-Anbietern zum Abrufen der Anmeldedaten.
  • Ihre App ruft manuell Anmeldedaten von einem Drittanbieter über das SDK dieses Anbieters ab und gibt diese Anmeldedaten an das Authentication SDK weiter.

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

Firebase SDK-gestützte IDP-Abläufe testen

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

Der Emulator erstellt nach Bedarf simulierte Drittanbieter-Nutzerkonten und -Anmeldedaten im weiteren Verlauf.

IdP-Abläufe mit manuellem Abrufen von Anmeldedaten testen

Wenn Sie „manuelle“ Anmeldemethoden verwenden und die signInWithCredentials-Methode Ihrer Plattform aufrufen, fordert Ihre App wie gewohnt eine echte Anmeldung bei einem Drittanbieter an und ruft echte Anmeldedaten des Drittanbieters ab.

Der Emulator unterstützt die signInWithCredential-Authentifizierung nur für Anmeldedaten, die über Google Sign-In, Apple und andere Anbieter 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 erläutert.

Nicht interaktive Tests

Ein Ansatz für nicht interaktive Tests besteht darin, Nutzerklicks auf der Anmeldeseite des Emulators zu automatisieren. Verwenden Sie für Webanwendungen eine Steueroberfläche 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 Mock-ID-Tokens für Konten anstelle echter Anmeldedaten verwenden.

  1. Überarbeiten oder kommentieren Sie den Teil Ihres Codes, der id-Tokens vom IDP abruft. Dadurch müssen Sie während der Tests keine echten Nutzernamen und Passwörter eingeben und Ihre Tests sind nicht von API-Kontingenten und -Geschwindigkeitslimits beim IDP betroffen.
  2. Zweitens: Verwenden Sie einen literalen JSON-String anstelle des Tokens für signInWithCredential. Am Beispiel des Web SDK können Sie den Code so ändern:
firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
  '{"sub": "abc123", "email": "foo@example.com", "email_verified": true}'
));

Bei der Verwendung mit dem Emulator wird mit diesem Code ein Nutzer erfolgreich mit der E-Mail-Adresse foo@example.com bei Google authentifiziert. Stellen Sie sich das untergeordnete Feld als Primärschlüssel vor, 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 Authentifizierung mit benutzerdefiniertem Token

Der Authentication-Emulator verarbeitet die Authentifizierung mit benutzerdefinierten JSON-Webtokens über Aufrufe der signInWithCustomToken-Methode auf unterstützten Plattformen, wie in der Produktionsdokumentation für Authentication beschrieben.

Unterschiede zwischen dem Authentication-Emulator und der Produktion

Der Firebase Authentication-Emulator simuliert viele Funktionen des Produktionsprodukts. Da jedoch jede Art von Authentifizierungssystem auf mehreren Ebenen (Gerät, Drittanbieter, Firebase usw.) in hohem Maße auf Sicherheit angewiesen ist, ist es für den Emulator schwierig, alle Abläufe ordnungsgemäß neu zu erstellen.

Cloud IAM

Die Firebase Emulator Suite versucht nicht, IAM-bezogenes Laufverhalten 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 Cloud Functions, ist der Emulator jedoch nicht konfigurierbar und verwendet das global verfügbare Konto auf Ihrem Entwicklercomputer, ähnlich wie beim direkten Ausführen eines lokalen Scripts.

Da die Anmeldung per E-Mail-Link auf mobilen Plattformen auf Firebase Dynamic Links basiert, werden alle derartigen Links stattdessen auf der (mobilen) Webplattform geöffnet.

Anmeldung über Drittanbieter

Bei der Anmeldung über Drittanbieter benötigt 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 anderen Anbietern als OpenID Connect werden nicht unterstützt.

Anmeldung per E-Mail/SMS

In Produktions-Apps umfassen die Anmeldeabläufe per E-Mail und SMS einen asynchronen Vorgang, bei dem der Nutzer eine empfangene Nachricht überprüft und einen Anmeldecode in eine Anmeldeoberfläche eingibt. Der Authentication-Emulator sendet keine E-Mails oder SMS, generiert wie oben beschrieben jedoch Anmeldecodes und gibt sie an das Terminal aus, um sie für die Tests zu verwenden.

Der Emulator unterstützt nicht die Definition von Testtelefonnummern mit festen Anmeldecodes, 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 selbst erstellte Tokens verwenden und Tokens unbegrenzt in Prototyping- und Test-Szenarien wiederverwenden.

Ratenbegrenzung / Schutz vor Missbrauch

Der Authentication-Emulator repliziert keine Funktionen zur Begrenzung der Produktionsgeschwindigkeit oder zum Schutz vor Missbrauch.

Blockierfunktionen

In der Produktion werden Nutzer einmal in den Speicher geschrieben, nachdem die Ereignisse beforeCreate und beforeSignIn 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 einen Fehler erhalten.

Und jetzt?