Docs Menu
Docs Home
/ /
Servicios de terceros

Configurar webhooks de servicio

Importante

Servicios de terceros y notificaciones push obsoletos

Los servicios de terceros y las notificaciones push en App Services han quedado obsoletos en favor de la creación de puntos finales HTTP que usan dependencias externas en funciones.

Los webhooks se han renombrado como puntos finales HTTPS sin cambios en su comportamiento. Debe migrar los webhooks existentes.

Los servicios existentes continuarán funcionando hasta el de septiembre 30 2025de.

Dado que los servicios de terceros y las notificaciones push ya no se utilizan, se han eliminado de forma predeterminada de la interfaz de usuario de App Services. Si necesita administrar un servicio de terceros o una notificación push existente, puede volver a agregar las configuraciones a la interfaz de usuario siguiendo estos pasos:

  • En la navegación izquierda, debajo del Manage sección, haga clic en App Settings.

  • Habilite el interruptor junto a Temporarily Re-Enable 3rd Party Services y luego guarde los cambios.

Algunos servicios externos permiten crear webhooks entrantes a los que los clientes externos pueden acceder mediante HTTP. Puedes crear webhooks para estos servicios desde la interfaz de usuario de App Services o con la CLI de App Services. Selecciona la pestaña a continuación que corresponda al método que desees usar.

1

Los webhooks entrantes se limitan a servicios individuales. Puedes crear y administrar un webhook desde su página de servicio asociada en la interfaz de usuario de App Services.

Para crear un webhook entrante:

  1. Haga clic en Services en el menú de navegación de la izquierda.

  2. Haga clic en el servicio para el cual desea agregar un webhook entrante.

  3. Seleccione la pestaña Incoming Webhooks para el servicio.

  4. Haga clic en Add Incoming Webhook. App Services lo redireccionará a la pantalla Settings para el nuevo webhook.

2

Introduzca un nombre único e identificativo para el webhook en el campo Webhook Name. Este nombre debe ser distinto al de cualquier otro webhook que haya creado para el servicio.

3

Las funciones de Atlas, incluidos los webhooks, siempre se ejecutan en el contexto de un usuario específico de la aplicación o como usuario del sistema, lo que omite las reglas. Para configurar el usuario de ejecución del webhook, especifique el tipo de autenticación que App Services debe usar para el webhook.

Tipo de autenticación
Descripción

Autenticación de aplicaciones

Este tipo de autenticación configura un webhook para que se ejecute en el contexto de un usuario de la aplicación existente, especificado en cada solicitud entrante. Las solicitudes entrantes deben incluir las credenciales del proveedor de autenticación del usuario en el cuerpo o en los encabezados de la solicitud.

Los siguientes ejemplos muestran los nombres de campo y los valores para cada proveedor de autenticación compatible:

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

Importante

No utilice campos de encabezado y cuerpo al mismo tiempo

Si una solicitud incluye credenciales tanto en los encabezados como en el cuerpo de la solicitud, App Services genera un error y no ejecuta la función.

Nota

Usuarios de la aplicación

Puede configurar un webhook que utilice la autenticación de la aplicación para realizar trabajo adicional relacionado con el usuario para cada solicitud:

  • Si Fetch Custom User Data habilita, App Services consulta los datos de usuario personalizados del usuario solicitante y, si existen, expone los datos como un objeto en el context.user.custom_data propiedad.

  • Si habilita Create User Upon Authentication, App Services creará automáticamente un nuevo usuario basado en las credenciales proporcionadas si no coinciden con las de un usuario ya existente. El proveedor de autenticación correspondiente a las credenciales debe estar habilitado al momento de la solicitud para crear un nuevo usuario.

Sistema

Este tipo de autenticación configura un webhook para que se ejecute como el usuario del sistema, que tiene acceso total a las APIs de MongoDB CRUD y Agregación y no está sujeto a reglas, roles ni permisos.

ID de usuario

Este tipo de autenticación configura un webhook para que siempre se ejecute como un usuario de aplicación específico.

Guión

Este tipo de autenticación configura un webhook para que se ejecute como un usuario específico de la aplicación, determinado por el resultado de una función personalizada que usted defina. La función debe devolver la cadena de un usuario específico id o puede especificar un usuario del sistema { "runAsSystem": true } devolviendo.

La entrada del tipo de autenticación del usuario en la interfaz de usuario
haga clic para ampliar
4

Puede exigir que las solicitudes entrantes utilicen un método específico Método HTTPo puede aceptar todos los métodos HTTP y manejar cada uno individualmente en la función webhook inspeccionando la httpMethod propiedad en el objeto context.request, como en la siguiente función de ejemplo:

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: {}
}
}
La entrada desplegable del método HTTP en la interfaz de usuario
5

Puede enviar una respuesta HTTP configurable a servicios externos que llaman al webhook.

Si Respond With Result habilita, el webhook responderá a las solicitudes entrantes con una respuesta HTTP 200 básica que incluye el valor de retorno de la función del webhook como su body campo. Puede configurar una respuesta HTTP personalizada desde la función del webhook usando el response objeto que App Services pasa automáticamente como segundo argumento.

El interruptor para responder con resultado en la interfaz de usuario
haga clic para ampliar
6

Puedes autorizar solicitudes dinámicamente según el contenido de cada una definiendo una Can Evaluate expresión. App Services evalúa la expresión para cada solicitud entrante que recibe el webhook. Si no especificas una expresión, App Services autoriza automáticamente todas las solicitudes entrantes autenticadas.

La expresión puede expandir variables de expresión estándar, incluida la %%request expansión.

La entrada de expresión JSON del webhook puede evaluarse en la interfaz de usuario
haga clic para ampliar
7

Para validar que una solicitud de webhook se envió desde una fuente confiable, algunos servicios externos requieren que las solicitudes entrantes incorporen una cadena secreta de una de varias maneras prescritas. Otros servicios, como el servicio HTTP, permiten solicitar la validación de la solicitud de forma opcional.

Si su webhook requiere validación de solicitud:

  1. Seleccione el método de validación de la solicitud.

  2. Introduce una string Secret para usar en el proceso de validación de la solicitud.

La entrada secreta de validación de solicitud en la interfaz de usuario
haga clic para ampliar
8

Una vez configurado el webhook, solo queda escribir la función que se ejecuta al llamarlo. App Services pasa automáticamente dos objetos como argumentos de la función del webhook:

Argument
Descripción

payload

Una representación EJSON de la carga útil de la solicitud entrante. El contenido del documento de carga útil variará según el servicio y el evento que provocó la activación del webhook. Para obtener una descripción del objeto payload de un servicio específico, consulte la página de referencia de ese servicio.

response

Un objeto de respuesta HTTP que configura la respuesta al cliente que llamó al webhook. Este objeto incluye métodos que permiten configurar los encabezados, el cuerpo y el código de estado de la respuesta. Llamar a cualquiera de estos métodos anula el comportamiento predeterminado de la respuesta.

Puede utilizar la siguiente función de webhook como base para su propio 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!" };
};

Nota

Si desea depurar una respuesta de función de webhook desde el editor de funciones, debe proporcionar manualmente el objeto de respuesta HTTP cuando ejecute la función.

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

Debes guardar los cambios en tu webhook para que surtan efecto. Para ello, haz clic en Save desde la pantalla Settings o en Function Editor.

Importante

Comprueba tu versión de CLI

Este procedimiento utiliza la versión 2 de la CLI de Realm. Si tiene una versión anterior de realm-cli, actualice a la última versión o use el indicador --help para ver una lista de los comandos compatibles con su versión.

1

Para definir un webhook entrante con realm-cli, necesita una copia local de los archivos de configuración de su aplicación.

Para extraer una copia local de la última versión de su aplicación, ejecute lo siguiente:

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

Tip

También puedes descargar una copia de los archivos de configuración de tu aplicación desde la pantalla Deploy > Export App en la Interfaz de usuario Realm.

2

Cree un nuevo subdirectorio con el mismo nombre que el webhook en /http_endpoints/<service>/incoming_webhooks/:

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

Agregue un archivo de configuración de webhook config.json entrante llamado al nuevo directorio de webhook.

El archivo de configuración debe tener el siguiente formato:

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

Introduzca un nombre para el webhook en el campo name del archivo de configuración. Este nombre debe ser distinto al de cualquier otro webhook que haya creado para el servicio.

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

Especifique el tipo de autenticación que App Services debe usar para el webhook. App Services admite los siguientes métodos de autenticación de webhook:

Método de autenticación
Descripción

Autenticación de aplicaciones

Este tipo de autenticación configura un webhook para que se ejecute en el contexto de un usuario de la aplicación existente, especificado en cada solicitud entrante. Las solicitudes entrantes deben incluir las credenciales del proveedor de autenticación del usuario en el cuerpo o en los encabezados de la solicitud.

Para configurar un webhook para utilizar la autenticación de la aplicación, establezca el valor de run_as_authed_user en true:

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

Ejemplo

Los siguientes ejemplos demuestran los nombres de campo y los valores que las solicitudes entrantes deben incluir como campos de cuerpo o encabezado para cada proveedor de autenticación compatible:

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

Importante

No utilice campos de encabezado y cuerpo al mismo tiempo

Si una solicitud incluye credenciales tanto en los encabezados como en el cuerpo de la solicitud, App Services genera un error y no ejecuta la función.

Sistema

Este tipo de autenticación configura un webhook para que se ejecute como el usuario del sistema, que tiene acceso total a las APIs de MongoDB CRUD y Agregación y no está sujeto a reglas, roles ni permisos.

Para configurar un webhook para que se ejecute como un usuario del sistema, no configure ningún otro campo de autenticación:

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

ID de usuario

Este tipo de autenticación configura un webhook para que siempre se ejecute como un usuario de aplicación específico.

Para configurar un webhook para que siempre se ejecute como un usuario específico, configure run_as_user_id en el ID del usuario:

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

Guión

Este tipo de autenticación configura un webhook para que se ejecute como un usuario específico de la aplicación, determinado según el resultado de una función personalizada que usted defina. La función debe devolver la cadena de un usuario específico id o puede especificar un usuario del sistema { "runAsSystem": true} devolviendo.

Para configurar un webhook para que se ejecute como un usuario determinado por una función, configure run_as_user_id_script_source en el código de función en cadena:

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

Puede requerir que las solicitudes entrantes utilicen un método HTTP específico o puede aceptar todos los métodos HTTP y manejar cada uno individualmente en la función webhook inspeccionando la httpMethod propiedad en el objeto context.request, como en la siguiente función de ejemplo:

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: {}
}
}

Para especificar un método webhook, configure el campo options.httpMethod con el nombre del método usando todas letras mayúsculas o "ANY".

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

Puede enviar una respuesta HTTP configurable a los servicios externos que llaman al webhook. Para configurar el webhook y que envíe una respuesta a las solicitudes entrantes,respond_result configure true en.

Si Respond With Result habilita, el webhook responderá a las solicitudes entrantes con una respuesta HTTP 200 básica que incluye el valor de retorno de la función del webhook como su body campo. Puede configurar una respuesta HTTP personalizada desde la función del webhook usando el response objeto que App Services pasa automáticamente como segundo argumento.

8

Puede autorizar solicitudes dinámicamente según el contenido de cada solicitud al definir una Can Evaluate expresión. App Services evalúa la expresión para cada solicitud entrante que recibe el webhook. La expresión puede expandir variables de expresión estándar, incluida la expansión %%request.

Para definir una expresión de autorización, asigne el valor del campo can_evaluate a la expresión. Si no especifica ninguna expresión, App Services autoriza automáticamente todas las solicitudes entrantes autenticadas.

Ejemplo

La siguiente expresión solo autoriza solicitudes entrantes si la dirección IP del remitente no está incluida en la lista de direcciones.

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

Para validar que una solicitud de webhook se envió desde una fuente confiable, algunos servicios externos requieren que las solicitudes entrantes incorporen una cadena secreta de una de varias maneras prescritas. Otros servicios, como el servicio HTTP, permiten solicitar la validación de la solicitud de forma opcional.

Puede configurar el método de autorización de solicitudes de un webhook en el options documento de la configuración del webhook. App Services admite los siguientes métodos de validación de solicitudes:

Método
Descripción

Sin autorización adicional

Las solicitudes de webhook entrantes no requieren autorización adicional.

{
"validationMethod": "NO_VALIDATION"
}

Verificar la firma de la carga útil

Las solicitudes de webhook entrantes deben incluir una firma hash del cuerpo de la solicitud y un valor secreto. Para más información, consulte Verificación de la firma de la carga útil.

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

Requerir secreto

Las solicitudes de webhook entrantes deben incluir un valor de cadena secreta como secret parámetro de consulta en la URL del webhook. Para obtener más información, consulte "Secreto como parámetro de consulta".

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

Agregue un archivo llamado source.js al nuevo directorio del webhook. El archivo debe contener una función válida que se ejecute al llamar al webhook.

App Services pasa automáticamente dos objetos como argumentos de la función webhook:

Argument
Descripción

payload

Una representación EJSON de la carga útil de la solicitud entrante. El contenido del documento de carga útil variará según el servicio y el evento que provocó la activación del webhook. Para obtener una descripción del objeto payload de un servicio específico, consulte la página de referencia de ese servicio.

response

Un objeto de respuesta HTTP que configura la respuesta al cliente que llamó al webhook. Este objeto incluye métodos que permiten configurar los encabezados, el cuerpo y el código de estado de la respuesta. Llamar a cualquiera de estos métodos anula el comportamiento predeterminado de la respuesta.

Puede utilizar la siguiente función de webhook como base para su propio 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

Una vez que haya configurado la preferencia de lectura para el clúster en config.json, puede enviar la configuración a su aplicación remota. La CLI de App Services implementa la actualización inmediatamente al enviarla.

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

Volver

Configurar servicios de terceros

En esta página