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 gegebenenfalls die Dokumentation für die Kombination aus Plattform und Authentifizierungsmethode.

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 Produktionsumgebung 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 zum Testen der Authentifizierung per E-Mail/Passwort, Telefonnummer/SMS, SMS-Multi-Faktor-Authentifizierung und Authentifizierung über Identitätsanbieter von Drittanbietern (z.B. Google) erstellen, aktualisieren und verwalten
  • Emulierte Nutzer ansehen und bearbeiten
  • Prototypen für benutzerdefinierte Tokenauthentifizierungssysteme
  • Prüfen Sie die authentifizierungsbezogenen Meldungen auf dem Tab „Emulator UI Logs“ (Emulator-UI-Protokolle).

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 echten und Demo-Firebase-Projekten.

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 Firebase-Demoprojekt 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 der 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 zu erstellen
  • Höhere Sicherheit, da bei versehentlichem Aufruf nicht emulierter (Produktions-)Ressourcen durch Ihren Code keine Daten geändert werden und es keine Nutzung und Abrechnung gibt
  • Bessere Offlineunterstützung, da kein Zugriff auf das Internet erforderlich ist, um die SDK-Konfiguration herunterzuladen.

App für die Kommunikation mit dem Emulator instrumentieren

Android-, iOS- und Web-SDKs

So richten Sie Ihre In-App-Konfiguration oder Testklassen ein, damit 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 SDK 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 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, die Umgebungsvariable nicht in der Produktionsumgebung festzulegen.

Wenn Sie möchten, dass Ihr Admin SDK-Code eine Verbindung zu einem freigegebenen Emulator herstellt, 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 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 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 oder 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 eines Nutzerkontos 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 des Zurücksetzens von Passwörtern druckt der Emulator eine ähnliche URL mit dem Parameter newPassword (den Sie bei Bedarf ändern können) in das Terminal.

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 E-Mail- und Passwort-Testabläufen sieht die typische Abfolge so aus:

  1. Erstelle Nutzer mit dem Authentication REST-Endpunkt „signUp“.
  2. Melden Sie die Nutzer mit den E-Mail-Adressen und Passwörtern an, um Tests durchzuführen.
  3. Rufen Sie gegebenenfalls verfügbare 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 vorkonfiguriert sind.

Ansonsten ist der Ablauf der Telefon-/SMS-Authentifizierung in Bezug auf den Clientcode mit dem für die Produktion beschriebenen Ablauf identisch (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 Testen der SMS-Multi-Faktor-Authentifizierung (MFA), die in der Produktion für iOS, Android und Web verfügbar ist.

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

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 haben Sie zwei Möglichkeiten, sich mit dem Firebase SDK zu authentifizieren:

  • In Ihrer App kann das SDK den gesamten Prozess abwickeln, einschließlich aller Interaktionen mit IDP-Anbietern von Drittanbietern zum Abrufen von 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 den Test beider Ansätze.

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

Wenn Ihre App einen End-to-End-Ablauf des Firebase SDK verwendet, z. B. OAuthProvider für die Anmeldung bei Microsoft, GitHub oder Yahoo, wird im Authentication-Emulator für interaktive Tests eine lokale Version der entsprechenden Anmeldeseite bereitgestellt, 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, die von der WebView-Bibliothek Ihrer Plattform gerendert werden.

Der Emulator erstellt nach Bedarf während der Abläufe Mock-Nutzerkonten und -Anmeldedaten von Drittanbietern.

IdP-Abläufe mit manueller Abruf 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 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 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 anstelle des Tokens für signInWithCredential einen JSON-Literal-String. 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}'
));

In Verbindung mit dem Emulator authentifiziert dieser Code einen Nutzer mit der E-Mail-Adresse foo@example.com bei Google. 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 jede Art von Authentifizierungssystem jedoch stark auf Sicherheit auf mehreren Ebenen (Gerät, Drittanbieter, Firebase usw.) angewiesen ist, ist es für den Emulator schwierig, alle Abläufe korrekt nachzubilden.

Cloud IAM

Die Firebase Emulator Suite versucht nicht, IAM-bezogenes Laufverhalten zu replizieren oder zu respektieren. 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 über E-Mail-Links auf mobilen Plattformen auf Firebase Dynamic Links basiert, werden alle diese Links stattdessen auf der (mobilen) Webplattform geöffnet.

Anmeldung über Drittanbieter

Für die Anmeldung über Drittanbieter nutzt 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 aber wie oben beschrieben Anmeldecodes und gibt sie für die Tests an das Terminal aus.

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 nicht die Signatur oder das Ablaufdatum benutzerdefinierter Tokens. So können Sie selbst erstellte Tokens verwenden und Tokens unbegrenzt in Prototyping- und Test-Szenarien wiederverwenden.

Ratenbegrenzung / Missbrauchsprävention

Der Authentication-Emulator repliziert keine Ratenbegrenzungen oder Anti-Missbrauchsfunktionen der Produktion.

Blockierfunktionen

In der Produktion werden Nutzer einmal in den Speicher geschrieben, nachdem sowohl das Ereignis beforeCreate als auch das Ereignis 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 ein Fehler auftritt.

Und jetzt?