カスタムユーザーメタデータの定義
項目一覧
アプリの各ユーザーにカスタム メタデータを関連付けらることができます。 たとえば、ユーザーの希望言語、誕生日、などユーザーに関連付ける情報を保存できます。
ユーザーのメタデータは、次の 2 つのソースから取得できます。
カスタム ユーザー データを保存する MongoDB Atlas のコレクション。 ユーザー ID を使用して、各ユーザーを コレクション内のドキュメントに関連付けることができます。 各ドキュメントには任意のデータを保存できます。
認証プロバイダ。 Google や 、カスタム プロバイダーなどのプロバイダーが Web トークンJSONFacebook を使用する場合は、ユーザーの からのデータをユーザーのアカウントに関連付けるプロバイダー構成でメタデータJSON web token フィールドを定義できます。
カスタムユーザーデータ
アプリケーション ユーザーに関する任意のデータを MongoDB コレクションに保存できます。 アプリは、ユーザーの ID の特定のフィールドをクエリして、各ユーザーを コレクション内のドキュメントにマッピングします。 ユーザーが認証を行う際、アプリはユーザーのデータを検索し、それをアクセス トークンに含めます。
ID "63ed2dbe5960df2af7fd216e"
を持つユーザーについて考えてみましょう。 カスタム ユーザー データ コレクションがuserId
フィールドにユーザーの ID を保存するように設定されている場合、ユーザーは次のドキュメントにマッピングされます。
{ "_id": "63ed2e4fb7f367c92578e526", "user_id": "63ed2dbe5960df2af7fd216e", "preferences": { "preferDarkMode": true }, "dateOfBirth": "1989-03-11T00:00:00.000Z" }
カスタム ユーザー データを使用する場合は、次の点に注意してください。
ユーザーごとに 1 つのドキュメントを保存 : ユーザー データを含むドキュメントには、特定のフィールドにユーザーの ID を含める必要があります。 複数のドキュメントで同じユーザーの ID が指定されている場合、App Services は最初に挿入されたドキュメントのデータのみを公開します。
カスタム ユーザー データを小さく: ユーザーの完全なカスタム ユーザー ドキュメントがアクセス トークンに含まれます。 一般的に、カスタム ユーザー データ ドキュメントは小さく(16 KB 未満)に保つようにしてください。 他のサービスでは HTTP ヘッダーのサイズが制限されている場合があり、カスタム ユーザー データ オブジェクトが大きいと統合の問題が発生する可能性があります。
カスタム データは古い可能性があります :ユーザーのカスタム データはMongoDBコレクションから取得されますが、ユーザーの認証アクセス トークンに保存され、読み取りが行われます。 基礎となるドキュメントが変更されたときにユーザーが有効なアクセス トークンを持っている場合、そのセッション内のカスタム データは、アクセス トークンを更新するか再認証を行うまで更新されません。
カスタムユーザーデータの作成と管理
カスタムユーザーデータコレクション内のドキュメントを管理する必要があります。 ユースケースに応じて、次の操作を行います。
ユーザー作成機能を使用して、アプリケーションに登録するときに各ユーザーのドキュメントを自動的に作成します。 この関数はユーザーがアクセス トークンを発行する前に実行されるため、追加したデータは最初のログイン時にアクセス トークンに含まれます。
認証triggerを使用して、ユーザーが登録またはログインするときにそのユーザーのカスタム データをアップデートし、アカウントが削除された場合はそのユーザーのデータを削除します。 trigger は非同期で実行され、ユーザーのアクセス トークンが作成された後に終了する可能性があります。
スケジュールされたtriggerを使用して、カスタム ユーザー データを定期的にアップデートまたは削除します。
関数、Atlas Device SDK、MongoDB ドライバー、または MongoDB Compass からの標準 CRUD 操作を使用して、コレクション内のドキュメントを手動で作成、更新、削除します。
カスタムユーザーデータを保護する
アプリのカスタム ユーザー データに個人ユーザー情報またはプライベートユーザー情報が含まれている場合は、カスタムユーザー データ コレクションへのアクセスを制限する必要があります。 特権ユーザーのみに読み取りおよび書込みアクセスを制限するには、次の権限モデルのいずれかを使用することを検討してください。
ユーザーは独自のカスタム ユーザー データ ドキュメントの読み取りや書き込みができます。 他のすべてのドキュメントへの読み取りおよび書込みアクセスを拒否します。
例
次のコレクション構成では、ユーザーの ID がドキュメントの
user_id
フィールドに含まれている場合にのみ、ドキュメントへの読み取りおよび書込みアクセス権を付与する 1 つのロールがあります。カスタムユーザーデータコレクション構成{ "database": "<Database Name>", "collection": "<Collection Name>", "roles": [ { "name": "ThisUser", "apply_when": { "user_id": "%%user.id%%" }, "insert": false, "read": true, "write": true, "search": false, "delete": false } ], "filters": [] } カスタム ユーザー データ ドキュメントの読み取りと書き込みはできません。 代わりに、システム関数を使用して、ユーザーに代わってカスタムユーザーデータを管理します。
ユーザー作成関数
新しいユーザーが正常に登録されるたびに、新しいユーザー アカウントが作成される前に実行される 関数 を定義できます。 関数がスローなどのエラーが発生すると、ユーザー アカウントの作成は失敗します。 これにより、ユーザーは一度作成したカスタム データを常に関連付けることができます。
この関数は、ユーザー メタデータ オブジェクトを唯一の引数として受け取ります。 これを使用して、ユーザー用に新しいカスタム ユーザー データ ドキュメントを作成できます。
exports = async function onUserCreation(user) { const customUserDataCollection = context.services .get("mongodb-atlas") .db("myapp") .collection("users"); try { await customUserDataCollection.insertOne({ // Save the user's account ID to your configured user_id_field user_account_id: user.id, // Store any other user data you want favorite_color: "blue", }); } catch (e) { console.error(`Failed to create custom user data document for user:${user.id}`); throw e } }
Tip
ユーザー作成機能を構成すると、App Services によってその関数の削除が防止されます。 関数を削除する場合は、まずカスタムユーザーデータ構成を変更して、別のユーザー作成関数を使用します。
カスタムユーザーデータの有効化
App Services Admin UI でカスタム ユーザー データを構成して有効にできます。
カスタムユーザーデータコレクションを指定する
アプリケーションのユーザーのカスタム データは、リンクされた MongoDB Atlas クラスターの単一のコレクションに保存する必要があります。 このコレクションからユーザー データを読み取るようにアプリケーションを構成するには、次の値を指定する必要があります。
Cluster Name: カスタム ユーザー データ コレクションを含む連結された MongoDB クラスターの名前。
Database Name: カスタムユーザーデータコレクションを含む MongoDB database の名前。
Collection Name: カスタム ユーザー データが含まれる MongoDB コレクションの名前。
ユーザー ID フィールドの指定
カスタムユーザーデータコレクション内のすべてのドキュメントには、特定のアプリケーションユーザーにマッピングする フィールドがあります。 フィールドは、そのObjectIdを表す ObjectID
または string
タイプである必要があります。 このフィールドは、ユーザーにマッピングするすべてのドキュメントに存在する必要があります。
User ID Field入力で各ユーザーの ID を含むフィールドの名前を指定します。
注意
2 つのドキュメントに同じ ユーザーIDが含まれており、1 つはstringとして、もう 1 つはObjectIdとして保存されている場合、App Services はstring型のドキュメントをユーザーにマッピングします。
ユーザー作成関数の定義(任意)
ユーザー作成関数を使用する場合は、インライン エディターで定義するか、既存の関数を名前で参照します。
更新されたアプリケーションの配置
カスタム ユーザー データ コレクションを構成したら、アプリケーションをデプロイすることで、カスタム ユーザー データをクライアント アプリケーションで利用できるようになります。 App Services UI からドラフト アプリケーションを配置するには次の手順に従います。
左側のナビゲーション メニューで [ Deployをクリックします。
配置履歴テーブルで配置案を見つけ、 Review & Deploy Changesをクリックします。
変更の差を確認し、 Deployをクリックします。
アプリケーションが正常に配置されると、App Services によるカスタム データのユーザーとの関連付けが開始されます。 ユーザーがログインすると、App Services はカスタム ユーザー データ コレクションで、指定されたUser ID Fieldにユーザーの ID が含まれるドキュメントを自動的にクエリします。 ドキュメントが一致する場合、App Services はドキュメント内のデータをそのユーザーのユーザー オブジェクトのcustom_data
フィールドに公開します。
カスタムユーザーデータの構成
アプリケーションのユーザーのカスタム データは、リンクされた Atlas クラスターの単一のコレクションに保存する必要があります。 コレクション内のすべてのドキュメントには、記述する App Services ユーザーのユーザー ID を含む特定のフィールドを含める必要があります。
このコレクションからユーザー データを読み取るようにアプリケーションを構成するには、 /auth/custom_user_data.json
でカスタム ユーザー データ構成ドキュメントを定義します。
{ "enabled": <Boolean>, "mongo_service_name": "<MongoDB Data Source Name>", "database_name": "<Database Name>", "collection_name": "<Collection Name>", "user_id_field": "<User ID Field Name>", "on_user_creation_function_name": "<Function Name>" }
クライアント アプリケーションからカスタム ユーザー データにアクセス
クライアント アプリケーションからカスタム ユーザー データにアクセスしてアップデートする方法を示すコード例については、Atlas Device SDK のドキュメントを参照してください。
カスタム ユーザー データでの権限変更に関するベストプラクティス
カスタム ユーザー データ ドキュメントを変更すると、ユーザーの権限は自動的に更新されます。 ユーザー セッションは終了し、自動的に更新されます。
ユーザー権限を自動的に更新するには、カスタム ユーザー データ ドキュメントをビューまたは時系列コレクションではなく、通常のコレクションに保存する必要があります。
自動的に更新する権限については、カスタム ユーザー データ ドキュメントを削除しないでください。 代わりに、ドキュメント内のすべての非 ID フィールドの設定を解除してください。
例
ユーザーに読み取りおよび書込み権限が割り当てられている次のドキュメントを検討します。
{ "_id": "63ed2erealobjectid78e526", "user_id": "63ed2dbe5960df2af7fd216e", "canRead": true, "canWrite": true, }
canRead
フィールドとcanWrite
フィールドは、このドキュメントのコレクションのロールを決定するのに役立ちます。 たとえば、 canRead
フィールドは、 apply_when
式の次のreadAllRole
の適格性を決定するために使用されます。
{ "name": "readAllRole" "apply_when": {"%%user.custom_data.canRead": true}, ... }
たとえば、ユーザーが長期間アクティブでなかったため、ユーザーのドキュメントを削除したいとします。 まず、非 ID フィールドの設定を解除して、従業員の権限を正しく削除する必要があります。 ドキュメントは次のようになります。
{ "_id": "63ed2erealobjectid78e526", "user_id": "63ed2dbe5960df2af7fd216e" }
非 ID フィールドの設定を解除すると、App Services は ロール に従ってユーザーの権限を自動的に更新できます。 必要に応じて、ドキュメントを安全に削除できるようになりました。
認証プロバイダのメタデータ
Atlas App Services は、認証プロバイダからユーザー メタデータを読み取ることができます。 次に、App Services は各ユーザーのデータをユーザー オブジェクトの フィールドで公開します。 たとえば、ユーザーの名前、メール、誕生日、性 にアクセスしたいとします。
ユーザーがログインするときにアクセス トークンを使用してメタデータをリクエストするように App Services を設定できます。 クライアント SDK を使用して、ログインユーザーの オブジェクトからそのデータにアクセスできます。
認証プロバイダを設定するときに、リクエストするメタデータを定義できます。 ユーザーのアカウントを通じてアクセスするオプションのメタデータ フィールドを指定します。 これらのメタデータ フィールドは、プロバイダーによって異なります。
プロバイダー | メタデータ フィールド |
---|---|
Facebook |
|
Google |
|
カスタム JWT | JSON web tokenカスタムJSON web token プロバイダーの メタデータ フィールド 構成によって指定される、 内の任意のフィールド。 |
重要
古い認証プロバイダのメタデータを避ける
アクセス トークンが発行された後にユーザーのメタデータが更新された場合、以前に作成されたアクセス トークンを使用するリクエストには新しく更新されたメタデータは含まれません。 ユーザー メタデータは、アクセス トークンを更新または再認証するときに更新されます。
注意
セキュリティと認証プロバイダーのメタデータ
認証プロバイダのメタデータは、クライアントや外部認証プロバイダによって外部定義される可能性があるため、注意が必要です。 データアクセス権限の ルール式 でこのメタデータを使用するなど、セキュリティ関連の決定を行うために認証プロバイダのメタデータのみに依存しないでください。
認証プロバイダ メタデータの設定
ユーザー メタデータの設定
Google または Facebook
有効にするメタデータ フィールドの横にあるチェックボックスを選択します。
カスタム JWT 認証
IdP がサポートするメタデータ フィールドを指定できます。 Add Fieldボタンを押した後、以下を定義します。
パス
フィールド名
フィールドが任意か必須か
詳細については、「 JSON web tokenメタデータ フィールド 」を参照してください。
アクセスするメタデータを設定したら、 Save Draftボタンを押します。
更新されたアプリケーションの配置
メタデータ構成を更新した後、アプリケーションを配置する必要があります。 App Services UI からドラフト アプリケーションを配置するには次の手順に従います。
左側のナビゲーション メニューで [ Deployをクリックします。
配置履歴テーブルで配置案を見つけ、 Review & Deploy Changesをクリックします。
変更の差を確認し、 Deployをクリックします。
アプリケーションが正常に配置されると、App Services によってメタデータとユーザーの関連付けが開始されます。 ユーザーがログインすると、 App Services requestsは要求されたメタデータにアクセスするためのユーザーの権限を要求します。 ユーザーが承認すると、App Services はそのユーザーのユーザー オブジェクト内のデータを公開します。
メタデータ フィールドの構成
アプリの認証プロバイダのメタデータ_フィールドは、 /auth/providers.json
にあります。 この配列を更新して、認証プロバイダからユーザー メタデータを要求します。
Google または Facebook
この配列は次のようになります。
{ ...other config details... "metadata_fields": [ { "required": false, "name": "name" }, { "required": false, "name": "gender" } ] }
カスタム JWT 認証
metadata_fields 配列には、追加のプロパティfield_name
があります。 カスタムJSON web token認証では、name
は フィールドへのパスを表します。 field_name
はフィールド名を表します。
{ ...other config details... "metadata_fields": [ { "required": true, "name": "user.name", "field_name": "name" }, { "required": false, "name": "user.favoriteColor", "field_name": "favoriteColor" } ] }
MongoDB Atlas ユーザーの認証
MongoDB Atlas API キー ペアを使用して、管理ユーザー認証エンドポイントを呼び出します。
curl -X POST \ https://services.cloud.mongodb.com/api/admin/v3.0/auth/providers/mongodb-cloud/login \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -d '{ "username": "<Public API Key>", "apiKey": "<Private API Key>" }'
認証に成功すると、レスポンス本文にはaccess_token
値を持つ JSON オブジェクトが含まれます。
{ "access_token": "<access_token>", "refresh_token": "<refresh_token>", "user_id": "<user_id>", "device_id": "<device_id>" }
access_token
は App Services Admin API へのアクセスを許可します。 すべての管理 API リクエストのAuthorization
ヘッダーに Bearer トークンとして含める必要があります。
メタデータ フィールドの構成
認証プロバイダを更新エンドポイントに リクエストを送信します。 リクエスト本文で、プロバイダーのmetadata_fields
を定義します。
次のように、管理API access_token
、アプリを含むAtlasプロジェクトの groupId
、アプリ内部の appId
16 進string 、および認証プロバイダの _id
値を含めます。
curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \ --header 'Authorization: Bearer <access_token>' \ --header 'Content-Type: application/json' \ --data '{ "_id": "<Provider ID>", "name": "oauth2-facebook", "type": "oauth2-facebook", "redirect_uris": ["https://example.com/"], "config": { "clientId": "<Facebook Client ID>" }, "secret_config": { "clientSecret": "<Facebook Client Secret Name>" }, "metadata_fields": [ { "required": false, "name": "name" }, { "required": true, "name": "first_name" }, { "required": true, "name": "last_name" }, { "required": false, "name": "picture" }, { "required": false, "name": "gender" }, { "required": false, "name": "birthday" }, { "required": false, "name": "min_age" }, { "required": false, "name": "max_age" }, { "required": false, "name": "email" } ], "disabled": false }'
curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \ --header 'Authorization: Bearer <access_token>' \ --header 'Content-Type: application/json' \ --data '{ "_id": "<Provider ID>", "name": "oauth2-google", "type": "oauth2-google", "redirect_uris": ["https://example.com/"], "config": { "clientId": "<Google Client ID>" }, "secret_config": { "clientSecret": "<Google Client Secret Name>" }, "metadata_fields": [ { "required": false, "name": "name" }, { "required": true, "name": "first_name" }, { "required": true, "name": "last_name" }, { "required": false, "name": "picture" }, { "required": false, "name": "gender" }, { "required": false, "name": "birthday" }, { "required": false, "name": "min_age" }, { "required": false, "name": "max_age" }, { "required": false, "name": "email" } ], "disabled": false }'
curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \ --header 'Authorization: Bearer <access_token>' \ --header 'Content-Type: application/json' \ --data '{ "_id": "<Provider ID>", "name": "custom-token", "type": "custom-token", "metadata_fields": [ { "required": true, "name": "jwt.field.path", "field_name": "metadataFieldName" } ], "config": { "audience": [], "requireAnyAudience": false, "signingAlgorithm": "HS256", "useJWKURI": false }, "secret_config": { "signingKeys": [ "<JWT Signing Key>" ] }, "disabled": true }'
プロバイダーのメタデータ フィールドが正常に構成されると、App Services は204
応答を返します。
注意
複数のリンクされた認証プロバイダーを持つユーザーに関するヒント
最新のメタデータを確保するために、ユーザーは別の認証プロバイダに切り替えた後に再認証を行う必要があります。 そうしないと、UI のApp Usersページおよび認証プロバイダを使用するリクエストのUsersテーブルに反映される、古いメタデータが反映される可能性があります。
ユーザーが認証プロバイダーを切り替える場合、メタデータが伝達されるまでに最大30分かかる場合があります。 リクエストでは、認証プロバイダに関連付けられた最新のメタデータが使用されることが常に保証されます。
クライアント アプリケーションからユーザー メタデータにアクセスする
クライアント アプリケーションからユーザー メタデータ データにアクセスする方法を示すコードの例については、Atlas Device SDK のドキュメントを参照してください。