Partilhar via


Receber notificações de alteração através de webhooks

Um webhook é uma API de chamada de retorno definida pelo utilizador baseada em HTTP que pode configurar na sua infraestrutura para receber notificações de alteração e eventos de um serviço, como o Microsoft Graph. Para utilizar webhooks, tem de definir um ponto final protegido por HTTPS acessível publicamente que receba as notificações.

Pode criar uma subscrição para o recurso para o qual quer ser notificado sobre as alterações. Embora a subscrição seja válida, o Microsoft Graph envia uma notificação para o ponto final sempre que detetar uma alteração no recurso.

O artigo orienta-o ao longo do processo de implementação do ponto final do webhook, da subscrição e gestão de subscrições do Microsoft Graph e de como receber notificações de alteração através de webhooks.

Para obter detalhes sobre como criar notificações de alteração, consulte Notificações de alteração do Microsoft API do Graph.

Considerações para um ponto final de webhook

Antes de poder receber uma notificação através de webhooks, tem de criar um ponto final acessível publicamente protegido por HTTPS que seja endereçável através de URL. Se o ponto final não estiver acessível publicamente, o Microsoft Graph não envia notificações para o ponto final.

O ponto final tem de fornecer respostas HTTP corretas, consistentes e atempadamente para receber notificações de forma fiável. Se um ponto final não responder em tempo útil, o serviço de notificação de alteração poderá começar a remover as notificações. As notificações removidas não podem ser recuperadas.

O ponto final também tem de continuar a ser autenticado no Microsoft Graph, ao renovar continuamente a sua subscrição ou ao responder a notificações de ciclo de vida.

Códigos HTTP e lógica de repetição

Assim que o serviço de notificações de alteração do Microsoft Graph receber um código de classe 2xx do ponto final, a notificação é considerada enviada. Desde que o serviço de notificações de alteração receba qualquer outra resposta HTML (mesmo um código de erro) dentro de 10 segundos, o serviço continua a tentar entregar a notificação durante um máximo de 4 horas.

  • Se conseguir processar a notificação numa janela de 3 segundos, deve devolver um 200 - OK código de status ao Microsoft Graph
  • Se o serviço demorar mais de 10 segundos a processar a notificação, poderá optar por manter a notificação numa fila no ponto final e devolver 202 - Accepted status código ao Microsoft Graph.
  • Se a notificação não for processada ou em fila, devolva um código de classe 5xx para indicar um erro para que o Microsoft Graph possa repetir a notificação.

As notificações que não são entregues são repetidas em intervalos de trás exponenciais. As notificações perdidas podem demorar até 4 horas a reenviar assim que o ponto final ficar online.

Limitação

Por motivos de segurança e desempenho, o Microsoft Graph limita as notificações enviadas para pontos finais que ficam lentas ou não respondem. Pode incluir a remoção de notificações de uma forma que não podem ser recuperadas.

  1. Um ponto final é marcado como "lento" uma vez que mais de 10% das respostas demoram mais de 10 segundos numa janela de 10 minutos.

    • Assim que um ponto final estiver marcado como "lento", todas as novas notificações são enviadas com um atraso de 10 segundos.
    • Um ponto final sai do estado "lento" uma vez que menos de 10% das respostas demoram mais de 10 segundos numa janela de 10 minutos.
  2. Um ponto final é marcado como "drop" uma vez que mais de 15% das respostas demoram mais de 10 segundos numa janela de 10 minutos.

    • Depois de um ponto final ser marcado como "drop", todas as novas notificações são removidas durante um máximo de 10 minutos
    • Um ponto final sai do estado "drop" uma vez que menos de 15% das respostas demoram mais de 10 segundos numa janela de 10 minutos.

Se o ponto final não conseguir cumprir estas características de desempenho, considere utilizar os Hubs de Eventos ou o Event Grid como destino para receber notificações.

Autenticação

Quando cria a sua subscrição, é enviado um token de acesso para o ponto final. Este token de acesso é utilizado apenas para marcar a validade do ponto final e tem um ciclo de vida diferente do ciclo de vida da subscrição de notificação de alteração. Geralmente, este token de acesso expira dentro de 1 hora.

O ponto final tem de estar preparado para ser reautorizado regularmente pelo Microsoft Graph para garantir que o Microsoft Graph pode continuar a entregar notificações ao ponto final.

Se um token de acesso expirar, as notificações não serão entregues. No entanto, não aciona o comportamento de limitação de pontos finais e o Microsoft Graph continua a tentar enviar cada notificação durante um máximo de 4 horas. Por isso, se o token de acesso for atualizado no prazo de 4 horas após a expiração, serão entregues notificações não enviadas.

Recomenda-se que adicione notificações de ciclo de vida à sua subscrição para receber um aviso sobre a expiração do token para que possa reautorizar o ponto final em tempo útil.

Quando renovar a sua subscrição, o token de acesso também é atualizado.

Configuração do firewall

Pode configurar a firewall que protege o ponto final para permitir ligações de entrada apenas do Microsoft Graph, o que reduz a exposição a notificações de alteração inválidas. Para obter uma lista completa de endereços IP usados pelo Microsoft Graph para oferecer notificações de alteração, confira pontos de extremidade adicionais para Microsoft 365.

Observação

Os endereços IP listados que são usados para fornecer notificações de alteração podem ser atualizados a qualquer momento sem aviso prévio.

Criar uma assinatura

Importante

São necessários vários passos para garantir que um canal de comunicação seguro é estabelecido e mantido entre o serviço de notificações de alteração do Microsoft Graph e o ponto final.

Para começar a receber notificações de alteração do Microsoft Graph, tem de criar uma subscrição com o URL do ponto final (URL de notificação) para estabelecer a subscrição. O padrão de estabelecer uma subscrição é o seguinte:

  1. A aplicação cliente envia um pedido de subscrição para subscrever alterações num recurso específico.

  2. O Microsoft Graph verifica o pedido.

    • Se o pedido for válido, o Microsoft Graph envia um token de validação para o URL de notificação da aplicação cliente para validar o URL de notificação.
    • Se o pedido for inválido, o Microsoft Graph envia uma resposta de erro com um código de erro e detalhes.
  3. Quando o cliente recebe o pedido de validação do URL de notificação, o cliente responde com o token de validação em texto simples.

  4. O Microsoft Graph valida a resposta do token de validação do cliente e, se o token de validação for válido, responde com um ID de subscrição.

Pedido de subscrição

A aplicação cliente envia um pedido POST para o /subscriptions ponto final. O exemplo seguinte mostra um pedido básico para subscrever alterações a uma pasta de correio específica em nome do utilizador com sessão iniciada. Para obter mais informações sobre outros recursos do Microsoft Graph que suportam notificações de alteração, veja recursos suportados.

POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json

{
  "changeType": "created,updated",
  "notificationUrl": "https://webhook.azurewebsites.net/notificationClient",
  "lifecycleNotificationUrl": "https://webhook.azurewebsites.net/api/lifecycleNotifications",
  "resource": "/me/mailfolders('inbox')/messages",
  "expirationDateTime": "2016-03-20T11:00:00.0000000Z",
  "clientState": "SecretClientState"
}

A propriedade clientState é necessária. Definir a propriedade permite que o seu serviço confirme que as notificações de alteração que recebe têm origem no Microsoft Graph. Por esse motivo, o valor da propriedade deve continuar em segredo e deve ser conhecido somente por seu aplicativo e pelo serviço do Microsoft Graph.

Se tiver êxito, o Microsoft Graph retornará um código 201 Created e um objeto subscription no corpo.

Cada subscrição tem um subscriptionId exclusivo, mesmo que tenha várias subscrições que monitorizem o mesmo recurso e utilizem o mesmo URL de notificação.

Observação

Qualquer parâmetro de cadeia de consulta incluído na propriedade notificationUrl é incluído no pedido HTTP POST quando as notificações estão a ser entregues ao seu serviço.

Não são permitidas subscrições duplicadas. Quando um pedido de subscrição contém os mesmos valores para changeType e recurso que uma subscrição existente, o pedido falha com um código 409 Conflictde erro HTTP e a mensagem Subscription Id <> already exists for the requested combinationde erro .

validação notificationUrl

Quando envia um pedido para criar uma subscrição para receber notificações de alteração através de webhooks, o serviço de subscrição verifica se a propriedade notificationUrl no pedido de subscrição é válida. O processo de validação funciona da seguinte forma:

Observação

Se também estiver a subscrever notificações de ciclo de vida , o serviço de subscrição também valida o ciclo de vidaNotificationUrl.

  1. Quando uma subscrição é pedida, o Microsoft Graph codifica um token de validação e inclui-o num pedido POST para o URL de notificação da seguinte forma.

    Content-Type: text/plain; charset=utf-8
    POST https://{notificationUrl}?validationToken={opaqueTokenCreatedByMicrosoftGraph}
    
  2. O cliente tem de descodificar corretamente o URL para obter o token de validação de texto simples do Microsoft Graph.

    A fuga de qualquer HTML ou JavaScript é uma boa prática, uma vez que os atores maliciosos podem utilizar o ponto final de notificação para ataques de scripting entre sites. O Microsoft Graph nunca envia nenhum valor contendo código HTML ou JavaScript.

    Em geral, trate o valor do token de validação como opaco, uma vez que o formato do token pode ser alterado sem aviso prévio.

  3. O cliente tem de responder com as seguintes características dentro de 10 segundos do passo 1:

    • Um código de status de HTTP 200 OK.
    • Um tipo de conteúdo de text/plain.
    • Um corpo que inclui o token de validação de texto simples descodificado do URL .

    Importante

    O token de validação tem de ser devolvido em texto simples. Se o cliente retornar um token de validação codificado, a validação falhará.

  4. Se a validação do ponto final falhar, o Microsoft Graph não cria a subscrição.

Receber notificações

Embora a subscrição seja válida e existam alterações ao recurso que subscreveu, o Microsoft Graph envia um POST pedido ao notificationUrl com detalhes das alterações. Este payload é a notificação de alteração.

Para a maioria das subscrições, o Microsoft Graph não atrasa o envio de notificações, mas entrega todas as notificações no SLA, a menos que o serviço esteja a ter um incidente.

Um payload de notificação de alteração enviado para o ponto final pode conter uma coleção de notificações de alteração relacionadas com as suas subscrições.

Exemplo de notificação de alteração

Quando o utilizador recebe um e-mail, o Microsoft Graph envia um objeto de notificação de alteração para a aplicação cliente, conforme mostrado no exemplo seguinte. Veja changeNotificationCollection e a alteração relacionadaNotificação para obter detalhes do payload de notificação.

Quando várias alterações ocorrerem, o Microsoft Graph poderá enviar várias notificações que correspondam a diferentes assinaturas na mesma solicitação POST.

{
  "value": [
    {
      "id": "lsgTZMr9KwAAA",
      "subscriptionId":"{subscription_guid}",
      "subscriptionExpirationDateTime":"2016-03-19T22:11:09.952Z",
      "clientState":"secretClientValue",
      "changeType":"created",
      "resource":"users/{user_guid}@{tenant_guid}/messages/{long_id_string}",
      "tenantId": "84bd8158-6d4d-4958-8b9f-9d6445542f95",
      "resourceData":
      {
        "@odata.type":"#Microsoft.Graph.Message",
        "@odata.id":"Users/{user_guid}@{tenant_guid}/Messages/{long_id_string}",
        "@odata.etag":"W/\"CQAAABYAAADkrWGo7bouTKlsgTZMr9KwAAAUWRHf\"",
        "id":"{long_id_string}"
      }
    }
  ]
}

Processar a notificação de alteração

Quando recebe uma notificação de alteração:

  1. Valide a propriedade clientState . Ela deve corresponder ao valor enviado originalmente com a solicitação de criação da assinatura.

    Se existir um erro de correspondência, não considere a notificação de alteração válida. É possível que a notificação de alteração não tenha origem no Microsoft Graph e possa ter sido enviada por um ator não autorizado. Você também deve investigar de onde vem a notificação de alteração e tomar as medidas apropriadas.

  2. Atualize a aplicação cliente com base na lógica de negócio.

Ciclo de vida da subscrição

Quando já não forem necessárias, as subscrições podem ser eliminadas ou expirar. Quando cria a sua subscrição, define uma data de expiração com a propriedade expirationDateTime . Assim que esta hora passar, o Microsoft Graph elimina a subscrição e não envia notificações para o ponto final. Também pode eliminar explicitamente a sua subscrição.

A forma mais simples de continuar a receber notificações é continuar a renovar o pedido de subscrição. Cada notificação inclui uma propriedade subscriptionExpirationDateTime . Pode utilizá-la para orientá-lo quando renovar a sua subscrição.

Cada subscrição também inclui um token de acesso concedido ao ponto final. O tempo de expiração deste token de acesso pode ocorrer antes da expiração da subscrição. Pode gerir a expiração do token de acesso através de notificações de ciclo de vida para a sua subscrição.

Renovar uma subscrição

PATCH https://graph.microsoft.com/v1.0/subscriptions/{id}
Content-Type: application/json

{
  "expirationDateTime": "2016-03-22T11:00:00.0000000Z"
}

Se o pedido de renovação da subscrição for bem-sucedido, o Microsoft Graph devolve um 200 OK código de resposta e um objeto de subscrição no corpo da resposta. O objeto de subscrição inclui o novo valor expirationDateTime .

Excluir uma assinatura

Se a aplicação cliente já não quiser alterar as notificações, pode eliminar a subscrição com o subscriptionId da seguinte forma:

DELETE https://graph.microsoft.com/v1.0/subscriptions/{id}

Se tiver êxito, o Microsoft Graph retornará um código 204 No Content.

Notificações de ciclo de vida da sua subscrição

Para maior flexibilidade e fiabilidade, quando cria uma subscrição, também pode subscrever as notificações de ciclo de vida dessa subscrição ao fornecer um ponto final lifecycleNotificationUrl que recebe, processa e responde a notificações de ciclo de vida.

Quando subscreve notificações de ciclo de vida, o Microsoft Graph alerta-o:

  • Quando o token de acesso está prestes a expirar.
  • Quando uma subscrição está prestes a expirar.
  • Quando um administrador inquilino revoga as permissões da sua aplicação para ler um recurso.

Observação

Se um token de acesso expirar, as notificações não serão entregues ao ponto final. No entanto, o Microsoft Graph continua a tentar enviar cada notificação durante um máximo de 4 horas. Por isso, se o token de acesso for atualizado no prazo de 4 horas após a expiração, serão entregues notificações não enviadas.

Para obter mais informações sobre como utilizar notificações de ciclo de vida para a sua subscrição, veja notificações de ciclo de vida.

Resumo

Neste artigo, aprendeu a receber notificações de alteração através de webhooks.

  1. Crie uma subscrição ao enviar um pedido POST para o /subscriptions ponto final.
  2. O Microsoft Graph valida o ponto final de notificação do webhook antes de concluir o processo de criação da subscrição. Um subscriptionID exclusivo está associado à subscrição.
  3. Desde que a subscrição ainda seja válida e ocorram alterações ao recurso subscrito, o Microsoft Graph envia notificações de alteração para o ponto final notificationUrl .
  4. Renove regularmente a subscrição para manter a validade e continuar a receber atualizações sobre as alterações subscritas.