web-dev-qa-db-ja.com

Firebase:追加のユーザープロパティを設定する

Firebaseユーザーオブジェクトにプロパティを追加したいと思います。 ユーザードキュメント は、Firebaseリアルタイムデータベースを使用して追加のプロパティのみを保存できることを示しています。

私はこれが実際にどのように機能するのかについて確信が持てません。

実際には、次の意味は何ですか?

Firebase Userオブジェクトに他のプロパティを直接追加することはできません。代わりに、Firebase Realtime Databaseに追加のプロパティを保存できます。

私はそれを次のように解釈します:

FIRUserオブジェクトのプロパティを変更することはできませんが、これを追加のオブジェクトと組み合わせることができます。」

set関数 ドキュメント を見つけました。

  var userRef = ref.child("users");
  userRef.set({
    newfield: "value"
  });

これは賢明なアプローチですか?

20
mm24

あなたはほとんどそこにいます。従来のFirebaseドキュメントには、 そのような追加のユーザーデータの保存 に関するセクションがありました。

重要なのは、ユーザーのuidの下に追加情報を保存することです。

    let newUser = [
        "provider": authData.provider,
        "displayName": authData.providerData["displayName"] as? NSString as? String
    ]
    // Create a child path with a key set to the uid underneath the "users" node
    // This creates a URL path like the following:
    //  - https://<YOUR-FIREBASE-APP>.firebaseio.com/users/<uid>
    ref.childByAppendingPath("users")
       .childByAppendingPath(authData.uid).setValue(newUser)

新しいドキュメントにもこの情報を追加する必要があるというメモを追加しました。ちょうど良い場所を見つける必要があります。

17

Custom Claims ドキュメントによると、

Firebase Admin SDKは、ユーザーアカウントのカスタム属性の定義をサポートしています。 [...]ユーザーロールは、次の一般的な場合に定義できます。

  • ユーザーに追加の識別子を追加します。たとえば、Firebaseユーザーは別のシステムの別のUIDにマップできます。

[...]カスタムクレームペイロードは1000バイトを超えてはなりません。

ただし、これは Best Practices に従って、一般的なプロファイル情報ではなく、認証関連のユーザーデータに対してのみ実行してください。

カスタムクレームは、アクセス制御を提供するためにのみ使用されます。追加のデータ(プロファイルやその他のカスタムデータなど)を保存するようには設計されていません。これはそうするのに便利なメカニズムのように思えるかもしれませんが、これらのクレームはIDトークンに保存され、すべての認証済みリクエストにはサインインしたユーザーに対応するFirebase IDトークンが常に含まれるため、パフォーマンスの問題を引き起こす可能性があるため、強くお勧めできません。

カスタムアクセスを使用して、ユーザーアクセスのみを制御するためのデータを保存します。他のすべてのデータは、リアルタイムデータベースまたは他のサーバー側ストレージを介して個別に保存する必要があります。

3
Dan Dascalescu