Firebase-tools: Firebase-Authentifizierungsemulator zur Emulator-Suite hinzufügen

@vladimirdjurdjevic danke, dass

Aber wir wollen auf jeden Fall den von Ihnen erwähnten End-to-End-Use-Case ermöglichen!

Frage: Würden Sie es nützlich finden, wenn es eine Bibliothek gäbe, die es Ihnen ermöglicht, einen Firebase-Benutzer lokal für die Verwendung mit den Emulatoren zu verspotten? Etwas wie:

firebase.auth().setEmulatedUser({
   uid: 'abc123',
   // ...
});

@samtstern Würde der Aufruf von setEmulatedUser() auch functions.auth.user().onCreate() emulierte Cloud-Funktionen auslösen? Wenn ja, wäre das sehr nützlich.

@samtstern Das würde sicherlich einigen Testszenarien helfen, erfordert aber immer noch eine echte Instanz für die Entwicklung. Meine Idee ist es zu vermeiden, mehrere Firebase-Projekte für verschiedene Umgebungen zu erstellen und lokal entwickeln zu können (offline vielleicht). Ein anderer Ansatz wäre, unterschiedliche Umgebungen für Dienste zu unterstützen. Wenn wir unterschiedliche Umgebungen für beispielsweise Firestore und Auth unter demselben Projekt erstellen könnten, würde dies viele Probleme lösen. Ich weiß, dass ich Projekte pro Umgebung erstellen kann, aber das ist eine echte Nervensäge. Jede Umgebung konfigurieren, Daten replizieren usw. Idealerweise möchte ich in der Lage sein, ein Firebase-Projekt zu erstellen, und wenn ich Dummy-Daten für manuelle Tests benötige, könnte ich einfach eine Staging-Umgebung für Firestore erstellen und dort Daten hochladen.

@noelmansour gute Frage! Das wäre nicht allzu schwer, wir würden wahrscheinlich zwei verschiedene Aufrufe wie signInAsEmulatedUser und signUpAsEmulatedUser wobei nur der zweite die Funktion auslöst.

@vladimirdjurdjevic stimme

Frage: Würden Sie es nützlich finden, wenn es eine Bibliothek gäbe, die es Ihnen ermöglicht, einen Firebase-Benutzer lokal für die Verwendung mit den Emulatoren zu verspotten?

Wirklich nützlich, würde sehr helfen.
Im Moment setze ich nur die Regelfunktion auf true den angemeldeten Benutzer jedes Mal überprüft, wenn ich etwas lokal testen muss.

Ja das wäre unglaublich nützlich

Ich möchte auch functions.auth.user().onCreate() Unit-Tests durchführen. Ich nehme an, die beste Problemumgehung besteht im Moment darin, die Callback-Funktion zu exportieren, die an onCreate und ihr ein gefälschtes user Objekt bereitzustellen.

Für diese Art von Unit-Tests schauen Sie sich den Firebase-Functions-Test an
Bibliothek, die Ihnen hilft, Ihre Funktionshandler mit Scheindaten aufzurufen.

Am So, 13. Oktober 2019, 05:44 Uhr schrieb Daniel K. [email protected] :

Ich möchte auch Funktionen.auth.user().onCreate() Unit-Tests durchführen. ich
Angenommen, im Moment ist die beste Problemumgehung im Wesentlichen der Export von Rückrufen
-Funktion onCreate übergeben und gefälschtes Benutzerobjekt an sie übergeben.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/1677?email_source=notifications&email_token=ACATB2QYJLX2LNVDTWJV25TQOMJ4VA5CNFSM4I27PTFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DNSMV2HZ154
oder abmelden
https://github.com/notifications/unsubscribe-auth/ACATB2SO3IR6UB73F4EMZPTQOMJ4VANCNFSM4I27PTFA
.

@samtstern Das funktioniert tatsächlich zusammen mit dem Firestore-Emulator? Aufgrund dessen habe ich den Eindruck, dass es für einen anderen Zweck ist.

https://firebase.google.com/docs/functions/unit-testing#initializing

Ich möchte sicherlich keinen Online-Modus für Unit-Tests, das wäre ein Langweiler. Und ich bin mir nicht sicher, ob ich durch "Stubbing" auf den Firestore-Emulator zugreifen kann.

@ FredyC danke für den Hinweis auf diese Dokumente. Die verwendeten Wörter sind verwirrend, da die "Modi" kein Schalter sind, den Sie aktivieren können, sondern nur Strategien beschreiben, die Sie ergreifen können.

Wenn Sie den Firestore-Emulator neben Ihren Komponententests starten, könnte Ihr Code definitiv eine Verbindung dazu herstellen. Wenn Sie die Umgebungsvariable FIRESTORE_EMULATOR_HOST festlegen, verbindet sich das Firebase Admin SDK automatisch mit dem Firestore-Emulator ( firebase emulators:exec erledigt dies für Sie).

@samtstern Ich habe immer noch Probleme, Punkte zu verbinden und wie soll mir das alles helfen, functions.auth.user().onCreate() zu testen? Ich meine, es ist großartig, dass Funktionen anstelle einer Produktionsversion mit dem Emulator verbunden werden, aber das ist nur Firestore, oder? Wie rufe ich die Benutzererstellung aus Tests auf, um den Funktionscode tatsächlich zu aktivieren?

Es scheint eine kryptische Methode makeUserRecord im erwähnten Firebase-Functions-Test zu geben, aber es macht nicht viel Sinn, wie das funktionieren oder wie man es tatsächlich verwendet.

Ich habe versucht, auth.createUserWithEmailAndPassword() aus dem @firebase/testing Paket aufzurufen, aber das beschwert sich über einen ungültigen API-Schlüssel, daher gehe ich davon aus, dass es nur mit der Online-Version funktionieren würde.

Wenn ich org nach der von Ihnen erwähnten env-Variablen

Ich habe auch die https://github.com/firebase/functions-samples durchsucht, aber dort keine Beispiele für Unit-Tests gefunden.

Kannst du das bitte etwas nachvollziehen? :)

Ich habe auch einen anderen Fall, etwas entgegengesetzt, wo der Cloud-Funktionscode den admin.auth().getUserByEmail() Aufruf verwendet. Überraschenderweise endet es nicht mit dem Fehler, aber ich habe keine Ahnung, wie ich diesen Benutzer erstellen würde, damit er zurückgegeben werden kann. Außer natürlich das ganze Admin-Modul zu verspotten, aber das ist verrückt :)

@samtstern Sorry für die Verspätung. Wenn ich echte Instanz sage, meine ich echte Instanz: D Idealerweise möchte ich nur die Konfiguration in meiner Winkelumgebungsdatei für die Entwicklung austauschen und weiterhin Authentifizierungsfunktionen implementieren, wie zum Beispiel meine App mit einer echten API spricht, aber tatsächlich läuft der Emulator auf meinem Maschine, und ich kann es offline tun. Jetzt verstehe ich die Herausforderungen zum Beispiel beim Senden von SMS. Es wäre albern zu erwarten, dass der Emulator echte SMS an mein Telefon sendet, aber Sie könnten sie vielleicht einfach auf der Konsole ausdrucken (den Inhalt der SMS, die gesendet werden würde). Es ist wahrscheinlich mehr Ärger als der Wert damit. Deshalb denke ich, dass die Unterstützung mehrerer Umgebungen pro Projekt die Dinge viel besser machen könnte. Es dauert zu lange, Konfigurationen zwischen mehreren Projekten für verschiedene Umgebungen zu replizieren. Und auch die Verwaltung mehrerer Dienstkonten für Skripte, um Daten in verschiedene Firestore-Projekte zu übertragen, ist mühsam. Deshalb habe ich gelehrt, dass wir, wenn wir eine ganze Firebase-Plattform emuliert hätten, diese für jede Nicht-Produktionsumgebung verwenden und nur ein echtes Firebase-Projekt verwalten könnten. Aber vielleicht ist die Unterstützung mehrerer Umgebungen pro Projekt eine bessere Lösung mit einem akzeptablen Ergebnis.

@FredyC danke für all dein Feedback! Es ist wirklich hilfreich für uns zu sehen, wie verwirrend das sein kann. Es gibt zwei wichtige Dinge, die die Leute in ihren Tests im Zusammenhang mit der Authentifizierung tun möchten:

1. Melden Sie sich an, um Dienste wie Firestore oder Realtime Database zu verwenden, ohne echte Benutzer zu erstellen. Im Moment würde das so etwas wie setEmulatedUser lösen. Es würde Ihnen nur erlauben, lokal ein gefälschtes Authentifizierungstoken zu haben, das die Emulatoren akzeptieren würden, aber es würde von prod abgelehnt. Mehr Sicherheit, mehr Isolation usw.
2. Testen Sie die Authentifizierung tatsächlich direkt. Dies hätte ein paar Stücke:
   A. Ein Authentifizierungsemulator, der auf alle erforderlichen API-Aufrufe antwortet, damit Sie die Authentifizierungs-SDKs darauf verweisen können.
   B. Integration zwischen diesem Emulator und dem Funktionsemulator, damit .onCreate Funktionen korrekt ausgelöst werden.
   C. Automocking innerhalb des Funktionsemulators, sodass admin.auth() auf den Auth-Emulator zeigt, genau wie wir es heute für Firestore und RTDB tun.

Ich denke, (2) ist eindeutig die richtige Geschichte, aber ich habe versucht, ein Gefühl dafür zu bekommen, wie viele Leute mit (1) zufrieden sein würden, da es wesentlich einfacher zu implementieren und zu warten ist.

@samtstern Ich sehe. Korrigieren Sie mich, wenn ich falsch liege, aber ist (1) nicht bereits gelöst? Ich meine, in Tests kann ich einfach Folgendes aufrufen und der Firestore-Emulator erkennt mich als diesen Benutzer, damit ich gegen Sicherheitsregeln testen kann. Das habe ich noch nicht probiert, sieht aber bisher vielversprechend aus :)

  const app = firebase.initializeTestApp({
    projectId,
    auth: {
      uid: 'owner'
    }
  })

Die (2) klingt definitiv sehr nützlich, ist aber mit Sicherheit viel komplexer zu bewältigen. Leider ist mein Einblick in das vollständige Produkt so begrenzt, dass ich hier keine wirklich nützlichen Ideen anbieten kann.

Ich denke, es sollte inkrementell gebaut werden. Anstatt zu versuchen, alle Szenarien auf einmal abzudecken, erstellen Sie es basierend auf bekannten Anwendungsfällen und fügen Sie es unterwegs hinzu. Meiner begrenzten Meinung nach scheint es nicht so schwer zu sein, "Benutzerdatenbank" zusammen mit Funktionstriggern zu emulieren.

@ FredyC Sie haben Recht, dass (1) für die Verwendung in @firebase/testing .

Ich verstehe. Ehrlich gesagt wäre es großartig, wenn @firebase/testing plattformübergreifend verwendet werden könnte, anstatt separate Lösungen zu haben. Ich meine, wie schwer kann es sein, die Kommunikation zum Emulator umzuleiten? Ist das FIRESTORE_EMULATOR_HOST genau dafür? Obwohl ich denke, dass etwas wie FIREBASE_EMULATOR_HOST angemessener wäre, wenn der Emulator auch andere Dienste hat.

@vladimirdjurdjevic Ich denke, würde nicht wirklich funktionieren, um die Methode signInWithPhone im Grunde zu verspotten, damit Sie ihr Verhalten kontrollieren können? Dann brauchen Sie sich keine Sorgen um einen Emulator und simulierten SMS-Code in der Konsole zu machen :)

Natürlich benötigen Sie dann eine Möglichkeit, sich beim Emulator für Firestore zu authentifizieren (und eine Verbindung zu diesem herzustellen). Etwas wie ich in früheren https://github.com/firebase/firebase-tools/issues/1677#issuecomment -542897671 beschrieben habe. Es gibt eine zugrunde liegende Methode zum Generieren ungesicherter Token: https://github.com/firebase/firebase-js-sdk/blob/master/packages/testing/src/api/index.ts#L64. Bin mir nicht sicher ob das funktionieren würde.

Natürlich ist es nicht immer so einfach, Bibliotheken von Drittanbietern zu verspotten, aber wenn man es einmal herausgefunden hat, kann es großartige Ergebnisse bringen. Schließlich könnte es in eine Bibliothek extrahiert werden, um es allgemein einfacher zu machen.

Ich denke auch, dass diese Anmeldemethoden eine ganze Reihe von Fehlercodes auslösen können, was auch bei richtigen Tests beachtet werden sollte. Das geht auch leicht mit Spott.

@samtstern Das Erweitern des firebase.auth() Namespace-Kontexts um etwas Aktuelles wie setEmulatedUser scheint ein Anti-Muster mit den bestehenden Emulationsstrategien zu sein. Wird diese Empfehlung vielleicht von der Einfachheit der Erweiterbarkeit auf der Paketseite beeinflusst?

Im Einklang mit den anderen Emulatoren würde ich erwarten, dass eine separate Authentifizierungsdienstebene über HTTP gestartet wird und eine clientseitige Konfiguration die vorhandene API-Oberfläche zur Verwendung umleiten kann.

Ich hätte es viel lieber, wenn exzentrische AuthN-Fälle Fehler zurückgeben, wenn die Admin- und Client-API CRUD für einfache Benutzer über Benutzername/Passwort minimal unterstützt. Verdammt, ich denke, selbst mit der Unterstützung von benutzerdefinierten Token im Admin und signInWithCustomToken würde wirklich weit gehen. Vielleicht implementieren Sie niedrig hängende Früchte mit einer in den Dokumenten veröffentlichten API-Unterstützungsmatrix.

Für @FredyC besteht die aktuelle Strategie für Integrations-Auth-Tests darin, @firebase/testing im Anwendungscode bedingt zu importieren, um sie an den benutzerdefinierten initializeTestApp Aufruf weiterzuleiten. Diese Aktion betont sowohl den Paketausschluss zur Build-Zeit für Projektteams als auch verteilt die Emulator-Weiterleitungskonfigurationen auf zwei Paket-APIs ( initializeTestApp und firestore.settings / functions.useFunctionsEmulator ).

Hacke den Planeten!

Die aktuelle Strategie für Integrations-Auth-Tests besteht darin, @firebase/testing bedingt in den Anwendungscode zu importieren, um sie an den benutzerdefinierten initializeTestApp Aufruf weiterzuleiten.

Ähm, ich nenne diese Methode innerhalb von Tests. Der Trick besteht darin, dass sich normales initializeApp in index.ts das Funktionen importiert. Es wird beim Start des Emulators aufgerufen, aber wenn Tests ausgeführt werden, handelt es sich um einen anderen Prozess, der nicht miteinander in Konflikt steht. Es gibt also wirklich keine Last des bedingten Imports.

Dies kann natürlich beim Testen der Authentifizierung in z. B. anders sein. Web-App, in der der Testläufer den Prozess mit dem App-Code teilt. Beim Komponententest importieren Sie jedoch normalerweise nicht eine ganze App in einen Test. Das initializeApp wird wahrscheinlich in einem Code ausgeführt, der für Tests nicht relevant ist und überhaupt nicht importiert wird.

@FredyC Vereinbarte die dokumentierte Verwendung für

Ich wollte Ihnen nur die Namensnennung für Honestly, it would be kinda superb if @firebase/testing could be used cross-platform instead of having separate solutions . digitales High Five

@FredyC danke für all dein Feedback! Es ist wirklich hilfreich für uns zu sehen, wie verwirrend das sein kann. Es gibt zwei wichtige Dinge, die die Leute in ihren Tests im Zusammenhang mit der Authentifizierung tun möchten:

1. Melden Sie sich an, um Dienste wie Firestore oder Realtime Database zu verwenden, ohne echte Benutzer zu erstellen. Im Moment würde das so etwas wie setEmulatedUser lösen. Es würde Ihnen nur erlauben, lokal ein gefälschtes Authentifizierungstoken zu haben, das die Emulatoren akzeptieren würden, aber es würde von prod abgelehnt. Mehr Sicherheit, mehr Isolation usw.
2. Testen Sie die Authentifizierung tatsächlich direkt. Dies hätte ein paar Stücke:
   A. Ein Authentifizierungsemulator, der auf alle erforderlichen API-Aufrufe antwortet, damit Sie die Authentifizierungs-SDKs darauf verweisen können.
   B. Integration zwischen diesem Emulator und dem Funktionsemulator, damit .onCreate Funktionen korrekt ausgelöst werden.
   C. Automocking innerhalb des Funktionsemulators, sodass admin.auth() auf den Auth-Emulator zeigt, genau wie wir es heute für Firestore und RTDB tun.

Ich denke, (2) ist eindeutig die richtige Geschichte, aber ich habe versucht, ein Gefühl dafür zu bekommen, wie viele Leute mit (1) zufrieden sein würden, da es wesentlich einfacher zu implementieren und zu warten ist.

@samtstern erst einmal würde ich ❤️ diese Art von Emulation haben.

Ich würde nein sehen. 1 sehr nützlich zum Schreiben von e2e-Tests. Derzeit muss ich eine echte Instanz für die Authentifizierung verwenden, während ich den Emulator für Hosting, Regeln, Firestore und Funktionen verwenden kann.

Ich denke, es sollte möglich sein, setEmulatedUser zu verwenden, um Benutzer auf die gleiche Weise zu verspotten, wie es in firebase.initializeTestApp getan wird. Es sollte möglich sein, zB benutzerdefinierte Token und andere benutzerbezogene Daten zu übermitteln.

Es sollte auch möglich sein, Beispielanmeldeinformationen abzurufen, die in der Client-App mit firebase.auth().signInWithCredential(credential)

Danke @vladimirdjurdjevic , dass du dieses Thema

Wir würden gerne einen echten Emulator für drei Dinge sehen:

1. e2e-Tests für die gesamte App, sodass wir keine unterschiedlichen Umgebungen erstellen müssen, wie @vladimirdjurdjevic sagte.
2. Integrationstests für das Backend, wo die APIs aufgerufen werden und der Benutzer bei Firebase validiert werden soll.
3. Alle unsere Entwickler verwenden während der Entwicklung eine zentrale Firebase-Umgebung, was zu vielen Kollisionen führt. Natürlich könnte jeder Entwickler sein eigenes Firebase-Projekt erstellen, aber er muss seine Testbenutzer trotzdem im Firebase-Dashboard verwalten, was nicht ideal ist. Außerdem möchten wir unsere App offline entwickeln, was heute mangels eines echten Emulators nicht möglich ist.

Ich hoffe, dass Sie bald etwas für uns veröffentlichen werden, es würde Ihr Produkt wertvoller machen! Die Produktivität der Entwickler ist bei solchen Diensten sehr wichtig!

Dies scheint ein Merkmal auf der Wunschliste vieler Menschen zu sein. Firebase-Authentifizierung scheint derzeit die Nummer 1 unter den IDaaS zu sein, was die Preise angeht, daher ist es wirklich ein Problem, dass Sie mit Cloud Functions nicht lokal damit entwickeln können. Hoffentlich hat das FB-Team bald Updates für uns! 🙏

Bearbeiten: Pingen Sie @mbleigh von @firebase-ops, da dieser Thread unter Problemen begraben ist ...

Ich habe auch diese Fehlerfunktion ... ignoriert, weil der Auth-Emulator nicht existiert oder nicht läuft.

dies wird durch diesen Code ausgelöst:

Funktionen.auth.user().onDelete()

irgendwelche Infos dazu...

@dominikfoldi

Ich stimme deinen Punkten zu. Ein Tipp, der dir in der Zwischenzeit vielleicht helfen könnte:

Natürlich könnte jeder Entwickler sein eigenes Firebase-Projekt erstellen, aber er muss seine Testbenutzer trotzdem im Firebase-Dashboard verwalten, was nicht ideal ist.

Sie können Benutzer programmgesteuert mit dem Firebase Admin SDK starten und verwalten, z. B. auth().createUser , siehe auch https://firebase.google.com/docs/auth/admin/manage-users

Nachdem ich diesen Thread gelesen habe, denke ich, dass die Leute hier Foundry nützlich finden könnten.

Ich bin einer der Mitbegründer von Foundry. Foundry ist ein CLI-Tool, das Ihre Firebase Cloud Functions übernimmt und eine Kopie Ihrer Firebase-Produktionsanwendung auf unseren Servern erstellt, die als Ihre Entwicklungsumgebung fungieren, in der Sie Ihren Code direkt ausführen. Es ist keine Konfiguration erforderlich.

Foundry überwacht Ihre Quellcodedateien und jedes Mal, wenn Sie Ihren Code lokal speichern, führen wir ihn auf unseren Servern aus und geben Ihnen die Ergebnisse innerhalb weniger Sekunden zurück. Alles ist superschnell.
Sie geben an, welche Firestore-, RealtimeDB- und Auth-Benutzerdaten über unsere YAML-Datei aus Ihrer Produktions-App kopiert werden sollen, damit Sie sie während der Entwicklung zur Verfügung haben.

 users:
      - getFromProd: 5 # Copy first 5 users from your Firebase project
      - getFromProd: ['id-1', 'id-2'] # Copy users with the specified IDs from your Firebase project

 # Copy first 3 documents from production from the collection 'userWorkspaces'
 # also add a custom document with id 'new-user-workspace' with a new data
 # format that you want to use
 firestore:
     - collection: userWorkspaces
       docs:
         - getFromProd: 3
         - id: new-user-workspace
           data: {"newDataFormat": 42}

Sie geben auch an, wie wir Ihre Cloud-Funktionen auslösen sollen, wenn wir Ihren Code ausführen. Es funktioniert wie ein REPL für Ihre Cloud-Funktionen. Auf diese Weise können Sie immer sicher sein, dass Ihre Cloud-Funktionen mit Produktionsdaten und in der Produktionsumgebung nach der Bereitstellung korrekt funktionieren.
Außerdem verhalten sich Ihre Cloud-Funktionen so, als wären sie bereitgestellt.

Diese Entwicklungsumgebungen werden ad-hoc erstellt, sobald Sie Ihre Sitzung starten. Jeder in Ihrem Team arbeitet also in seiner eigenen Umgebung, in der er herumspielen kann.

Ich möchte die Diskussion hier nicht spammen , also eine E-Mail zu
Ich helfe Ihnen gerne, Foundry in Ihren Projekten einzurichten. Senden Sie mir einfach eine E-Mail!

Aber nach Ihrer Beschreibung und dem, was ich auf der Homepage gelesen habe, ist dieser Dienst Cloud-basiert.
Der Firebase-Emulator funktioniert stattdessen sogar offline, daher ist er für automatische Tests nützlich.

@samtstern Irgendwelche Fortschritte oder eine andere Lösung für dieses Problem/Feature? Ich benötige (1) setEmulatedUser, um mit dem Cloud-Firestore-Emulator zu arbeiten, damit ich lokal manuelle Tests durchführen kann. Eine andere Option wäre ein Befehlszeilenargument, das die Benutzer-ID festlegt, wenn der Emulator gestartet wird. Auf diese Weise würde der Emulator unter der beim Start übergebenen Benutzerkennung laufen. Auf diese Weise könnten die Regeln lokal getestet werden.

Laut Ihrem Kommentar: am 17. Oktober 2019
_Ich denke, (2) ist eindeutig die richtige Geschichte, aber ich habe versucht, ein Gefühl dafür zu bekommen, wie viele Leute mit (1) zufrieden sein würden, da es wesentlich einfacher zu implementieren und zu warten ist.

(1) Melden Sie sich an, um Dienste wie Firestore oder Realtime Database zu nutzen, ohne echte Benutzer zu erstellen. Im Moment würde das so etwas wie setEmulatedUser lösen. Es würde Ihnen nur erlauben, lokal ein gefälschtes Authentifizierungstoken zu haben, das die Emulatoren akzeptieren würden, aber es würde von prod abgelehnt. Mehr Sicherheit, mehr Isolation usw._

Wir arbeiten hart an einem vollständigen Authentifizierungsemulator, der hoffentlich das sein wird
alle wollen. Keine Zeitleiste, die ich im Moment anbieten kann, aber es hat eine hohe Priorität
für uns.

Am Freitag, 22. Mai 2020 um 8:12 Uhr schrieb ChuckB [email protected] :

@samtstern https://github.com/samtstern Irgendwelche Fortschritte oder andere
Lösung für dieses Problem/Feature? Ich brauche (1) setEmulatedUser, um mit dem zu arbeiten
den Cloud-Firestore-Emulator, damit ich lokal manuelle Tests durchführen kann.

Laut Ihrem Kommentar: am 17. Oktober 2019
_Ich denke, (2) ist eindeutig die richtige Geschichte, aber ich habe versucht, ein Gefühl dafür zu bekommen
mit wie vielen Leuten wäre zufrieden (1) da es wesentlich einfacher ist
implementieren und pflegen.

(1) Melden Sie sich an, um Dienste wie Firestore oder Realtime Database ohne . zu nutzen
tatsächlich echte Benutzer erstellen. Im Moment ist das sowas
setEmulatedUser würde lösen. Es würde Ihnen nur erlauben, eine gefälschte Authentifizierung zu haben
lokales Token, das die Emulatoren akzeptieren würden, aber es würde abgelehnt werden von
Prod. Mehr Sicherheit, mehr Isolation usw._

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-632660684 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/ACATB2Q4LV7NXMQFEALNPXLRSZT25ANCNFSM4I27PTFA
.

1. Melden Sie sich an, um Dienste wie Firestore oder Realtime Database zu nutzen, ohne echte Benutzer zu erstellen. Im Moment würde das so etwas wie setEmulatedUser lösen. Es würde Ihnen nur erlauben, lokal ein gefälschtes Authentifizierungstoken zu haben, das die Emulatoren akzeptieren würden, aber es würde von prod abgelehnt. Mehr Sicherheit, mehr Isolation usw.

Ich würde mich mit Nummer 1 hier in der Zwischenzeit freuen

https://stackoverflow.com/questions/62736060/firebase-test-auth-cloud-functions-locally

Ist es immer noch unmöglich?

@rishisingh-dev Es ist nicht möglich, einen Authentifizierungsemulator zum Laufen zu bringen, da die Firebase-Emulatoren derzeit keinen ausliefern.

Es ist jedoch durchaus möglich, Cloud-Funktionen zu testen, die eine Auth-Funktion beinhalten. Sie können die Funktion, die eine Authentifizierungs-API benötigt, umgestalten und in den Tests nachahmen, während Sie die echte in der Firebase-Funktionsdatei bereitstellen. Die Wiedergabetreue Ihres Testaufbaus ist geringer, aber dann ist es eine Frage des Grades, keine Frage der Art: Sie testen nur die Authentifizierungsaufrufe direkt, können aber testen, was Sie erwarten.

In dieser SO-Frage wäre es ungefähr so:

function sendWelcomeEmail(user) {
  console.log(user.uid);
  console.log(user.email);
  console.log(user.displayName);
}

exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => sendWelcomeEmail(user));

Und bei Ihren Tests rufen Sie sendWelcomeEmail direkt an, um sicherzustellen, dass es das tut, was Sie tun müssen.

Stellen Sie sich vor, Sie haben eine kompliziertere Cloud-Funktion namens addFriend , bei der der Benutzer eine E-Mail eines Freundes eingibt und Sie die Uid möchten. Sie können dies über die Authentifizierungen getUserByEmail .

function addFriend(email, getUserByEmail ) {
  const friendUid = getUserByEmail(email);
  // do things with friendUid;
}

exports.addFriend = functions.https.onCall(async (data, context) => {
  const email = data.email;
  const getUserByEmail = (email) => admin.auth().getUserByEmail(email);
  return { res: await addFriend(email, getUserByEmail ) };
}

In der Cloud-Fn-Deklaration senden Sie die echten getUserByEmail , aber bei Ihren Tests senden Sie stattdessen eine gefälschte:

async function testAddFriend() {
  const emails = {"[email protected]": "test-uid")
  const fakeGetUserByEmail = (email) => emails[email];
  addFriend("[email protected]);
  // verify the things were done with friendUid
}

Ich glaube nicht, dass sich dies wesentlich vom Testen einer Drittanbieter-API in einem Komponententest unterscheidet. Wenn die Firebase-Emulatoren Authentifizierung bereitstellen, werden Boilerplate für End-to-End-Testszenarien entfernt, aber die Unit-Tests werden dadurch nicht wesentlich verändert, da Sie sowieso nicht möchten, dass der persistente Zustand zwischen den Tests beibehalten wird.

Ich würde dies gerne lokal ausführen können, ohne zur Überprüfung in die Cloud hochladen zu müssen

export const onCreate = functions.auth.user().onCreate((user) => {
    addGravatarURLtoUserData(user.uid, user.email)
})

export const addGravatarURLtoUserData = async (uid, email) => {
    const hash = crypto.createHash("md5").update(email).digest("hex")
    await admin.database().ref(`users/${uid}`).update({ gravatarURL: uid })
}

Übrigens, kann ich user.displayName in die onCreate-Funktion holen?

ja wenn es eingestellt ist denke ich, hast du es probiert?

Ja, es gibt null zurück.
Ich habe es in der Cloud versucht (nicht lokal).

Mein Code ist hier.

exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => {
  console.log(user.uid);
  console.log(user.email);
  console.log(user.displayName);
});

Interessanterweise verwende ich keinen Anzeigenamen, ich verwende benutzerdefinierte Benutzer displayName für
Echtzeit-DB

/**
 * updates Custom data in the realtime datastore users object, except for the username
 * <strong i="7">@param</strong> data
 * <strong i="8">@returns</strong> {Promise<void>}
 */
export async function updatePersonalData(data) {
    const { displayName } = data
    try {
        await firebase
            .database()
            .ref("users/" + firebase.auth().currentUser.uid)
            .update({
                displayName: displayName,
            })

        userDataStore.update((user) => {
            return { ...user, displayName: displayName }
        })
    } catch (e) {
        alert(e.message)
    }
}

Am Fr, 10. Juli 2020 um 10:44 Uhr, rishisingh-dev [email protected]
schrieb:

Ja, es gibt null zurück.
Ich habe es in der Cloud versucht (nicht lokal).

[Bild: Screenshot 2020-07-10 um 14:43 Uhr]
https://user-images.githubusercontent.com/56976320/87140958-29f3ac80-c257-11ea-98d3-084fad619de7.png

Mein Code ist hier.

console.log(user.uid);
console.log(user.email);
console.log(user.displayName);
});```

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-656587759 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AABU35Q27EMMHYAYU5CNZR3R23PIDANCNFSM4I27PTFA
.

>

Mit freundlichen Grüßen

Nikos Katsikanis

Ja, mein primäres Ziel war es, die Datenbank mit Benutzerinformationen in der Funktion onCreate aktualisieren.
Aber da ich displayName nicht bekommen kann, habe ich eine onCallable Funktion erstellt und sie ausgeführt.

Vielen Dank.

@samtstern Ich arbeitest :)

Das Beste ist, dass ich Chrome nicht ohne Sicherheit öffnen muss

@sammstern

Kann man nun zwei Monate später eine grobe Schätzung abgeben?

Wir möchten Anfang des nächsten Jahres versenden. Wir stehen nun vor der Entscheidung, ob wir anfangen, Integrationstests gegen ein reales Projekt zu schreiben oder ein paar Monate auf den Auth-Emulator warten. Könnten Sie uns hier ein bisschen helfen?

Am besten,

Niklas

Unsere Richtlinie bei Firebase besteht darin, keine Schätzungen darüber abzugeben, wann etwas veröffentlicht wird, es sei denn, wir sind uns zu 100 % sicher. Im Moment arbeiten wir hart an dem Auth-Emulator, aber wir sind noch nicht nah genug dran, um einen Starttermin festzulegen.

Dies ist eine unserer obersten Prioritäten, aber ich denke, Sie sollten nicht warten, bis wir mit dem Testen Ihrer App beginnen. Schreiben Sie Ihre Tests noch heute gegen prod und wechseln Sie sie zum Ziel des Emulators, wenn dieser verfügbar ist.

Okay, danke @sammstern. Das hilft!

Wir würden gerne einen Authentifizierungsemulator verwenden, um Cloud Functions- und Firestore-Anfragen zu testen, die benutzerdefinierte Ansprüche auf Nutzertoken beinhalten. Wir können benutzerdefinierte Ansprüche mit Firestore im Regelspielplatz in der Firebase-Konsole testen, aber ein vollwertiger Authentifizierungsemulator würde uns theoretisch ermöglichen, viel mehr zu testen, wenn es um Benutzertoken geht.

Um es klar zu sagen: Wir setzen uns für einen vollwertigen Authentifizierungsemulator ein, der die tatsächlichen Dienstendpunkte (wo immer möglich) emuliert. Wir ziehen nicht mehr etwas Leichtes in Betracht, wie meine früheren Kommentare vorgeschlagen haben.

@samtstern das ist toll zu hören (zusammen mit den benutzerdefinierten Ansprüchen, da dies oft bei Integrationen von Drittanbietern verwendet wird). Gibt es irgendwo, wo wir mit dem Fortschritt/ETA Schritt halten können?

@fandy nein Entschuldigung, wir haben noch nichts zu teilen...

Danke Sam, derzeit mache ich alle meine Tests manuell, weil es nicht so ist
Es lohnt sich, e2e-Tests ohne Auth-Mocks zu schreiben

Am Mittwoch, den 26. August 2020 um 14:32 Uhr schrieb Sam Stern [email protected] :

>
>

@fandy https://github.com/fandy nein sorry wir haben nichts zu tun
noch teilen...

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-680850282 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AABU35UAQDBYEXKKINJSM43SCT6E7ANCNFSM4I27PTFA
.

--

Mit freundlichen Grüßen

Nikos Katsikanis

Um dies zu umgehen, habe ich mit dem Importieren von @firebase/testing in den Browser experimentiert. Das hat nicht wirklich funktioniert. Dies funktioniert jedoch: mangle @firebase/testing source, um den folgenden leicht bearbeiteten Chunk herauszukopieren:

import firebase from "firebase/app"
import * as component from "@firebase/component"
import * as util from "@firebase/util"
import { __awaiter, __generator } from "tslib"

function createUnsecuredJwt(auth) {
    // Unsecured JWTs use "none" as the algorithm.
    var header = {
        alg: 'none',
        kid: 'fakekid'
    };
    // Ensure that the auth payload has a value for 'iat'.
    auth.iat = auth.iat || 0;
    // Use `uid` field as a backup when `sub` is missing.
    auth.sub = auth.sub || auth.uid;
    if (!auth.sub) {
        throw new Error("auth must be an object with a 'sub' or 'uid' field");
    }
    // Unsecured JWTs use the empty string as a signature.
    var signature = '';
    return [
        util.base64.encodeString(JSON.stringify(header), /*webSafe=*/ false),
        util.base64.encodeString(JSON.stringify(auth), /*webSafe=*/ false),
        signature
    ].join('.');
}

function initializeApp(accessToken, options) {
    var _this = this;
    var app = firebase.initializeApp(options);
    if (accessToken) {
        var mockAuthComponent = new component.Component('auth-internal', function () {
            return ({
                getToken: function () { return __awaiter(_this, void 0, void 0, function () { return __generator(this, function (_a) {
                    return [2 /*return*/, ({ accessToken: accessToken })];
                }); }); },
                getUid: function () { return null; },
                addAuthTokenListener: function (listener) {
                    // Call listener once immediately with predefined accessToken.
                    listener(accessToken);
                },
                removeAuthTokenListener: function () { }
            });
        }, "PRIVATE" /* PRIVATE */);
        app._addOrOverwriteComponent(mockAuthComponent);
    }
    return app;
}

export function initializeTestApp(options) {
  let accessToken = undefined
  if (options.auth !== undefined) {
    accessToken = createUnsecuredJwt(options.auth)
  }
  return initializeApp(accessToken, options)
}

Jetzt können Sie das in Ihrem browserseitigen Code der App importieren, und

  let app
  if (dev) {
    app = initializeTestApp({projectId: "test", auth: {uid: "testuser"}})
    app.firestore().settings({
      host: "localhost:8080",
      ssl: false,
    })
  } else {
    app = firebaseProduction.initializeApp({ firebase config here })
    app.firestore().settings({ firestore config here })
  }
  window.firebase = app

Das funktioniert super! Wenn ich jetzt in der Entwicklung laufe, habe ich einen lokalen gefälschten Benutzer, den der Emulator für "testuser" hält (wie das Testhandbuch für Firestore-Sicherheitsregeln zeigt).

Eine andere Problemumgehung, die ich verwende, besteht darin, Ihre Authentifizierung zu stoppen (ich verwende generierte gefälschte Benutzer für Tests).

TypeScript-Beispiel:

import type { User as AuthUser } from '@firebase/auth-types'
// not importing a type, but a module of types
import { auth as authTypes} from 'firebase/app'
type Auth = authTypes.Auth

export const authStub = {
    getUser(uid: string) {
        // for uids like `testuser1234uid`
        let n = uid ? uid.replace("testuser", '').replace("uid", '') : ''
        return Promise.resolve({
            uid,
            email: `test.user${n}@foo.com`,
            emailVerified: true,
            providerData: [{
                providerId: 'google.com',
                email: `test.user${n}@foo.com`,
                uid: `testuser${n}provideruid`,
                phoneNumber: null,
                displayName: `Test User ${n}`.trim(),
                photoURL: 'https://thispersondoesnotexist.com/image',
            }],
            metadata: {
                // https://firebase.google.com/docs/reference/admin/node/admin.auth.UserMetadata
                createTime: new Date().toUTCString(),
                lastSignInTime: new Date().toUTCString()
            },
            customClaims: {
                username: `testuser${n}`
            }
        })
    },
    deleteUser(uid: string) {
        return Promise.resolve()
    },
    async updateUser(uid: string, data: AuthUser) {
        let user = await this.getUser(uid)
        return { ...user, data }
    },
    setCustomUserClaims(uid: string, customUserClaims: Object): Promise<void> {
        return Promise.resolve()
    }
}

export const auth = <Auth><unknown>authStub

Ändern Sie auch Ihre Regeln, da auth.token nicht emuliert wird. Zum Beispiel:

const rules = fs.readFileSync(__dirname + '/src/firebase/firestore/firestore.rules', 'utf8')
const modifiedRules =
    rules
        .replace(/request\.auth\.token\.email_verified/g, "true")
        .replace(/request\.auth\.token\.firebase\.sign_in_provider/g, "'password'")

await firebase.loadFirestoreRules({ projectId, rules: modifiedRules })

Bei mir funktioniert es super. Ich hoffe es hilft…

Wenn Sie diesem Thread folgen und ein Alpha-Tester des Firebase Authentication Emulators werden möchten, gehen Sie folgendermaßen vor:

1. Melden Sie sich für das Firebase Alpha-Programm an: https://services.google.com/fb/forms/firebasealphaprogram/
2. Senden Sie mir eine E-Mail an [email protected] , stellen Sie sicher, dass Sie diese von der E-Mail-Adresse senden, die Sie zum Testen verwenden.

Bitte tun Sie dies nur, wenn Sie ernsthaft daran interessiert sind, einen Emulator im Frühstadium auszuprobieren und Feedback zu geben! Es wird Fehler geben und einige Teile des Setups werden schwierig sein, aber wir möchten wissen, was Sie davon halten.

@samtstern Das sind tolle Neuigkeiten! Ich würde es gerne ausprobieren, aber ich gehe Ende der Woche mit meinem aktuellen Projekt in die Produktion, daher kann ich es mir im Moment nicht leisten, damit zu spielen. Werde mich so schnell wie möglich für Alpha anmelden :) Danke für die tolle Arbeit.

100% werden es versuchen wollen! Du bist der Mann Sam!

@samtstern freue mich darauf, es

Ich brauche die Auth-Funktion, um Funktionen lokal von Android aus zu testen, der Kontext von Auth ist immer null

Gute Nachrichten, der Authentifizierungs-Emulator ist Teil der neuen Version 8.14.0 ! 🙌🎊

Danke für die harte Arbeit Jungs und @samtstern 💪

Tolle Typen!

Ich bin nur der Bote! Der Auth-Emulator wurde zu 99% von @yuchenshi gebaut ... und deshalb werde ich ihm die Ehre geben, dieses Problem zu schließen, wenn er aufwacht.

Gibt es eine Dokumentation zu diesem neuen Emulator? (wie man Clients installiert, konfiguriert usw.)

PSVielen Dank für all die harte Arbeit dabei. Das wird uns alle möglichen coolen Sachen ermöglichen.

@nicoburns sehr bald! Offizielle Ankündigung, Dokumente und all die guten Sachen kommen in Kürze.

Großartige Neuigkeiten! :) Kann es kaum erwarten es auszuprobieren :)

Ich weiß, dass du darauf gewartet hast, also lass uns auf den Punkt kommen:

• Der Firebase-Authentifizierungsemulator ist jetzt verfügbar. Sie erhalten es, indem Sie Firebase CLI >= v8.14.0 installieren.
• Folgen Sie der Anleitung zur Emulator Suite, um loszulegen und Ihre Apps zu verbinden .
• Für spannende Ankündigungen wie diese und vieles mehr schalte JETZT den Firebase Summit- Livestream ein.**

**Shameless Plug: Ich mache heute auch eine Sitzung zum Thema "So richten Sie CI mit der Firebase Emulator Suite ein". Das Auffinden dieser im Sitzungsplan wird dem Leser als Übung überlassen.

_P.S. Ich kann wirklich 99% des Kredits nicht annehmen, da der Auth-Emulator natürlich Teamwork ist. Auch verschiedene Leute bei Firebase und Firebase-Entwickler (Sie) haben dabei eine große Rolle gespielt. Dankeschön!_

@yuchenshi Ist es möglich, erstellte Benutzer beim Beenden zu exportieren, genau wie beim Firestore-Emulator?

@vdjurdjevic noch nicht, daran arbeiten wir.

Dies ist ein sehr beliebtes Problem und jedes Update benachrichtigt 50-100 Personen. Da wir jetzt den Auth-Emulator veröffentlicht haben, werde ich dieses Problem für zukünftige Updates sperren. Wenn Sie eine Frage, einen Fehler oder eine Funktionsanfrage haben, starten Sie bitte eine neue Ausgabe!