Docs Menu
Docs Home
/ /
Atlas App Services
/

カスタムユーザーメタデータの定義

項目一覧

  • カスタムユーザーデータ
  • カスタムユーザーデータの作成と管理
  • カスタムユーザーデータを保護する
  • ユーザー作成関数
  • カスタムユーザーデータの有効化
  • クライアント アプリケーションからカスタム ユーザー データにアクセス
  • カスタム ユーザー データでの権限変更に関するベストプラクティス
  • 認証プロバイダのメタデータ
  • 認証プロバイダ メタデータの設定
  • クライアント アプリケーションからユーザー メタデータにアクセスする

アプリの各ユーザーにカスタム メタデータを関連付けらることができます。 たとえば、ユーザーの希望言語、誕生日、などユーザーに関連付ける情報を保存できます。

ユーザーのメタデータは、次の 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 でカスタム ユーザー データを構成して有効にできます。

1

左側のナビゲーション メニューで [ App Usersをクリックします。 次に、 User Settingsタブを選択し、 Custom User Dataセクションを見つけます。

2

Enable Custom User DataトグルをクリックしてOnに設定します。

App Services UI でカスタム ユーザー データを有効にする切り替えボタンを [On] に設定します。
クリックして拡大します
3

アプリケーションのユーザーのカスタム データは、リンクされた MongoDB Atlas クラスターの単一のコレクションに保存する必要があります。 このコレクションからユーザー データを読み取るようにアプリケーションを構成するには、次の値を指定する必要があります。

  • Cluster Name: カスタム ユーザー データ コレクションを含む連結された MongoDB クラスターの名前。

  • Database Name: カスタムユーザーデータコレクションを含む MongoDB database の名前。

  • Collection Name: カスタム ユーザー データが含まれる MongoDB コレクションの名前。

Atlas App Services UI のコレクションとユーザー ID フィールドの入力ボックス。
クリックして拡大します
4

カスタムユーザーデータコレクション内のすべてのドキュメントには、特定のアプリケーションユーザーにマッピングする フィールドがあります。 フィールドは、そのObjectIdを表す ObjectID または string タイプである必要があります。 このフィールドは、ユーザーにマッピングするすべてのドキュメントに存在する必要があります。

User ID Field入力で各ユーザーの ID を含むフィールドの名前を指定します。

注意

2 つのドキュメントに同じ ユーザーIDが含まれており、1 つはstringとして、もう 1 つはObjectIdとして保存されている場合、App Services はstring型のドキュメントをユーザーにマッピングします。

5

ユーザー作成関数を使用する場合は、インライン エディターで定義するか、既存の関数を名前で参照します。

6

カスタム ユーザー データ コレクションを構成したら、アプリケーションをデプロイすることで、カスタム ユーザー データをクライアント アプリケーションで利用できるようになります。 App Services UI からドラフト アプリケーションを配置するには次の手順に従います。

  1. 左側のナビゲーション メニューで [ Deployをクリックします。

  2. 配置履歴テーブルで配置案を見つけ、 Review & Deploy Changesをクリックします。

  3. 変更の差を確認し、 Deployをクリックします。

アプリケーションが正常に配置されると、App Services によるカスタム データのユーザーとの関連付けが開始されます。 ユーザーがログインすると、App Services はカスタム ユーザー データ コレクションで、指定されたUser ID Fieldにユーザーの ID が含まれるドキュメントを自動的にクエリします。 ドキュメントが一致する場合、App Services はドキュメント内のデータをそのユーザーのユーザー オブジェクトcustom_dataフィールドに公開します。

1

appservices を使用してカスタム ユーザー データを定義するには、アプリケーションの構成ファイルのローカル コピーが必要です。

アプリの最新バージョンのローカルコピーを取得するには、次のコマンドを実行します。

appservices pull --remote="<Your App ID>"

Tip

App Services UI のDeploy > Export App画面からアプリケーションの構成ファイルのコピーをダウンロードすることもできます。

2

アプリケーションのユーザーのカスタム データは、リンクされた Atlas クラスターの単一のコレクションに保存する必要があります。 コレクション内のすべてのドキュメントには、記述する App Services ユーザーのユーザー ID を含む特定のフィールドを含める必要があります。

このコレクションからユーザー データを読み取るようにアプリケーションを構成するには、 /auth/custom_user_data.jsonカスタム ユーザー データ構成ドキュメントを定義します。

/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>"
}
3

カスタム ユーザー データを構成したら、更新された構成をリモート アプリにプッシュできます。 App Services CLI はプッシュ時に更新をすぐに配置します。

appservices push --remote="<Your App ID>"

クライアント アプリケーションからカスタム ユーザー データにアクセスしてアップデートする方法を示すコード例については、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
  • name

  • first_name

  • last_name

  • picture

  • gender

  • birthday

  • min_age

  • max_age

  • email

Google
  • name

  • first_name

  • last_name

  • picture

  • email

カスタム JWT
JSON web tokenカスタムJSON web token プロバイダーの メタデータ フィールド 構成によって指定される、 内の任意のフィールド。

重要

古い認証プロバイダのメタデータを避ける

アクセス トークンが発行された後にユーザーのメタデータが更新された場合、以前に作成されたアクセス トークンを使用するリクエストには新しく更新されたメタデータは含まれません。 ユーザー メタデータは、アクセス トークンを更新または再認証するときに更新されます。

注意

セキュリティと認証プロバイダーのメタデータ

認証プロバイダのメタデータは、クライアントや外部認証プロバイダによって外部定義される可能性があるため、注意が必要です。 データアクセス権限の ルール式 でこのメタデータを使用するなど、セキュリティ関連の決定を行うために認証プロバイダのメタデータのみに依存しないでください。

1

App Services UI でユーザー メタデータを構成して有効にできます。 構成ページにアクセスする方法は、次のとおりです。

  • 左側のナビゲーション メニューで [ Authenticationをクリックします。

  • Authentication Providers タブを選択します。

  • 設定するメタデータを持つプロバイダーのEDITボタンを押します。

2

Google または Facebook

有効にするメタデータ フィールドの横にあるチェックボックスを選択します。

App Services UI でユーザー メタデータ フィールドを有効にするチェックボックス
クリックして拡大します

カスタム JWT 認証

IdP がサポートするメタデータ フィールドを指定できます。 Add Fieldボタンを押した後、以下を定義します。

  • パス

  • フィールド名

  • フィールドが任意か必須か

詳細については、「 JSON web tokenメタデータ フィールド 」を参照してください。

Atlas App Services UI で必須/オプション、パス、名前を追加します。
クリックして拡大します

アクセスするメタデータを設定したら、 Save Draftボタンを押します。

3

メタデータ構成を更新した後、アプリケーションを配置する必要があります。 App Services UI からドラフト アプリケーションを配置するには次の手順に従います。

  1. 左側のナビゲーション メニューで [ Deployをクリックします。

  2. 配置履歴テーブルで配置案を見つけ、 Review & Deploy Changesをクリックします。

  3. 変更の差を確認し、 Deployをクリックします。

アプリケーションが正常に配置されると、App Services によってメタデータとユーザーの関連付けが開始されます。 ユーザーがログインすると、 App Services requestsは要求されたメタデータにアクセスするためのユーザーの権限を要求します。 ユーザーが承認すると、App Services はそのユーザーのユーザー オブジェクト内のデータを公開します。

1

appservices を使用してアプリを更新するには、その構成ファイルのローカル コピーが必要です。

アプリの最新バージョンのローカルコピーを取得するには、次のコマンドを実行します。

appservices pull --remote="<Your App ID>"

Tip

App Services UI からアプリケーションの構成ファイルのコピーをダウンロードすることもできます。 アプリ ダッシュボードから Deploy > Export App 画面にGoします。

2

アプリの認証プロバイダのメタデータ_フィールドは、 /auth/providers.jsonにあります。 この配列を更新して、認証プロバイダからユーザー メタデータを要求します。

Google または Facebook

この配列は次のようになります。

/auth/providers.json
{ ...other config details...
"metadata_fields": [
{
"required": false,
"name": "name"
},
{
"required": false,
"name": "gender"
}
]
}

カスタム JWT 認証

metadata_fields 配列には、追加のプロパティfield_nameがあります。 カスタムJSON web token認証では、name は フィールドへのパスを表します。 field_nameはフィールド名を表します。

/auth/providers.json
{ ...other config details...
"metadata_fields": [
{
"required": true,
"name": "user.name",
"field_name": "name"
},
{
"required": false,
"name": "user.favoriteColor",
"field_name": "favoriteColor"
}
]
}
3

カスタム ユーザー データを構成したら、更新された構成をリモート アプリにプッシュできます。 App Services CLI はプッシュ時に更新をすぐに配置します。

appservices push --remote="<Your App ID>"
1

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 トークンとして含める必要があります。

Tip

以下も参照してください。

2

認証プロバイダを更新エンドポイントに リクエストを送信します。 リクエスト本文で、プロバイダーの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 のドキュメントを参照してください。

戻る

ユーザーの作成