Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Un recurso de webhook permite integrar la canalización con un servicio externo para automatizar el flujo de trabajo.
webhooks:
- webhook: string # Required as first property. Name of the webhook.
connection: string # Required. Name of the connection. In case of offline webhook this will be the type of Incoming Webhook otherwise it will be the type of the webhook extension.
type: string # Name of the webhook extension. Leave this empty if it is an offline webhook.
filters: [ filter ] # List of trigger filters.
Definiciones que hacen referencia a esta definición: resources.webhooks
Propiedades
webhook
cadena. Obligatorio como primera propiedad.
Nombre del webhook. Valores aceptables: [-_A-Za-z0-9]*.
Para el webhook de Azure DevOps, webhook
siempre debe ser .WebHook
connection
cadena. Obligatorio.
Nombre de la conexión. En caso de webhook sin conexión, este será el tipo de Webhook entrante; de lo contrario, será el tipo de la extensión de webhook.
type
cadena.
Nombre de la extensión de webhook. Deje esto vacío si es un webhook sin conexión.
filters
resources.webhooks.webhook.filters.
Lista de filtros de desencadenador.
Ejemplos
Ejemplo básico
Puede definir la canalización de la siguiente manera.
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
Para desencadenar la canalización mediante el webhook, debe realizar una POST
solicitud a https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
.
El nombre del webHook debe coincidir con el de la conexión de servicio de webHook entrante.
Este punto de conexión está disponible públicamente y no se necesita ninguna autorización. La solicitud debe tener el siguiente cuerpo.
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
Al acceder a los datos desde el cuerpo de la solicitud del webhook, tenga en cuenta que puede provocar un YAML incorrecto. Por ejemplo, si en la canalización anterior, el paso lee - script: echo ${{ parameters.WebHook.resource.message }}
y desencadena la canalización a través de un webhook, la canalización no se ejecuta. Esto se debe a que, en el proceso de reemplazar ${{ parameters.WebHook.resource.message.title }}
por message
, que contiene el siguiente JSON, el YAML generado deja de ser válido.
{
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
Dado que el YAML generado no es válido, no se pone en cola ninguna ejecución de canalización en respuesta.
Impedir ejecuciones de canalizaciones no autorizadas
Los webhooks permiten a cualquier persona desencadenar la canalización, siempre y cuando conozcan los nombres de la organización y la conexión de servicio de webhook.
Puede evitar ejecuciones de canalizaciones no autorizadas mediante la definición de un secreto al crear una conexión de servicio de webhook entrante. También debe especificar el nombre del encabezado HTTP que contiene la suma de comprobación SHA-1 del cuerpo del webhook.
Para comprobar que se autoriza una llamada entrante a la API REST de webhook, Azure Pipelines calcula la suma de comprobación SHA-1 del cuerpo de la solicitud mediante el secreto como clave. A continuación, lo compara con la suma de comprobación pasada en el encabezado de solicitud. De este modo, el autor de la llamada demuestra que conocen el secreto.
Veamos un ejemplo. Supongamos que configuró una conexión de servicio de webhook entrante denominada IncomingWH
, especificó que el secreto es secret
y que la suma de comprobación se envía en el encabezado HTTP denominado X-WH-Checksum
. Imagine que tiene una canalización que define un recurso de Webhook.
Supongamos que desea desencadenar la canalización mediante el siguiente cuerpo de solicitud:
{"resource":{"message":{"title":"Hello, world!","subtitle":"I'm using WebHooks!"}}}
Para ello, debe realizar una POST
solicitud a https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/IncomingWH?api-version=6.0-preview
y agregar el X-WH-Checksum
encabezado con el valor de 750D33212D3AD4932CC390819050734831A0A94F
. No es necesario especificar ningún nombre de usuario y contraseña ni ningún otro tipo de información de autenticación.
Azure Pipelines calculará de forma independiente la suma de comprobación SHA-1 del cuerpo mediante secret
como clave y generará el mismo 750D33212D3AD4932CC390819050734831A0A94F
valor. Dado que los valores coinciden, la llamada está autorizada y la cola de canalización continúa.
Calcula el valor del X-WH-Checksum
encabezado, en pseudocódigo, como SHA1(secret).ComputeHash(requestBody)
. Puede usar . La clase de System.Security.Cryptography.HMACSHA1
NET para este propósito.
Para evitar errores de validación debido a nuevas líneas o espacios en blanco, se recomienda enviar el cuerpo en un formulario minimizado. Es decir, enviar
{"resource":{"message":{"title":"Hello, world!","subtitle":"I'm using WebHooks!"}}}
En lugar de
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
Aunque los dos objetos JSON anteriores representan el mismo objeto, generan sumas de comprobación SHA-1 diferentes. Esto se debe a que SHA-1 se calcula en su representación de cadena, que es diferente.