サービス Webhook の構成 [非推奨]
重要
サードパーティ サービスとプッシュ通知の廃止
Atlas App Services のサードパーティ サービスとプッシュ通知は非推奨となり、代わりに関数内の外部依存関係を使用する HTTP エンドポイントを作成できるようになりました。
Webhook はHTTPS endpointsに名前変更され、動作は変更されません。 既存の Webhook を移行する必要があります。
既存のサービスは、 30、2025 まで引き続き機能します。
サードパーティ サービスとプッシュ通知は非推奨になったため、App Services UI からデフォルトで削除されました。 既存のサードパーティ サービスまたはプッシュ通知を管理する必要がある場合は、次の操作を実行して構成を UI に追加できます。
左側のナビゲーションの [ App Settings Manageセクションの下にある [] をクリックします。
Temporarily Re-Enable 3rd Party Servicesの横にあるトグル スイッチを有効にし、変更を保存します。
Overview
一部の外部サービスでは、外部クライアントが HTTP 経由で呼び出せる受信 Webhookを作成できます。 App Services UI または App Services CLI を使用して、これらのサービスの Webhook を作成できます。 使用する方法に対応する以下のタブを選択します。
手順
新しい Webhook を設定する
受信する Webhook の範囲は個々のサービスに限定されます。 App Services UI の関連するサービス ページから Webhook を作成および管理できます。
受信 Webhook を作成するには、次の手順に従います。
左側のナビゲーション メニューで [ Servicesをクリックします。
受信 Webhook を追加するサービスをクリックします。
サービスの [ Incoming Webhooks ] タブを選択します。
[ Add Incoming Webhookをクリックします。 App Services は新しい Webhook のSettings画面にリダイレクトします。
ユーザー認証の設定
Webhook を含む Atlas 関数は常に特定のアプリケーションユーザーのコンテキストで、またはシステムユーザーとして実行され、ルールをバイパスします。 Webhook の実行ユーザーを構成するには、App Services が Webhook に使用する認証のタイプを指定します。
認証タイプ | 説明 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
アプリケーション認証 | このタイプの認証では、各受信リクエストで指定された既存のアプリケーション ユーザー配下で Webhook を実行するように構成されます。 受信リクエストには、リクエスト本文またはリクエスト ヘッダーのいずれかにユーザーの認証プロバイダが含まれている必要があります。 次の例は、サポートされている各認証プロバイダのフィールド名と値を示しています。
重要ヘッダーとボディ フィールドの両方を使用しないリクエストのリクエスト ヘッダーとリクエスト本文の両方に認証情報が含まれている場合、App Services はエラーをスローし、関数を実行しません。 注意アプリケーション ユーザーアプリケーション認証を使用する Webhook を設定して、リクエストごとに追加のユーザー関連の作業を実行できます。
| ||||||||||
システム | このタイプの認証では、MongoDB CRUD および集計 API へのフルアクセス権を持ち、ルール、ロール、または権限の影響を受けないシステムユーザーとして Webhook を実行するように構成されます。 | ||||||||||
ユーザー ID | このタイプの認証では、常に特定のアプリケーション ユーザーとして Webhook が実行されるように設定されます。 | ||||||||||
スクリプト | このタイプの認証では、定義したカスタム関数の結果によって決定された特定のアプリケーション ユーザーとして Webhook を実行するように構成されます。 この関数は特定のユーザーの id string を返す必要があります。または、 { "runAsSystem": true } を返すことでシステムユーザーを指定することもできます。 |
Webhook の HTTP メソッドを選択する
受信リクエストで特定の HTTP メソッドhttpMethod
を使用するように要求できます。 または、次の例の関数のように context.request オブジェクトの プロパティを検査することで、すべての 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 応答の構成
構成可能な HTTP 応答 を送信できます Webhook を呼び出す外部サービスに渡す追加サービス。
Respond With Resultを有効にすると、Webhook は基本的な HTTP200 で受信リクエストに応答します Webhook 関数の戻り値をbody
フィールドとして含む応答。App Services が 2 番目の引数として自動的に渡すresponse
オブジェクトを使用して、Webhook 関数内からカスタム HTTP レスポンスを構成できます。
リクエスト検証方法の指定
Webhook リクエストが信頼できるソースから送信されたことを検証するために、一部の外部サービスでは、受信リクエストにいくつかの方法で秘密の string を含める必要があります。 HTTP Serviceなどの他のサービスでは、オプションでリクエスト検証を要求できます。
Webhook にリクエスト検証が必要な場合は、次のようにします。
リクエスト検証プロセスで使用するSecret string を入力します。
Webhook 関数の記述
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() )
重要
CLI のバージョンを確認する
この手順では、Realm CLI [非推奨] のバージョン2を使用します。 realm-cli
の古いバージョンがある場合は、最新バージョンにアップグレードするか、ご使用のバージョンでサポートされているコマンドのリストを表示するために--help
フラグを使用します。
Webhook 構成ファイルの追加
config.json
という名前の受信 Webhook 構成ファイルを新しい Webhook ディレクトリに追加します。
構成ファイルは、次の形式である必要があります。
{ "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>" } }
ユーザー認証の設定
App Services が Webhook に使用する認証の種類を指定します。 App Services は次の Webhook 認証方法をサポートしています。
認証方法 | 説明 | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
アプリケーション認証 | このタイプの認証では、各受信リクエストで指定された既存のアプリケーション ユーザー配下で Webhook を実行するように構成されます。 受信リクエストには、リクエスト本文またはリクエスト ヘッダーのいずれかにユーザーの認証プロバイダが含まれている必要があります。 アプリケーション認証を使用するように Webhook を構成するには、
例次の例は、サポートされている各認証プロバイダーのボディ フィールドまたはヘッダー フィールドとして受信リクエストに含める必要があるフィールド名と値を示しています。
重要ヘッダーとボディ フィールドの両方を使用しないリクエストのリクエスト ヘッダーとリクエスト本文の両方に認証情報が含まれている場合、App Services はエラーをスローし、関数を実行しません。 | |||||||||||||||
システム | このタイプの認証では、MongoDB CRUD および集計 API へのフルアクセス権を持ち、ルール、ロール、または権限の影響を受けないシステムユーザーとして Webhook を実行するように構成されます。 システムユーザーとして実行するように Webhook を構成するには、他の認証フィールドを設定しないでください。
| |||||||||||||||
ユーザー ID | このタイプの認証では、常に特定のアプリケーション ユーザーとして Webhook が実行されるように設定されます。 Webhook を常に個別のユーザーとして実行するように設定するには、ユーザーの ID に
| |||||||||||||||
スクリプト | このタイプの認証では、定義したカスタム関数の結果に基づいて決定された特定のアプリケーション ユーザーとして Webhook を実行するように構成されます。 この関数は特定のユーザーの 関数によって決定されたユーザーとして Webhook を実行するように構成するには、文字列化された関数コードに
|
Webhook の HTTP メソッドを指定する
受信リクエストが特定の HTTP メソッド を使用することを要求できます または、次の例の関数のようにhttpMethod
context.request オブジェクトの プロパティを検査することで、すべての 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" } }
Webhook 応答の構成
構成可能な HTTP 応答 を送信できます Webhook を呼び出す外部サービスに渡す追加サービス。受信リクエストに応答を送信するように Webhook を構成するには、 respond_result
をtrue
に設定します。
Respond With Resultを有効にすると、Webhook は基本的な HTTP200 で受信リクエストに応答します Webhook 関数の戻り値をbody
フィールドとして含む応答。App Services が 2 番目の引数として自動的に渡すresponse
オブジェクトを使用して、Webhook 関数内からカスタム HTTP レスポンスを構成できます。
承認式の指定
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" ] } }
リクエスト検証方法の指定
Webhook リクエストが信頼できるソースから送信されたことを検証するために、一部の外部サービスでは、受信リクエストにいくつかの方法で秘密の string を含める必要があります。 HTTP Serviceなどの他のサービスでは、オプションでリクエスト検証を要求できます。
Webhook のリクエスト認証方法は、Webhook 構成のoptions
ドキュメントで構成できます。 App Services は次のリクエスト検証メソッドをサポートしています。
方式 | 説明 | ||||
---|---|---|---|---|---|
追加の承認なし | 受信 Webhook リクエストには追加の認可は必要ありません。
| ||||
ペイロード署名の検証 | 受信 Webhook リクエストには、リクエスト本文のハッシュされた署名と秘密の値が含まれている必要があります。 詳細については、「ペイロード署名の検証 」を参照してください。
| ||||
Require Secret | 受信 Webhook リクエストには、Webhook URL の
|
Webhook 関数のソースコードを追加する
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!" }; };