Docs Menu
Docs Home
/ /
Atlas App Services
/ /

サービス Webhook の構成

重要

サードパーティ サービスとプッシュ通知の廃止

Atlas App Services のサードパーティ サービスとプッシュ通知は非推奨となり、代わりに関数内の外部依存関係を使用する HTTP エンドポイントを作成できるようになりました。

Webhook はHTTPS endpointsに名前変更され、動作は変更されません。 既存の Webhook を移行する必要があります。

既存のサービスは、 30、2025 まで引き続き機能します。

サードパーティ サービスとプッシュ通知は非推奨になったため、App Services UI からデフォルトで削除されました。 既存のサードパーティ サービスまたはプッシュ通知を管理する必要がある場合は、次の操作を実行して構成を UI に追加できます。

  • 左側のナビゲーションの [ App Settings Manageセクションの下にある [] をクリックします。

  • Temporarily Re-Enable 3rd Party Servicesの横にあるトグル スイッチを有効にし、変更を保存します。

一部の外部サービスでは、外部クライアントが HTTP 経由で呼び出せる受信 Webhookを作成できます。 App Services UI または App Services CLI を使用して、これらのサービスの Webhook を作成できます。 使用する方法に対応する以下のタブを選択します。

1

受信する Webhook の範囲は個々のサービスに限定されます。 App Services UI の関連するサービス ページから Webhook を作成および管理できます。

受信 Webhook を作成するには、次の手順に従います。

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

  2. 受信 Webhook を追加するサービスをクリックします。

  3. サービスの [ Incoming Webhooks ] タブを選択します。

  4. [ Add Incoming Webhookをクリックします。 App Services は新しい Webhook のSettings画面にリダイレクトします。

2

Webhook Nameフィールドに Webhook を識別できる一意の名前を入力します。 この名前は、サービス用に作成した他の Webhook と異なる必要があります。

3

Webhook を含む Atlas 関数は常に特定のアプリケーションユーザーのコンテキストで、またはシステムユーザーとして実行され、ルールをバイパスします。 Webhook の実行ユーザーを構成するには、App Services が Webhook に使用する認証のタイプを指定します。

認証タイプ
説明

アプリケーション認証

このタイプの認証では、各受信リクエストで指定された既存のアプリケーション ユーザー配下で Webhook を実行するように構成されます。 受信リクエストには、リクエスト本文またはリクエスト ヘッダーのいずれかにユーザーの認証プロバイダが含まれている必要があります。

次の例は、サポートされている各認証プロバイダのフィールド名と値を示しています。

{
"email": "<User's Email Address>",
"password": "<User's Password>"
}
{
"api-key": "<User's API Key>"
}
{
"jwtTokenString": "<User's JWT Token>"
}

重要

ヘッダーとボディ フィールドの両方を使用しない

リクエストのリクエスト ヘッダーとリクエスト本文の両方に認証情報が含まれている場合、App Services はエラーをスローし、関数を実行しません。

注意

アプリケーション ユーザー

アプリケーション認証を使用する Webhook を設定して、リクエストごとに追加のユーザー関連の作業を実行できます。

  • Fetch Custom User Dataを有効にすると、App Services はリクエスト元のユーザーのカスタム ユーザー データをクエリし、存在する場合はそのデータを オブジェクトとして context.user.custom_dataプロパティで公開します。

  • Create User Upon Authenticationを有効にすると、既存のユーザーと一致しない場合、App Services は提供されたユーザー認証情報に基づいて新しいユーザーを自動的に作成します。 新しいユーザーを作成するには、リクエスト時に認証情報に対応する認証プロバイダを有効にする必要があります。

システム

このタイプの認証では、MongoDB CRUD および集計 API へのフルアクセス権を持ち、ルール、ロール、または権限の影響を受けないシステムユーザーとして Webhook を実行するように構成されます。

ユーザー ID

このタイプの認証では、常に特定のアプリケーション ユーザーとして Webhook が実行されるように設定されます。

スクリプト

このタイプの認証では、定義したカスタム関数の結果によって決定された特定のアプリケーション ユーザーとして Webhook を実行するように構成されます。 この関数は特定のユーザーのid string を返す必要があります。または、 { "runAsSystem": true }を返すことでシステムユーザーを指定することもできます。

UI のユーザー認証タイプの入力
クリックして拡大します
4

受信リクエストで特定の HTTPメソッドhttpMethod を使用するよう要求するか、コンテキストの プロパティを検査することで、すべてのHTTPメソッドを受け入れ、Webhook 関数でそれぞれを個別に処理することができます。次の例関数のように、オブジェクトをリクエスト。

exports = function(payload, response) {
switch(context.request.httpMethod) {
case "GET": { /* Handle GET requests */ }
case "POST": { /* Handle POST requests */ }
case "PUT": { /* Handle PUT requests */ }
case "DELETE": { /* Handle DELETE requests */ }
case "PATCH": { /* Handle PATCH requests */ }
default: {}
}
}
UI の HTTP メソッド ドロップダウン入力
5

Webhook を呼び出す外部サービスに、構成可能なHTTPレスポンス を送信できます。

Respond With Result を有効にすると、Webhook は基本的なHTTP 200 応答で受信リクエストに応答します。この応答には Webhook 関数の戻り値が bodyフィールドとして含まれます。App Services が 2 番目の引数として自動的に渡す responseオブジェクトを使用して、Webhook 関数内からカスタムHTTPレスポンスを構成できます。

UI で [結果] を切り替える
クリックして拡大します
6

Can Evaluateを定義することで、各リクエストの内容に基づいてリクエストを動的に承認できます。Atlas App Services は、Webhook が受信するすべての受信リクエストに対して式を評価します。 式を指定しない場合、Atlas App Services は認証されたすべての受信リクエストを自動的に承認します。

式は、 の展開を含む標準の 式変数 %%requestを展開できます。

Webhook の Can Evaluate JSON 式の UI への入力
クリックして拡大します
7

Webhook リクエストが信頼できるソースから送信されたことを検証するために、一部の外部サービスでは、受信リクエストにいくつかの方法で秘密の string を含める必要があります。 HTTP Serviceなどの他のサービスでは、オプションでリクエスト検証を要求できます。

Webhook にリクエスト検証が必要な場合は、次のようにします。

  1. リクエスト検証方法を選択します。

  2. リクエスト検証プロセスで使用するSecret string を入力します。

UI のリクエスト検証シークレットの入力
クリックして拡大します
8

Webhook を構成したら、残りは Webhook を呼び出したときに実行される関数を書込むだけです。 App Services は、Webhook 関数の引数として 2 つのオブジェクトを自動的に渡します。

Argument
説明

payload

受信リクエスト ペイロードの EJSON 表現。 ペイロード ドキュメントの内容は、Webhook の起動の原因となったサービスとイベントによって異なります。 特定のサービスのpayloadオブジェクトの説明については、そのサービスのリファレンス ページを参照してください。

response

Webhook を呼び出したクライアントへの応答を構成するHTTP レスポンス オブジェクト。 オブジェクトには、レスポンスのヘッダー、本体、ステータス コードを設定できるメソッドがあります。 これらのメソッドのいずれかを呼び出すと、デフォルトの応答動作が上書きされます。

次の Webhook 関数を、独自の Webhook のベースとして使用できます。

exports = async function (payload, response) {
// Convert the webhook body from BSON to an EJSON object
const body = EJSON.parse(payload.body.text());
// Execute application logic, such as working with MongoDB
if (body.someField) {
const mdb = context.services.get("mongodb-atlas");
const requests = mdb.db("demo").collection("requests");
const { insertedId } = await requests.insertOne({
someField: body.someField,
});
// Respond with an affirmative result
response.setStatusCode(200);
response.setBody(`Successfully saved "someField" with _id: ${insertedId}.`);
} else {
// Respond with a malformed request error
response.setStatusCode(400);
response.setBody(`Could not find "someField" in the webhook request body.`);
}
// This return value does nothing because we already modified the response object.
// If you do not modify the response object and you enable *Respond with Result*,
// App Services will include this return value as the response body.
return { msg: "finished!" };
};

注意

関数エディターから Webhook 関数の応答をデバッグする場合は、関数を実行するときに HTTP 応答オブジェクトを手動で提供する必要があります。

exports(
{ body: "This document is the webhook payload" },
new HTTPResponse()
)
9

Webhook への変更は、有効になる前に保存する必要があります。 そのためには、 Settings画面またはFunction EditorからSaveをクリックします。

重要

CLI のバージョンを確認する

この手順では、 Realm CLIのバージョン 2 を使用します。realm-cli の古いバージョンをお使いの場合は、最新バージョンにアップグレードするか、ご使用のバージョンでサポートされているコマンドのリストを表示するために --help フラグを使用してください。

1

realm-cliを使用して受信 Webhook を定義するには、アプリケーションの構成ファイルのローカル コピーが必要です。

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

realm-cli pull --remote="<Your App ID>"

Tip

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

2

/http_endpoints/<service>/incoming_webhooks/の Webhook と同じ名前で新しいサブディレクトリを作成します。

mkdir -p http_endpoints/<service>/incoming_webhooks/<webhook name>
3

config.jsonという名前の受信 Webhook 構成ファイルを新しい Webhook ディレクトリに追加します。

構成ファイルは、次の形式である必要があります。

http_endpoints/<Service Name>/incoming_webhooks/<Webhook Name>/config.json
{
"name": "<Webhook Name>",
"can_evaluate": { <JSON Expression> },
"run_as_authed_user": <Boolean>,
"run_as_user_id": "<App Services User ID>",
"run_as_user_id_script_source": "<Function Source Code>",
"respond_result": <Boolean>,
"fetch_custom_user_data": <Boolean>,
"create_user_on_auth": <Boolean>,
"options": {
"httpMethod": "<HTTP Method>",
"validationMethod": "<Webhook Validation Method>",
"secret": "<Webhook Secret>"
}
}
4

構成ファイルのnameフィールドに Webhook の名前を入力します。 この名前は、サービス用に作成した他の Webhook と異なる必要があります。

{
"name": "<Unique Webhook Name>"
}
5

App Services が Webhook に使用する認証の種類を指定します。 App Services は次の Webhook 認証方法をサポートしています。

認証方法
説明

アプリケーション認証

このタイプの認証では、各受信リクエストで指定された既存のアプリケーション ユーザー配下で Webhook を実行するように構成されます。 受信リクエストには、リクエスト本文またはリクエスト ヘッダーのいずれかにユーザーの認証プロバイダが含まれている必要があります。

アプリケーション認証を使用するように Webhook を構成するには、 run_as_authed_userの値をtrueに設定します。

{
"run_as_authed_user": true,
"run_as_user_id": "",
"run_as_user_id_script_source": "",
}

次の例は、サポートされている各認証プロバイダーのボディ フィールドまたはヘッダー フィールドとして受信リクエストに含める必要があるフィールド名と値を示しています。

{
"email": "<User's Email Address>",
"password": "<User's Password>"
}
{
"api-key": "<User's API Key>"
}
{
"jwtTokenString": "<User's JWT Token>"
}

重要

ヘッダーとボディ フィールドの両方を使用しない

リクエストのリクエスト ヘッダーとリクエスト本文の両方に認証情報が含まれている場合、App Services はエラーをスローし、関数を実行しません。

システム

このタイプの認証では、MongoDB CRUD および集計 API へのフルアクセス権を持ち、ルール、ロール、または権限の影響を受けないシステムユーザーとして Webhook を実行するように構成されます。

システムユーザーとして実行するように Webhook を構成するには、他の認証フィールドを設定しないでください。

{
"run_as_authed_user": false,
"run_as_user_id": "",
"run_as_user_id_script_source": "",
}

ユーザー ID

このタイプの認証では、常に特定のアプリケーション ユーザーとして Webhook が実行されるように設定されます。

Webhook を常に個別のユーザーとして実行するように設定するには、ユーザーの ID にrun_as_user_idを設定します。

{
"run_as_authed_user": false,
"run_as_user_id": "<App Services User ID>",
"run_as_user_id_script_source": "",
}

スクリプト

このタイプの認証では、定義したカスタム関数の結果に基づいて決定された特定のアプリケーション ユーザーとして Webhook を実行するように構成されます。 この関数は特定のユーザーのid string を返す必要があります。または、 { "runAsSystem": true}を返すことでシステムユーザーを指定することもできます。

関数によって決定されたユーザーとして Webhook を実行するように構成するには、文字列化された関数コードにrun_as_user_id_script_sourceを設定します。

{
"run_as_authed_user": false,
"run_as_user_id": "",
"run_as_user_id_script_source": "<Stringified Function>",
}
6

受信リクエストで特定のHTTPメソッドを使用するよう要求するか、コンテキストの httpMethodプロパティを検査することで、すべてのHTTPメソッドを受け入れ、Webhook 関数でそれぞれを個別に処理することができます。次の例関数のように、オブジェクトをリクエスト

exports = function(payload, response) {
switch(context.request.httpMethod) {
case "GET": { /* Handle GET requests */ }
case "POST": { /* Handle POST requests */ }
case "PUT": { /* Handle PUT requests */ }
case "DELETE": { /* Handle DELETE requests */ }
case "PATCH": { /* Handle PATCH requests */ }
default: {}
}
}

Webhook メソッドを指定するには、すべて大文字を使用してメソッドの名前にoptions.httpMethodフィールドを設定するか、 "ANY"を使用します。

{
"options": {
"httpMethod": "POST"
}
}
7

Webhook を呼び出す外部サービスに、構成可能なHTTPレスポンス を送信できます。受信リクエストに応答を送信するように Webhook を構成するには、respond_resulttrue に設定します。

Respond With Result を有効にすると、Webhook は基本的なHTTP 200 応答で受信リクエストに応答します。この応答には Webhook 関数の戻り値が bodyフィールドとして含まれます。App Services が 2 番目の引数として自動的に渡す responseオブジェクトを使用して、Webhook 関数内からカスタムHTTPレスポンスを構成できます。

8

Can Evaluateを定義することで、各リクエストの内容に基づいてリクエストを動的に認可できます。 Atlas App Services は、Webhook が受け取るすべての受信リクエストに対して式を評価します。 式は、 の展開を含む標準の 式変数 %%requestを展開できます。

認可式を定義するには、 can_evaluateフィールドの値を式に設定します。 式を指定しない場合、Atlas App Services は認証されたすべての受信リクエストを自動的に認可します。

次の式は、アドレスのリストに送信元の IP アドレスが含まれていない場合にのみ、受信リクエストを認可します。

{
"%%request.remoteIPAddress": {
"$nin": [
"248.88.57.58",
"19.241.23.116",
"147.64.232.1"
]
}
}
9

Webhook リクエストが信頼できるソースから送信されたことを検証するために、一部の外部サービスでは、受信リクエストにいくつかの方法で秘密の string を含める必要があります。 HTTP Serviceなどの他のサービスでは、オプションでリクエスト検証を要求できます。

Webhook のリクエスト認証方法は、Webhook 構成のoptionsドキュメントで構成できます。 App Services は次のリクエスト検証メソッドをサポートしています。

方式
説明

追加の承認なし

受信 Webhook リクエストには追加の認可は必要ありません。

{
"validationMethod": "NO_VALIDATION"
}

ペイロード署名の検証

受信 Webhook リクエストには、リクエスト本文のハッシュされた署名と秘密の値が含まれている必要があります。 詳細については、「ペイロード署名の検証 」を参照してください。

{
"validationMethod": "VERIFY_PAYLOAD",
"secret": "<Secret Value>"
}

Require Secret

受信 Webhook リクエストには、Webhook URL のsecretクエリ パラメータとしてシークレット string 値を含める必要があります。 詳細については、 「 クエリ パラメーターとしてシークレット 」を参照してください。

{
"validationMethod": "SECRET_AS_QUERY_PARAM",
"secret": "<Secret Value>"
}
10

source.jsという名前のファイルを新しい Webhook ディレクトリに追加します。 ファイルには、Webhook が呼び出されたときに実行される有効な関数が含まれている必要があります。

App Services は、Webhook 関数の引数として 2 つのオブジェクトを自動的に渡します。

Argument
説明

payload

受信リクエスト ペイロードの EJSON 表現。 ペイロード ドキュメントの内容は、Webhook の起動の原因となったサービスとイベントによって異なります。 特定のサービスのpayloadオブジェクトの説明については、そのサービスのリファレンス ページを参照してください。

response

Webhook を呼び出したクライアントへの応答を構成するHTTP レスポンス オブジェクト。 オブジェクトには、レスポンスのヘッダー、本体、ステータス コードを設定できるメソッドがあります。 これらのメソッドのいずれかを呼び出すと、デフォルトの応答動作が上書きされます。

次の Webhook 関数を、独自の Webhook のベースとして使用できます。

exports = async function (payload, response) {
// Convert the webhook body from BSON to an EJSON object
const body = EJSON.parse(payload.body.text());
// Execute application logic, such as working with MongoDB
if (body.someField) {
const mdb = context.services.get("mongodb-atlas");
const requests = mdb.db("demo").collection("requests");
const { insertedId } = await requests.insertOne({
someField: body.someField,
});
// Respond with an affirmative result
response.setStatusCode(200);
response.setBody(`Successfully saved "someField" with _id: ${insertedId}.`);
} else {
// Respond with a malformed request error
response.setStatusCode(400);
response.setBody(`Could not find "someField" in the webhook request body.`);
}
// This return value does nothing because we already modified the response object.
// If you do not modify the response object and you enable *Respond with Result*,
// App Services will include this return value as the response body.
return { msg: "finished!" };
};
11

config.jsonでクラスターの読み込み設定(read preference)を設定したら、その設定をリモート アプリにプッシュできます。 App Services CLI はプッシュ時に更新をすぐに配置します。

realm-cli push --remote="<Your App ID>"

戻る

サードパーティ サービスの構成

項目一覧