Firebase-tools: Firebase認証エミュレータをエミュレータスイートに追加する

@vladimirdjurdjevicこれを上げてくれてありがとう！ これは私たちがやるべきことのリストにありますが、エミュレートする認証サービスの量とそれを行うための最良の戦略はまだ決定していません。 特定のもの（匿名認証など）はエミュレートが非常に簡単ですが、他のもの（SMS認証など）は非常に困難です。

しかし、私たちは間違いなく、あなたが言及したエンドツーエンドのユースケースを有効にしたいと思っています！

質問：エミュレータで使用するためにFirebaseユーザーをローカルでモックできるライブラリがあれば便利だと思いますか？ 何かのようなもの：

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

@samtstern setEmulatedUser()呼び出すと、 functions.auth.user().onCreate()エミュレートされたクラウド関数もトリガーされますか？ もしそうなら、それは非常に便利でしょう。

@samtsternこれは確かにいくつかのテストシナリオに役立ちますが、それでも開発には実際のインスタンスが必要です。 私の考えは、異なる環境向けに複数のFirebaseプロジェクトを作成することを避け、ローカルで（おそらくオフラインで）開発できるようにすることです。 別のアプローチは、サービスのさまざまな環境をサポートすることです。 同じプロジェクトでfirestoreとauthなどの異なる環境を作成できれば、多くの問題が解決します。 私は環境ごとにプロジェクトを作成できることを知っていますが、それはお尻の本当の痛みです。 すべての環境の構成、データの複製など。理想的には、1つのFirebaseプロジェクトを作成できるようにしたいのですが、手動テスト用のダミーデータが必要な場合は、Firestoreのステージング環境を作成してそこにデータをアップロードできます。

@noelmansour良い質問です！ それはそれほど難しいことではありません。おそらく、 signInAsEmulatedUserとsignUpAsEmulatedUserような2つの異なる呼び出しが必要であり、2番目の呼び出しだけが関数をトリガーします。

@vladimirdjurdjevicは、フル機能のエミュレーターが最適であることに完全に同意します。 ユーザーをローカルに設定することで解決できない「開発用の実際のインスタンス」から必要なものについて説明してください。

質問：エミュレータで使用するためにFirebaseユーザーをローカルでモックできるライブラリがあれば便利だと思いますか？

本当に便利です、それは大いに役立ちます。
現在、ローカルで何かをテストする必要があるたびにログに記録されたユーザーを検証するルール関数をtrue設定しています。これはかなり安全ではありませんが、現在のユーザーをエミュレートせずに実行できる簡単なことです。

はい、これは信じられないほど便利です

functions.auth.user().onCreate()ユニットテストもしたいと思います。 現時点での最善の回避策は、基本的にonCreate渡されたコールバック関数をエクスポートし、それに偽のuserオブジェクトを提供することだと思います。

この種のユニットテストについては、firebase-functions-testを確認してください
ライブラリ。モックデータを使用して関数ハンドラーを呼び出すのに役立ちます。

日、2019年10月13日には、5:44ダニエルK.の[email protected]は書きました：

また、functions.auth.user（）。onCreate（）を単体テストしたいと思います。 私
今のところ、最善の回避策は基本的にエクスポートコールバックであると仮定します
onCreateに渡された関数は、偽のユーザーオブジェクトを提供します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/1677?email_source=notifications&email_token=ACATB2QYJLX2LNVDTWJV25TQOMJ4VA5CNFSM4I27PTFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ACATB2SO3IR6UB73F4EMZPTQOMJ4VANCNFSM4I27PTFA
。

@samtsternこれは実際にFirestoreエミュレーターと一緒に機能しますか？ これに基づいて、私はそれが別の目的のためであるという印象を受けました。

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

私は確かにユニットテストのためのオンラインモードを望んでいません、それはスローポークでしょう。 また、「スタブ」でFirestoreエミュレータにアクセスできるかどうかもわかりません。

@FredyCこれらのドキュメントを指摘してございます。 「モード」は有効にできるスイッチではなく、実行できる戦略を説明しているだけなので、使用されている言葉は紛らわしいものです。

単体テストと一緒にFirestoreエミュレーターを起動する場合、コードは確実にそれに接続できます。 FIRESTORE_EMULATOR_HOST環境変数を設定すると、Firebase Admin SDKが自動的にFirestoreエミュレーターに接続します（ firebase emulators:execがこれを行います）。

@samtsternまだドットの接続に問題がありますが、 functions.auth.user().onCreate()テストにどのように役立ちますか？ 関数が製品版ではなくエミュレーターに接続するのは素晴らしいことですが、それはFirestoreだけですよね？ テストからユーザー作成を呼び出して、実際に機能コードを開始するにはどうすればよいですか？

前述のfirebase-functions-testには不可解なメソッドmakeUserRecordがあるようですが、それがどのように機能するのか、実際にどのように使用するのかはあまり意味がありません。

@firebase/testingパッケージからauth.createUserWithEmailAndPassword()を呼び出そうとしましたが、無効なAPIキーについて不平を言っているので、オンラインバージョンでのみ機能すると思います。

あなたが言及したそのenv変数を組織で

https://github.com/firebase/functions-samplesも閲覧してい

これを理解していただけますか？ :)

クラウド関数コードがadmin.auth().getUserByEmail()呼び出しを使用している、もう1つのケースもあります。 驚いたことに、それはエラーで終わらないが、それを返すことができるようにそのユーザーをどのように作成するのか私にはわからない。 もちろん、管理モジュール全体をモックアウトすることを除いて、それはクレイジーです:)

@samtstern遅れてすみません。 私が実際のインスタンスと言うとき、私は実際のインスタンスを意味します：D理想的には、開発のために角度環境ファイルの構成を交換し、アプリが実際のAPIと通信しているように認証機能を実装し続けたいのですが、実際にはエミュレーターが実行されていますマシン、そして私はそれをオフラインで行うことができます。 これで、たとえばSMSの送信に関する課題を理解できました。 エミュレーターが実際のSMSを私の電話に送信することを期待するのはばかげていますが、コンソール（送信されるSMSのコンテンツ）に印刷することもできます。 これでの価値よりもおそらく面倒です。 そのため、プロジェクトごとに複数の環境をサポートするだけで、作業が大幅に改善されると思います。 異なる環境の複数のプロジェクト間で構成を複製するには、かなりの時間がかかります。 また、スクリプトの複数のサービスアカウントを管理して、さまざまなFirestoreプロジェクトにデータをシードできるようにするのは面倒です。 そのため、Firebaseプラットフォーム全体をエミュレートすれば、それをすべての非本番環境に使用して、実際のFirebaseプロジェクトを1つだけ管理できることを教えました。 しかし、プロジェクトごとに複数の環境をサポートするだけで、許容できる結果が得られるより良いソリューションになるかもしれません。

@FredyCフィードバックありがとう

1. 実際にユーザーを作成せずに、FirestoreやRealtimeDatabaseなどのサービスを使用するにはサインインしてください。 今のところ、それはsetEmulatedUserようなものが解決するものです。 これにより、エミュレーターが受け入れる偽の認証トークンをローカルに持つことができますが、prodによって拒否されます。 より多くの安全性、より多くの隔離など。
2. 実際に認証を直接テストします。 これにはいくつかの部分があります：
   NS。 必要なすべてのAPI呼び出しに応答して、AuthSDKを指定できるようにする認証エミュレーター。
   NS。 .onCreate関数が正しくトリガーされるように、そのエミュレーターと関数エミュレーターを統合します。
   NS。 関数エミュレーター内の自動モックにより、今日のFirestoreやRTDBの場合と同様に、 admin.auth()がAuthエミュレーターを指すようになります。

明らかに（2）は正しい話だと思いますが、実装と保守が大幅に簡単であるため、（1）に満足する人の数を把握しようとしていました。

@samtsternなるほど。 私が間違っている場合は私を訂正してください、しかし（1）はすでに解決されていませんか？ つまり、テストでは次のように呼び出すことができ、Firestoreエミュレーターは私をそのユーザーとして認識するため、セキュリティルールに対してテストできます。 私はまだ実際にそれを試していませんが、これまでのところ有望に見えます:)

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

（2）は確かに非常に便利に聞こえますが、確実に取り組むにははるかに複雑です。 残念ながら、製品全体に対する私の洞察は非常に限られているため、ここで役立つアイデアを提供することはできません。

少しずつ構築する必要があると思います。 すべてのシナリオを一度にカバーしようとするのではなく、既知のユースケースに基づいて構築し、外出先で追加します。 私の限られた意見では、関数トリガーとともに「ユーザーデータベース」をエミュレートすることはそれほど難しいことではないようです。

@FredyCあなたは正しいです（1）はテストスイート内で使用するために解決されています。 ただし、もう1つの使用例は、Android / iOS / Webアプリをローカル開発用のエミュレーターに直接接続することです。 その場合、 @firebase/testingは使用できません。

分かりました。 正直なところ、 @firebase/testingを個別のソリューションではなく、クロスプラットフォームで使用できれば、それはちょっと素晴らしいことです。 通信をエミュレーターにリダイレクトするのはどれほど難しいのでしょうか？ まさにそのためのFIRESTORE_EMULATOR_HOSTではありませんか？ エミュレータが他のサービスも持つ場合は、 FIREBASE_EMULATOR_HOSTようなものがより適切だと思いますが。

@vladimirdjurdjevic私が考えているのは、実際にはsignInWithPhoneメソッドをモックアウトして、その動作を制御できるようにすることではないでしょうか。 そうすれば、エミュレーターやコンソールでシミュレートされたSMSコードを取得することについて心配する必要はありません:)

もちろん、Firestoreのエミュレーターに対して認証する（そしてそれに接続する）方法が必要です。 以前のhttps://github.com/firebase/firebase-tools/issues/1677#issuecomment-542897671で概説したようなもの。 保護されていないトークンを生成するための基本的な方法があります： //github.com/firebase/firebase-js-sdk/blob/master/packages/testing/src/api/index.ts#L64。 それがうまくいくかどうかはわかりません。

もちろん、サードパーティのライブラリをモックすることは必ずしも簡単ではありませんが、一度理解すれば、素晴らしい結果をもたらすことができます。 最終的には、一般的に簡単にするために、いくつかのライブラリに抽出される可能性があります。

また、これらのsignInメソッドは、非常に多くのエラーコードをスローする可能性があると考えています。これは、適切なテストでも対処する必要があります。 これは、モックでも簡単に実行できます。

@samtstern firebase.auth()名前空間コンテキストをsetEmulatedUserようなトピックで拡張することは、既存のエミュレーション戦略のアンチパターンのように見えます。 その推奨事項は、パッケージ側の拡張のしやすさに影響されているのでしょうか。

他のエミュレーターと同様に、HTTPを介して別の認証サービス層が起動され、クライアント側の構成で既存のAPIサーフェスをリダイレクトして利用できるようになると思います。

むしろ、ユーザー名/パスワードを介して基本ユーザーのCRUDを最小限にサポートするAdminおよびClientAPIでエキセントリックなAuthNケースがエラーを返すようにしたいと思います。 ちなみに、管理者でのカスタムトークンのサポートから始めても、 signInWithCustomTokenは非常に効果的だと思います。 たぶん、ドキュメントで公開されているAPIサポートマトリックスを使用して、ぶら下がっている果物を実装します。

@FredyCポイントにとって、統合認証テストの現在の戦略は、アプリケーションコードの@firebase/testingを条件付きでインポートして、カスタムinitializeTestApp呼び出しにルーティングすることです。 このアクションは、プロジェクトチームのビルド時にパッケージの除外を強調するだけでなく、エミュレーターのリダイレクト構成を2つのパッケージAPI（ initializeTestAppとfirestore.settings / functions.useFunctionsEmulator ）に分散します。

惑星をハック！

統合認証テストの現在の戦略は、アプリケーションコードに@firebase/testingを条件付きでインポートして、カスタムinitializeTestApp呼び出しにルーティングすることです。

ええと、私はテスト内でそのメソッドを呼び出しています。 秘訣は、通常のinitializeApp関数をインポートするindex.ts存在することです。 エミュレーターの起動時に呼び出されますが、テストの実行中は別のプロセスであり、互いに競合しません。 したがって、条件付きインポートの負担は実際にはありません。

もちろん、これは、たとえば認証をテストする場合とは異なる場合があります。 テストランナーがプロセスをアプリコードと共有するウェブアプリ。 ただし、単体テストでは、通常、アプリ全体をテストにインポートすることはありません。 initializeAppは、テストに関係がなく、まったくインポートされていないコードで実行されている可能性があります。

@FredyCユニットテストの文書化された使用法について合意しました。 APIが発散し、動的インポートが文書化されたマップから外れるフルアプリシナリオについて実際に話していました。

Honestly, it would be kinda superb if @firebase/testing could be used cross-platform instead of having separate solutions帰属を表示したかっただけです。 デジタルハイファイブ

@FredyCフィードバックありがとう

1. 実際にユーザーを作成せずに、FirestoreやRealtimeDatabaseなどのサービスを使用するにはサインインしてください。 今のところ、それはsetEmulatedUserようなものが解決するものです。 これにより、エミュレーターが受け入れる偽の認証トークンをローカルに持つことができますが、prodによって拒否されます。 より多くの安全性、より多くの隔離など。
2. 実際に認証を直接テストします。 これにはいくつかの部分があります：
   NS。 必要なすべてのAPI呼び出しに応答して、AuthSDKを指定できるようにする認証エミュレーター。
   NS。 .onCreate関数が正しくトリガーされるように、そのエミュレーターと関数エミュレーターを統合します。
   NS。 関数エミュレーター内の自動モックにより、今日のFirestoreやRTDBの場合と同様に、 admin.auth()がAuthエミュレーターを指すようになります。

明らかに（2）は正しい話だと思いますが、実装と保守が大幅に簡単であるため、（1）に満足する人の数を把握しようとしていました。

@samtsternまず第一に、私は❤️この種のエミュレーションを持っているでしょう。

いいえ、わかりません。 1e2eテストの作成に非常に役立ちます。 現在、認証には実インスタンスを使用する必要がありますが、ホスティング、ルール、ファイアストア、および機能にはエミュレーターを使用できます。

setEmulatedUserを使用して、firebase.initializeTestAppで行われるのと同じ方法でユーザーをモックすることが可能であると思います。 カスタムトークンやその他のユーザー関連データなどを送信できるはずです。

firebase.auth().signInWithCredential(credential)使用してクライアントアプリで使用できるサンプルのクレデンシャルを取得することも可能である必要があります

この問題を提起してくれてありがとう

私たちは3つのことのために実際のエミュレーターを見たいと思っています：

1. e2eはアプリ全体をテストするため、 @ vladimirdjurdjevicが言ったように異なる環境を作成する必要はありません。
2. バックエンドの統合テスト。APIが呼び出され、ユーザーはFirebaseで検証される必要があります。
3. すべての開発者は、開発中に中央のFirebase環境を使用しているため、多くの衝突が発生します。 もちろん、すべての開発者が独自のFirebaseプロジェクトを作成できますが、それでもFirebaseダッシュボードでテストユーザーを管理する必要がありますが、これは理想的ではありません。 また、実際のエミュレーターがないため、今日は不可能なアプリをオフラインで開発したいと考えています。

あなたが私たちのために何かをすぐにリリースすることを願っています、それはあなたの製品をより価値のあるものにするでしょう！ このようなサービスでは、開発者の生産性が非常に重要です。

これは多くの人のウィッシュリストの機能のようです。 Firebase authは、現在の価格設定でナンバーワンのIDaaSのようです。そのため、CloudFunctionsを使用してローカルで開発できないのは本当に苦痛です。 FBチームが私たちのためにすぐにアップデートを持っていることを願っています！ 🙏

編集：このスレッドは問題に埋もれているため、@ firebase -opsから送信します...

また、このエラーがあります...認証エミュレータが存在しないか実行されていないため、関数は無視されます。

これは、次のコードによってトリガーされます。

関数.auth.user（）。onDelete（）

これに関する情報...

@dominikfoldi

私はあなたの意見に同意します。 その間に役立つかもしれない1つのヒント：

もちろん、すべての開発者が独自のFirebaseプロジェクトを作成できますが、それでもFirebaseダッシュボードでテストユーザーを管理する必要がありますが、これは理想的ではありません。

auth().createUserなどのfirebase admin SDKを使用して、プログラムでユーザーをシードおよび管理できます。https：//firebase.google.com/docs/auth/admin/manage-usersも参照して

このスレッドを読んだ後、私はここの人々がファウンドリが役に立つと思うかもしれないと思います。

私はFoundryの共同創設者の1人です。 Foundryは、Firebase Cloud Functionsを取得し、コードを直接実行する開発環境として機能するサーバー上に本番Firebaseアプリのコピーを作成するCLIツールです。 構成は必要ありません。

Foundryはソースコードファイルを監視し、コードをローカルに保存するたびにサーバー上で実行し、わずか数秒で結果を返します。 すべてが超高速です。
開発中に利用できるように、YAMLファイルを介して本番アプリからコピーするFirestore、RealtimeDB、およびAuthUsersデータを指定します。

 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}

また、コードを実行するときにクラウド関数をトリガーする方法も指定します。 クラウド機能のREPLのように機能します。 そうすることで、クラウド機能が本番データで正しく機能し、デプロイした後は本番環境で正しく機能することを常に確認できます。
また、クラウド機能は展開されているかのように機能します。

これらの開発環境は、セッションを開始するとアドホックに作成されます。 そのため、チームの全員が自分の環境で操作し、そこで混乱する可能性があります。

ここでのディスカッションをスパムしたくないので、質問があれば遠慮なくメールで送ってください
プロジェクトでFoundryをセットアップするお手伝いをさせていただき、メールをお送りください。

それでも、あなたがそれをどのように説明し、私がホームページで読んだかから、そのサービスはクラウドベースです。
代わりに、Firebaseエミュレータはオフラインでも機能するため、自動テストに役立ちます。

@samtsternこの問題/機能の進捗状況または別の解決策はありますか？ ローカルで手動テストを実行できるように、クラウドFirestoreエミュレーターと連携するために（1）setEmulatedUserが必要です。 もう1つのオプションは、エミュレーターの起動時にユーザーIDを設定するコマンドライン引数を使用することです。 このようにして、エミュレーターは起動時に渡されたユーザーIDで実行されます。 このようにして、ルールをローカルでテストできます。

あなたのコメントによると：2019年10月17日
_明らかに（2）は正しい話だと思いますが、実装と保守が大幅に簡単であるため、（1）に満足する人の数を把握しようとしていました。

（1）実際にユーザーを作成せずに、FirestoreやRealtimeDatabaseなどのサービスを使用するにはサインインします。 今のところ、それはsetEmulatedUserのようなものが解決するものです。 これにより、エミュレーターが受け入れる偽の認証トークンをローカルに持つことができますが、prodによって拒否されます。 より多くの安全性、より多くの隔離など_

私たちは完全な認証エミュレーターに取り組んでいます。
みんなが欲しい。 現在提供できるタイムラインはありませんが、優先度が高いです
私たちのために。

8:12 ChuckBので金、2020年5月22日に[email protected]書きました：

@samtsternhttps ：//github.com/samtstern進捗状況またはその他
この問題/機能の解決策は？ （1）setEmulatedUserを操作する必要があります
ローカルで手動テストを実行できるように、クラウドFirestoreエミュレーター。

あなたのコメントによると：2019年10月17日
_明らかに（2）は正しい話だと思いますが、私は感覚を得ようとしていました
（1）はかなり簡単なので、何人の人が満足するでしょうか
実装および保守。

（1）サインインしてFirestoreやRealtimeDatabaseなどのサービスを使用せずに使用する
実際に実際のユーザーを作成します。 今はそういうものです
setEmulatedUserが解決します。 それはあなたが偽の認証を持つことを可能にするでしょう
エミュレータが受け入れるローカルトークンですが、によって拒否されます
製品。 より多くの安全性、より多くの隔離など_

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-632660684 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ACATB2Q4LV7NXMQFEALNPXLRSZT25ANCNFSM4I27PTFA
。

1.実際にユーザーを作成せずに、FirestoreやRealtimeDatabaseなどのサービスを使用するにはサインインします。 今のところ、それはsetEmulatedUserのようなものが解決するものです。 これにより、エミュレーターが受け入れる偽の認証トークンをローカルに持つことができますが、prodによって拒否されます。 より多くの安全性、より多くの隔離など。

暫定的に、ここでナンバーワンに満足します

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

それはまだ不可能ですか？

@ rishisingh-dev現在、firebaseエミュレーターには認証エミュレーターが付属していないため、認証エミュレーターを実行することはできません。

ただし、認証を含むクラウド機能をテストすることは完全に可能です。 いくつかの認証APIを必要とする関数をリファクタリングし、テストでモックすると同時に、firebase関数ファイルで実際の関数を提供できます。 テスト設定の忠実度は低くなりますが、種類の問題ではなく、程度の問題になります。認証呼び出しを直接テストしているだけですが、期待どおりの結果をテストできます。

その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));

また、テストでは、 sendWelcomeEmail直接呼び出して、必要な処理が実行されることを確認します。

addFriendと呼ばれるより複雑なクラウド関数があり、ユーザーが友達の電子メールを入力し、uidが必要だとします。 これは、auths 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 ) };
}

クラウドのfn宣言では、実際のgetUserByEmailを送信しますが、テストでは、代わりに偽の宣言を送信します。

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

これは、単体テストでサードパーティのAPIをテストすることと大きく異なるとは思いません。 Firebaseエミュレーターに認証を提供させると、ボイラープレートからエンドツーエンドのテストシナリオが削除されますが、テスト間で永続的な状態を維持したくないため、単体テストが大幅に変更されることはありません。

確認のためにクラウドにアップロードしなくても、これをローカルで実行できるようにしたいと思います

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 })
}

ちなみに、onCreate関数内でuser.displayNameを取得できますか？

はい、設定されていると思いますが、やってみましたか？

はい、nullを返します。
私は（ローカルではなく）クラウドでそれを試しました。

私のコードはここにあります。

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

興味深いことに、私は表示名を使用していません。カスタムユーザーのdisplayNameを使用しています。
リアルタイムデータベース

/**
 * 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)
    }
}

10時44分に2020年7月〜金、10には、rishisingh-devの[email protected]
書きました：

はい、nullを返します。
私は（ローカルではなく）クラウドでそれを試しました。

[画像：スクリーンショット2020-07-10 at 2 43 12 AM]
https://user-images.githubusercontent.com/56976320/87140958-29f3ac80-c257-11ea-98d3-084fad619de7.png

私のコードはここにあります。

console.log（user.uid）;
console.log（user.email）;
console.log（user.displayName）;
}）; `` `

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-656587759 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AABU35Q27EMMHYAYU5CNZR3R23PIDANCNFSM4I27PTFA
。

>>

敬具

Nikos Katsikanis

はい、私の主な目標は、 onCreate関数内のユーザー情報でデータベースを更新すること
しかし、 displayName取得できないため、 onCallable関数を作成して実行しました。

ありがとう。

@samtsternこれに取り組んでいるのを見てとてもうれしいです：）

もう1つの優れた点は、セキュリティなしでChromeを開く必要がないことです。

@samtstern

2か月後、大まかな見積もりを出すことは可能ですか？

来年初めに発送したいと思います。 実際のプロジェクトに対して統合テストを書き始めるのか、それとも認証エミュレーターを数か月待つのかという決定に直面しています。 ここで少し手伝ってもらえますか？

一番、

ニクラス

Firebaseのポリシーでは、100％確信が持てない限り、何かがいつリリースされるかを見積もることはありません。 現在、Authエミュレーターに取り組んでいますが、リリース日を選択するのに十分な準備ができていません。

これは私たちの最優先事項の1つですが、アプリのテストが開始されるのを待つべきではないと思います。 今日prodに対するテストを作成し、利用可能になったときにエミュレーターをターゲットにするように切り替えます。

了解しました。@ samtsternに感謝します。 それは役に立ちます！

認証エミュレーターを本当に使用したいのは、ユーザートークンのカスタムクレームを含むクラウド関数とFirestoreリクエストをテストすることです。 Firebase ConsoleのルールプレイグラウンドでFirestoreを使用してカスタムクレームをテストすることはできますが、本格的な認証エミュレーターを使用すると、理論的には、ユーザートークンに関してテストの方法でさらに多くのことができるようになります。

明確にするために、私たちは実際のサービスエンドポイントをエミュレートする本格的な認証エミュレーターに取り組んでいます（可能な限り）。 以前のコメントが示唆したような軽量なものはもう検討していません。

@samtsternを聞くのは素晴らしいことです（カスタムクレームとともに、サードパーティの統合でよく使用されるため）。 進捗状況/ ETAについていくことができる場所はありますか？

@fandy申し訳ありませんが、まだ共有できるものはありません...

サムに感謝します。現在、すべてのテストを手動で行っています。
認証モックなしでe2eテストを作成するために努力する価値があります

14時32分の水、2020年8月26日には、サム・スターンの[email protected]は書きました：

>>
>>

@fandy https://github.com/fandy申し訳ありませんが、何もありません
まだ共有しています...

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-680850282 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AABU35UAQDBYEXKKINJSM43SCT6E7ANCNFSM4I27PTFA
。

-

敬具

Nikos Katsikanis

これを回避するために、ブラウザに@ firebase / testingをインポートしてみました。 それは実際には機能しませんでした。 ただし、これは行います。@ firebase / tests sourceをマングルして、次のわずかに編集されたチャンクをコピーします。

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)
}

これで、アプリのブラウザー側のコードで、それをインポートできます。

  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

それはうまくいきます！ 現在、開発中の場合、エミュレーターが「testuser」と見なすローカルの偽のユーザーがいます（Firestoreセキュリティルールのテストガイドに示されているように）。

私が使用する別の回避策は、認証をスタブ化することです（テストには生成された偽のユーザーを使用しています）。

TypeScriptの例：

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

また、 auth.tokenはエミュレートされないため、ルールを変更してください。 例えば：

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 })

それは私にとって素晴らしい働きをしています。 それが役に立てば幸い…

このスレッドをフォローしていて、Firebase Authentication EmulatorのAlphaテスターに​​なることをいとわない場合は、次の手順に従ってください。

1. Firebase Alphaプログラムにサインアップします： //services.google.com/fb/forms/firebasealphaprogram/
2. [email protected]にメールを送ってください。必ず、テストに使用するメールアドレスから送信してください。

初期段階のエミュレーターを試してフィードバックを提供することに真剣に興味がある場合にのみ、これを行ってください。 バグがあり、セットアップの一部が難しいでしょうが、私たちはあなたがどう思うか知りたいです。

@samtsternこれは素晴らしいニュースです！ 試してみたいのですが、週末までに現在のプロジェクトで制作する予定なので、今は遊ぶ余裕がありません。 私ができる限り早くアルファにサインアップします:)素晴らしい仕事をありがとう。

100％これを試してみたいと思います！ あなたの男サム！

@samtsternはそれを試して、私ができることは何でも助けることを楽しみにしています！

Androidからローカルで関数をテストするには、authの機能を使用する必要があります。Authのコンテキストは常にnullです。

朗報です。AuthenticationEmulatorは新しい

頑張ってくれてありがとう@ samtstern💪

素晴らしい人たち！

私はただのメッセンジャーです！ Authエミュレーターは99％が@yuchenshiによってました...そのため、彼が目を覚ましたときにこの問題を解決できることを光栄に思います。

この新しいエミュレータに関するドキュメントはありますか？ （クライアントのインストール、構成方法など）

PSこれに関するすべてのハードワークに感謝します。 これにより、あらゆる種類のクールなものが可能になります。

@nicoburnsすぐに！ 公式発表、ドキュメント、その他すべての優れた機能がまもなく登場します。

素晴らしいニュース！ :)それを試してみるのが待ちきれません:)

私はあなたがこれを待っていたのを知っているので、要点に切り込みましょう：

• Firebase AuthenticationEmulatorが利用可能になりました。 Firebase CLI> = v8.14.0をインストールすることで入手できます。
• エミュレータスイートガイドに従って開始し、アプリを
• このようなエキサイティングな発表やその他多くのことについては、 FirebaseSummitのライブストリームを今すぐご覧ください。**

**恥知らずなプラグイン：本日後半に「Firebaseエミュレータスイートを使用してCIを設定する方法」に関するセッションも行っています。 セッションスケジュールでそれを見つけることは、読者の練習問題として残されています。

_P.S。 Auth Emulatorはもちろんチームワークなので、99％のクレジットを取得することはできません。 FirebaseとFirebase開発者（あなた）のさまざまな人々もこれに大きな役割を果たしました。 ありがとうございました！_

@yuchenshi Firestoreエミュレーターの場合と同様に、作成したユーザーを終了時にエクスポートすることはできますか？

@vdjurdjevicはまだ、現在取り組んでいます。

これは非常に人気のある問題であり、更新するたびに50〜100人に通知されます。 Authエミュレーターをリリースしたので、今後の更新からこの問題をロックします。 質問、バグ、または機能のリクエストがある場合は、新しい問題を開始してください。