"` |
| `requestContext.http` | Un objet qui contient des informations sur la demande HTTP. | |
| `requestContext.http.method` | La méthode HTTP utilisée dans cette demande. Les valeurs valides sont les suivantes : `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PATCH` et `DELETE`. | `GET` |
| `requestContext.http.path` | Chemin d’accès de la demande. Par exemple, si l’URL de la demande est `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, alors la valeur du chemin est `/example/test/demo`. | `/example/test/demo` |
| `requestContext.http.protocol` | Le protocole de la demande. | `HTTP/1.1` |
| `requestContext.http.sourceIp` | L’adresse IP source de la connexion TCP immédiate qui fait la demande. | `123.123.123.123` |
| `requestContext.http.userAgent` | La valeur de l’en-tête de la demande Utilisateur-Agent. | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Gecko/20100101 Firefox/42.0` |
| `requestContext.requestId` | L’identifiant de la demande d’invocation. Vous pouvez utiliser cet ID pour suivre les journaux d’invocation liés à votre fonction. | `e1506fd5-9e7b-434f-bd42-4f8fa224b599` |
| `requestContext.routeKey` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `$default` comme espace réservé. | `$default` |
| `requestContext.stage` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `$default` comme espace réservé. | `$default` |
| `requestContext.time` | Horodatage de la demande. | `"07/Sep/2021:22:50:22 +0000"` |
| `requestContext.timeEpoch` | L’horodatage de la demande, en heure d’époque Unix. | `"1631055022677"` |
| `body` | Le corps de la demande. Si le type de contenu de la demande est binaire, le corps est codé en base64. | `{"key1": "value1", "key2": "value2"}` |
| `pathParameters` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null` ou l’exclut de JSON. | `null` |
| `isBase64Encoded` | `TRUE` si le corps est une charge utile binaire et codé en base64. Sinon `FALSE`. | `FALSE` |
| `stageVariables` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null` ou l’exclut du JSON. | `null` |
### Format de la charge utile de la réponse
Lorsque votre fonction renvoie une réponse, Lambda analyse la réponse et la convertit en réponse HTTP. Les charges utiles de la réponse de fonction ont le format suivant :
```
{
"statusCode": 201,
"headers": {
"Content-Type": "application/json",
"My-Custom-Header": "Custom Value"
},
"body": "{ \"message\": \"Hello, world!\" }",
"cookies": [
"Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT",
"Cookie_2=Value2; Max-Age=78000"
],
"isBase64Encoded": false
}
```
Lambda déduit le format de réponse pour vous. Si votre fonction renvoie un JSON valide et ne renvoie pas un `statusCode`, Lambda assume ce qui suit :
+ `statusCode` is `200`.
**Note**
Les valeurs de `statusCode` valides sont comprises entre 100 et 599.
+ `content-type` is `application/json`.
+ `body` est la réponse de la fonction.
+ `isBase64Encoded` is `false`.
Les exemples suivants montrent comment la sortie de votre fonction Lambda est mappée à la charge utile de réponse et comment la charge utile de réponse est mappée à la réponse HTTP finale. Lorsque le client invoque l’URL de votre fonction, il voit la réponse HTTP.
**Exemple de sortie pour une réponse de chaîne**
| Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
| --- | --- | --- |
| "Hello, world!"
| {
"statusCode": 200,
"body": "Hello, world!",
"headers": {
"content-type": "application/json"
},
"isBase64Encoded": false
} | HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 15
"Hello, world!"
|
**Exemple de sortie pour une réponse JSON**
| Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
| --- | --- | --- |
| {
"message": "Hello, world!"
} | {
"statusCode": 200,
"body": {
"message": "Hello, world!"
},
"headers": {
"content-type": "application/json"
},
"isBase64Encoded": false
} | HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 34
{
"message": "Hello, world!"
}
|
**Exemple de sortie pour une réponse personnalisée**
| Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
| --- | --- | --- |
| {
"statusCode": 201,
"headers": {
"Content-Type": "application/json",
"My-Custom-Header": "Custom Value"
},
"body": JSON.stringify({
"message": "Hello, world!"
}),
"isBase64Encoded": false
} | {
"statusCode": 201,
"headers": {
"Content-Type": "application/json",
"My-Custom-Header": "Custom Value"
},
"body": JSON.stringify({
"message": "Hello, world!"
}),
"isBase64Encoded": false
} | HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value
{
"message": "Hello, world!"
}
|
### Cookies
Pour renvoyer des cookies depuis votre fonction, n’ajoutez pas manuellement des en-têtes `set-cookie`. Incluez plutôt les cookies dans votre objet de charge utile de réponse. Lambda les interprète automatiquement et les ajoute comme en-têtes `set-cookie` de votre réponse HTTP, comme dans l’exemple suivant.
| Sortie de la fonction Lambda | Réponse HTTP (ce que voit le client) |
| --- | --- |
| {
"statusCode": 201,
"headers": {
"Content-Type": "application/json",
"My-Custom-Header": "Custom Value"
},
"body": JSON.stringify({
"message": "Hello, world!"
}),
"cookies": [
"Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT",
"Cookie_2=Value2; Max-Age=78000"
],
"isBase64Encoded": false
} | HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value
set-cookie: Cookie_1=Value2; Expires=21 Oct 2021 07:48 GMT
set-cookie: Cookie_2=Value2; Max-Age=78000
{
"message": "Hello, world!"
}
|
# Surveillance des URL de fonctions Lambda
Vous pouvez utiliser AWS CloudTrail et Amazon CloudWatch pour surveiller vos URL de fonctions.
**Topics**
+ [
## URL de fonctions de surveillance avec CloudTrail
](#urls-cloudtrail)
+ [
## Métriques CloudWatch pour les URL de fonctions
](#urls-cloudwatch)
## URL de fonctions de surveillance avec CloudTrail
Pour les URL de fonctions, Lambda prend automatiquement en charge la journalisation des opérations API suivantes en tant qu'événements dans des fichiers journaux CloudTrail :
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
Chaque entrée de journal contient des informations sur l'identité de l'appelant, le moment où la demande a été faite, et d'autres détails. Vous pouvez voir tous les événements des 90 derniers jours en consultant votre **Event history** (Historique des événements) CloudTrail. Pour conserver les enregistrements de plus de 90 jours, vous pouvez créer un journal d'activité.
Par défaut, CloudTrail ne journalise pas les demandes `InvokeFunctionUrl`, qui sont considérées comme des événements de données. Cependant, vous pouvez activer la journalisation des événements de données dans CloudTrail. Pour plus d’informations, consultez [Consignation d’événements de données pour les journaux d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) dans le *Guide de l’utilisateur AWS CloudTrail*.
## Métriques CloudWatch pour les URL de fonctions
Lambda envoie des métriques agrégées concernant les demandes d'URL de fonction vers CloudWatch. Avec ces métriques, vous pouvez surveiller les URL de vos fonctions, créer des tableaux de bord et configurer des alarmes dans la console CloudWatch.
Les URL de fonctions prennent en charge les métriques d'invocation suivantes. Nous vous recommandons de consulter ces métriques avec la statistique `Sum`.
+ `UrlRequestCount` – Nombre de demandes faites vers cette URL de fonction.
+ `Url4xxCount` – Nombre de demandes ayant retourné un code d'état HTTP 4XX. Les codes de la série 4XX indiquent des erreurs côté client, telles que des demandes erronées.
+ `Url5xxCount` – Nombre de demandes ayant retourné un code d'état HTTP 5XX. Les codes de la série 5XX indiquent des erreurs côté serveur, telles que des erreurs de fonction et des délais d'attente.
Les URL de fonctions prennent également en charge la métrique de performance suivante. Nous vous recommandons de consulter ces métriques avec les statistiques `Average` ou `Max`.
+ `UrlRequestLatency` – Le temps écoulé entre le moment où l'URL de fonction reçoit une demande et celui où l'URL de fonction renvoie une réponse.
Chacune de ces métriques d'invocation et de performance prend en charge les dimensions suivantes :
+ `FunctionName` – Affichez les métriques agrégées pour les URL de fonctions attribuées à la version non publiée `$LATEST` d'une fonction, ou à tout alias de la fonction. Par exemple, `hello-world-function`.
+ `Resource` – Affichez les métriques d'une URL de fonction spécifique. Cela est défini par un nom de fonction, accompagné de la version non publiée `$LATEST` de la fonction ou d'un alias de la fonction. Par exemple, `hello-world-function:$LATEST`.
+ `ExecutedVersion` – Affichez les métriques d'une URL de fonction spécifique en fonction de la version exécutée. Vous pouvez utiliser cette dimension principalement pour suivre l'URL de la fonction affectée à la version non publiée `$LATEST`.
# Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP
De nombreux cas d’utilisation courants de Lambda impliquent d’invoquer votre fonction à l’aide d’une requête HTTP. Vous pourriez souhaiter qu’une application Web invoque votre fonction par le biais d’une demande de navigateur. Les fonctions Lambda peuvent également être utilisées pour créer un REST complet APIs, gérer les interactions des utilisateurs à partir d'applications mobiles, traiter des données provenant de services externes via des appels HTTP ou créer des webhooks personnalisés.
Les sections suivantes expliquent quels sont vos choix pour invoquer Lambda via HTTP et fournissent des informations qui vous aideront à prendre la bonne décision pour votre cas d’utilisation particulier.
## Options proposées lors de la sélection d’une méthode d’appel HTTP
Lambda propose deux méthodes principales pour appeler une fonction à l'aide d'une requête HTTP : [function URLs](urls-configuration.md) et [API](services-apigateway.md) Gateway. Les principales différences entre ces deux options sont les suivantes :
+ **La fonction Lambda URLs** fournit un point de terminaison HTTP simple et direct pour une fonction Lambda. Elles sont optimisées pour la simplicité et la rentabilité et constituent le moyen le plus rapide d’exposer une fonction Lambda via HTTP.
+ **API Gateway** est un service plus avancé permettant de créer des fonctionnalités complètes APIs. API Gateway est optimisé pour créer et gérer des productions APIs à grande échelle et fournit des outils complets pour la sécurité, la surveillance et la gestion du trafic.
## Recommandations si vous connaissez déjà vos besoins
Si vous connaissez déjà bien vos besoins, voici nos recommandations de base :
Nous recommandons cette **[fonction URLs](urls-configuration.md)** pour les applications simples ou le prototypage où vous n'avez besoin que de méthodes d'authentification et de request/response manipulation de base et où vous souhaitez réduire les coûts et la complexité au minimum.
**[API Gateway](services-apigateway.md)** est un meilleur choix pour les applications de production à grande échelle ou pour les cas où vous avez besoin de fonctionnalités plus avancées telles que la prise en charge d'[OpenAPI Description](https://www.openapis.org/), un choix d'options d'authentification, des noms de domaine personnalisés ou une request/response gestion riche, notamment la régulation, la mise en cache et la transformation. request/response
## Éléments à prendre en compte lors de la sélection d’une méthode pour invoquer votre fonction Lambda
Lorsque vous choisissez entre function URLs et API Gateway, vous devez prendre en compte les facteurs suivants :
+ Vos besoins en matière d'authentification, par exemple si vous avez besoin OAuth d'Amazon Cognito pour authentifier les utilisateurs
+ Vos exigences en matière de mise à l’échelle et la complexité de l’API que vous souhaitez implémenter
+ Si vous avez besoin de fonctionnalités avancées telles que la validation et le request/response formatage des demandes
+ Vos besoins en matière de surveillance
+ Vos objectifs en matière de coûts
La compréhension de ces facteurs vous permettra de choisir l’option qui répond le mieux à vos exigences en matière de sécurité, de complexité et de coût.
Le tableau suivant résume les différences entre les deux options.
### Authentification
+ **La fonction URLs** fournit des options d'authentification de base via Gestion des identités et des accès AWS (IAM). Vous pouvez configurer vos points de terminaison pour qu’ils soient publics (aucune authentification) ou pour qu’ils nécessitent une authentification IAM. Avec l'authentification IAM, vous pouvez utiliser des AWS informations d'identification standard ou des rôles IAM pour contrôler l'accès. Bien que simple à configurer, cette approche offre des options limitées par rapport aux autres méthodes d’authentification.
+ **API Gateway** donne accès à une gamme plus complète d’options d’authentification. Outre l'authentification IAM, vous pouvez utiliser des autorisateurs [Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (logique d'authentification personnalisée), des groupes d'utilisateurs Amazon [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) et des flux .0. OAuth2 Cette flexibilité vous permet de mettre en œuvre des schémas d’authentification complexes, notamment des fournisseurs d’authentification tiers, une authentification basée sur des jetons et une authentification multifactorielle.
### Traitement des requêtes et réponses
+ **La fonction URLs** fournit une gestion de base des requêtes et des réponses HTTP. Elles prennent en charge les méthodes HTTP standard et créent une prise en charge intégrée du partage des ressources entre origines (CORS, cross-origin resource sharing). Bien qu’elles puissent gérer naturellement les charges utiles JSON et les paramètres de requête, elles n’offrent pas de fonctionnalités de transformation ou de validation des requêtes. La gestion des réponses est tout aussi simple : le client reçoit la réponse de votre fonction Lambda exactement telle que Lambda la renvoie.
+ **API Gateway** fournit des fonctionnalités sophistiquées de gestion des requêtes et des réponses. Vous pouvez définir des validateurs de demandes, transformer les demandes et les réponses à l'aide de modèles de mappage, configurer request/response des en-têtes et implémenter la mise en cache des réponses. API Gateway prend également en charge les charges utiles binaires et les noms de domaine personnalisés et peut modifier les réponses avant qu’elles n’atteignent le client. Vous pouvez configurer des modèles pour la request/response validation et la transformation à l'aide du schéma JSON.
### Mise à l’échelle
+ Les **fonctions** s' URLsadaptent directement aux limites de simultanéité de votre fonction Lambda et gérez les pics de trafic en augmentant la taille de votre fonction jusqu'à sa limite de simultanéité maximale configurée. Une fois cette limite atteinte, Lambda répond aux requêtes supplémentaires avec des réponses HTTP 429. Il n’existe aucun mécanisme de mise en file d’attente intégré. La gestion de la mise à l’échelle dépend donc entièrement de la configuration de votre fonction Lambda. Par défaut, les fonctions Lambda sont limitées à 1 000 exécutions simultanées par fonction. Région AWS
+ **API Gateway** fournit des fonctionnalités de dimensionnement supplémentaires en plus de la propre mise à l’échelle de Lambda. Il inclut des commandes intégrées de mise en file d’attente et de limitation des requêtes, ce qui vous permet de gérer les pics de trafic de manière plus élégante. API Gateway peut traiter jusqu’à 10 000 requêtes par seconde et par région par défaut, avec une capacité de débordement de 5 000 requêtes par seconde. Il fournit également des outils pour limiter les requêtes à différents niveaux (API, étape ou méthode) afin de protéger votre dorsal.
### Contrôle
+ Les **fonctions URLs** offrent une surveillance de base via CloudWatch les métriques Amazon, notamment le nombre de demandes, la latence et les taux d'erreur. Vous avez accès aux métriques et aux journaux Lambda standard, qui indiquent les requêtes brutes entrant dans votre fonction. Bien que cela fournisse une visibilité opérationnelle essentielle, les métriques se concentrent principalement sur l’exécution des fonctions.
+ **API Gateway** fournit des fonctionnalités de surveillance complètes, notamment des métriques détaillées, des options de journalisation et de suivi. Vous pouvez surveiller les appels d'API, la latence, les taux d'erreur et hit/miss les taux de cache via CloudWatch. API Gateway s'intègre également au AWS X-Ray traçage distribué et fournit des formats de journalisation personnalisables.
### Cost
+ Les **fonctions URLs** suivent le modèle de tarification Lambda standard : vous ne payez que pour les appels de fonctions et le temps de calcul. Il n’y a pas de frais supplémentaires pour le point de terminaison de l’URL lui-même. Cela en fait un choix rentable pour les applications simples APIs ou à faible trafic si vous n'avez pas besoin des fonctionnalités supplémentaires d'API Gateway.
+ **API Gateway** propose un [niveau gratuit](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) qui inclut un million d'appels d'API reçus pour REST APIs et un million d'appels d'API reçus pour HTTP APIs. Ensuite, API Gateway facture les appels d’API, le transfert de données et la mise en cache (si activée). Reportez-vous à la [page de tarification](https://aws.amazon.com/api-gateway/pricing/) d’API Gateway pour connaître les coûts associés à votre propre cas d’utilisation.
### Autres fonctions
+ URLsLes **fonctions** sont conçues pour la simplicité et l'intégration directe de Lambda. Ils prennent en charge les points de terminaison HTTP et HTTPS, offrent un support CORS intégré et fournissent des points de terminaison à double pile (IPv4 et IPv6). Bien qu’elles ne disposent d’aucune fonctionnalité avancée, elles excellent dans les scénarios où vous avez besoin d’un moyen rapide et simple d’exposer les fonctions Lambda via HTTP.
+ **API Gateway** inclut de nombreuses fonctionnalités supplémentaires telles que la gestion des versions des API, la gestion des étapes, les clés d'API pour les plans d'utilisation, la documentation des API via Swagger/OpenAPI, le mode WebSocket APIs privé au sein d' APIs un VPC et l'intégration WAF pour une sécurité accrue. Il prend également en charge les déploiements Canary, les intégrations fictives à des fins de test et l'intégration avec d'autres solutions que Services AWS Lambda.
## Sélection d’une méthode pour invoquer votre fonction Lambda
Maintenant que vous avez pris connaissance des critères de sélection entre la fonction Lambda URLs et API Gateway et des principales différences entre les deux, vous pouvez sélectionner l'option qui répond le mieux à vos besoins et utiliser les ressources suivantes pour vous aider à commencer à l'utiliser.
------
#### [ Function URLs ]
**Commencez à utiliser Function URLs grâce aux ressources suivantes**
+ Suivre le tutoriel [Création d’une fonction Lambda avec une URL de fonction](urls-webhook-tutorial.md)
+ Pour en savoir plus sur URLs les fonctions, consultez le [Création et gestion de la fonction Lambda URLs](urls-configuration.md) chapitre de ce guide
+ Essayez le tutoriel guidé intégré à la console **Créer une application Web simple** en procédant comme suit :
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Ouvrez le panneau d’aide en cliquant sur l’icône dans le coin supérieur droit de l’écran.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_help_screenshot.png)
1. Sélectionnez **Tutoriels**.
1. Dans **Créer une application Web simple**, choisissez **Démarrer le tutoriel**.
------
#### [ API Gateway ]
**Mise en route avec Lambda et API Gateway grâce aux ressources suivantes**
+ Suivez le tutoriel [Utilisation de Lambda avec API Gateway](services-apigateway-tutorial.md) pour créer une API REST intégrée à une fonction Lambda principale.
+ Pour en savoir plus sur les différents types d’API proposés par API Gateway, consultez les sections suivantes du *Guide du développeur Amazon API Gateway* :
+ [API Gateway REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)
+ [API Gateway HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)
+ [API Gateway WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html)
+ Essayez un ou plusieurs des exemples de la section [Tutoriels et ateliers](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) du manuel *Guide du développeur Amazon API Gateway*.
------
# Didacticiel : création d’un point de terminaison webhook à l’aide d’une URL de fonction Lambda
Dans ce didacticiel, vous créez une URL de fonction Lambda pour implémenter un point de terminaison webhook. Un webhook est une communication légère pilotée par les événements qui envoie automatiquement des données entre applications via HTTP. Vous pouvez utiliser un webhook pour recevoir des mises à jour immédiates sur les événements survenant dans un autre système, par exemple lorsqu’un nouveau client s’inscrit sur un site Web, qu’un paiement est traité ou qu’un fichier est chargé.
Avec Lambda, les webhooks peuvent être implémentés à l'aide de la fonction Lambda ou d'API Gateway. URLs URLs Les fonctions sont un bon choix pour les webhooks simples qui ne nécessitent pas de fonctionnalités telles que l'autorisation avancée ou la validation des demandes.
**Astuce**
Si vous ne savez pas quelle est la solution la mieux adaptée à votre cas d’utilisation particulier, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](furls-http-invoke-decision.md).
## Conditions préalables
Pour terminer ce didacticiel, Python (version 3.8 ou ultérieure) ou Node.js (version 18 ou ultérieure) doit être installé sur votre machine locale.
Pour tester le point de terminaison à l’aide d’une requête HTTP, le didacticiel utilise [curl](https://curl.se/), un outil de ligne de commande que vous pouvez utiliser pour transférer des données à l’aide de différents protocoles réseau. Reportez-vous à la [documentation curl](https://curl.se/docs/install.html) pour savoir comment installer l’outil si vous ne l’avez pas déjà.
## Créer la fonction Lambda
Créez d’abord la fonction Lambda qui s’exécute lorsqu’une requête HTTP est envoyée à votre point de terminaison webhook. Dans cet exemple, l’application d’envoi envoie une mise à jour chaque fois qu’un paiement est soumis, et indique dans le corps de la requête HTTP si le paiement a été effectué avec succès. La fonction Lambda analyse la demande et agit en fonction du statut du paiement. Dans cet exemple, le code imprime simplement l’ID de commande pour le paiement, mais dans une application réelle, vous pouvez ajouter la commande à une base de données ou envoyer une notification.
La fonction implémente également la méthode d’authentification la plus couramment utilisée pour les webhooks, l’authentification des messages basée sur le hachage (HMAC). Avec cette méthode, les applications d’envoi et de réception partagent une clé secrète. L’application d’envoi utilise un algorithme de hachage pour générer une signature unique à l’aide de cette clé associée au contenu du message, et inclut la signature dans la demande de webhook sous forme d’en-tête HTTP. L’application réceptrice répète ensuite cette étape en générant la signature à l’aide de la clé secrète, et compare la valeur obtenue avec la signature envoyée dans l’en-tête de la demande. Si le résultat correspond, la demande est considérée comme légitime.
Créez la fonction à l’aide de la console Lambda avec l’environnement d'exécution Python ou Node.js.
------
#### [ Python ]
**Créer la fonction Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Créez une fonction de type « Hello World » de base en procédant comme suit :
1. Choisissez **Créer une fonction**.
1. Sélectionnez **Créer à partir de zéro**.
1. Sous **Nom de la fonction**, saisissez **myLambdaWebhook**.
1. Pour **Runtime**, sélectionnez **python3.14**.
1. Choisissez **Créer une fonction**.
1. Dans le volet **Source du code**, remplacez le code existant en copiant et en collant ce qui suit :
```
import json
import hmac
import hashlib
import os
def lambda_handler(event, context):
# Get the webhook secret from environment variables
webhook_secret = os.environ['WEBHOOK_SECRET']
# Verify the webhook signature
if not verify_signature(event, webhook_secret):
return {
'statusCode': 401,
'body': json.dumps({'error': 'Invalid signature'})
}
try:
# Parse the webhook payload
payload = json.loads(event['body'])
# Handle different event types
event_type = payload.get('type')
if event_type == 'payment.success':
# Handle successful payment
order_id = payload.get('orderId')
print(f"Processing successful payment for order {order_id}")
# Add your business logic here
# For example, update database, send notifications, etc.
elif event_type == 'payment.failed':
# Handle failed payment
order_id = payload.get('orderId')
print(f"Processing failed payment for order {order_id}")
# Add your business logic here
else:
print(f"Received unhandled event type: {event_type}")
# Return success response
return {
'statusCode': 200,
'body': json.dumps({'received': True})
}
except json.JSONDecodeError:
return {
'statusCode': 400,
'body': json.dumps({'error': 'Invalid JSON payload'})
}
except Exception as e:
print(f"Error processing webhook: {e}")
return {
'statusCode': 500,
'body': json.dumps({'error': 'Internal server error'})
}
def verify_signature(event, webhook_secret):
"""
Verify the webhook signature using HMAC
"""
try:
# Get the signature from headers
signature = event['headers'].get('x-webhook-signature')
if not signature:
print("Error: Missing webhook signature in headers")
return False
# Get the raw body (return an empty string if the body key doesn't exist)
body = event.get('body', '')
# Create HMAC using the secret key
expected_signature = hmac.new(
webhook_secret.encode('utf-8'),
body.encode('utf-8'),
hashlib.sha256
).hexdigest()
# Compare the expected signature with the received signature to authenticate the message
is_valid = hmac.compare_digest(signature, expected_signature)
if not is_valid:
print(f"Error: Invalid signature. Received: {signature}, Expected: {expected_signature}")
return False
return True
except Exception as e:
print(f"Error verifying signature: {e}")
return False
```
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction.
------
#### [ Node.js ]
**Créer la fonction Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Créez une fonction de type « Hello World » de base en procédant comme suit :
1. Choisissez **Créer une fonction**.
1. Sélectionnez **Créer à partir de zéro**.
1. Sous **Nom de la fonction**, saisissez **myLambdaWebhook**.
1. Pour **Runtime**, sélectionnez **nodejs24.x**.
1. Choisissez **Créer une fonction**.
1. Dans le volet **Source du code**, remplacez le code existant en copiant et en collant ce qui suit :
```
import crypto from 'crypto';
export const handler = async (event, context) => {
// Get the webhook secret from environment variables
const webhookSecret = process.env.WEBHOOK_SECRET;
// Verify the webhook signature
if (!verifySignature(event, webhookSecret)) {
return {
statusCode: 401,
body: JSON.stringify({ error: 'Invalid signature' })
};
}
try {
// Parse the webhook payload
const payload = JSON.parse(event.body);
// Handle different event types
const eventType = payload.type;
switch (eventType) {
case 'payment.success': {
// Handle successful payment
const orderId = payload.orderId;
console.log(`Processing successful payment for order ${orderId}`);
// Add your business logic here
// For example, update database, send notifications, etc.
break;
}
case 'payment.failed': {
// Handle failed payment
const orderId = payload.orderId;
console.log(`Processing failed payment for order ${orderId}`);
// Add your business logic here
break;
}
default:
console.log(`Received unhandled event type: ${eventType}`);
}
// Return success response
return {
statusCode: 200,
body: JSON.stringify({ received: true })
};
} catch (error) {
if (error instanceof SyntaxError) {
// Handle JSON parsing errors
return {
statusCode: 400,
body: JSON.stringify({ error: 'Invalid JSON payload' })
};
}
// Handle all other errors
console.error('Error processing webhook:', error);
return {
statusCode: 500,
body: JSON.stringify({ error: 'Internal server error' })
};
}
};
// Verify the webhook signature using HMAC
const verifySignature = (event, webhookSecret) => {
try {
// Get the signature from headers
const signature = event.headers['x-webhook-signature'];
if (!signature) {
console.log('No signature found in headers:', event.headers);
return false;
}
// Get the raw body (return an empty string if the body key doesn't exist)
const body = event.body || '';
// Create HMAC using the secret key
const hmac = crypto.createHmac('sha256', webhookSecret);
const expectedSignature = hmac.update(body).digest('hex');
// Compare expected and received signatures
const isValid = signature === expectedSignature;
if (!isValid) {
console.log(`Invalid signature. Received: ${signature}, Expected: ${expectedSignature}`);
return false;
}
return true;
} catch (error) {
console.error('Error during signature verification:', error);
return false;
}
};
```
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction.
------
## Créer la clé de secret
Pour que la fonction Lambda authentifie la demande de webhook, elle utilise une clé secrète qu’elle partage avec l’application appelante. Dans cet exemple, la clé est stockée dans une variable d’environnement. Dans une application de production, n’incluez pas d’informations sensibles telles que des mots de passe dans votre code de fonction. [Créez plutôt un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html), puis [utilisez l'extension Lambda AWS Parameters and Secrets](with-secrets-manager.md) pour récupérer vos informations d'identification dans votre fonction Lambda.
**Créer et stocker la clé secrète du webhook**
1. Générez une longue chaîne aléatoire à l’aide d’un générateur de nombres aléatoires sécurisé par cryptographie. Vous pouvez utiliser les extraits de code suivants en Python ou Node.js pour générer et imprimer un secret de 32 caractères, ou utiliser votre propre méthode préférée.
------
#### [ Python ]
**Example code pour générer un secret**
```
import secrets
webhook_secret = secrets.token_urlsafe(32)
print(webhook_secret)
```
------
#### [ Node.js ]
**Example code pour générer un secret (format du module ES)**
```
import crypto from 'crypto';
let webhookSecret = crypto.randomBytes(32).toString('base64');
console.log(webhookSecret)
```
------
1. Stockez la chaîne générée en tant que variable d’environnement pour votre fonction en procédant comme suit :
1. Dans l’onglet **Configuration** de votre fonction, sélectionnez **Variables d’environnement**.
1. Choisissez **Modifier**.
1. Choisissez **Ajouter une variable d’environnement**.
1. Pour **Clé**, saisissez **WEBHOOK\$1SECRET**, puis pour **Valeur**, saisissez le secret que vous avez généré à l’étape précédente.
1. Choisissez **Enregistrer**.
Vous devrez réutiliser ce secret ultérieurement dans le didacticiel pour tester votre fonction. Veillez donc à le noter dès maintenant.
## Créer le point de terminaison d’URL de fonction
Créez un point de terminaison pour votre webhook à l’aide d’une URL de fonction Lambda. Comme vous utilisez le type d’authentification `NONE` pour créer un point de terminaison avec accès public, toute personne disposant de l’URL peut invoquer votre fonction. Pour en savoir plus sur le contrôle de l'accès aux fonctions URLs, voir[Contrôler l'accès à la fonction Lambda URLs](urls-auth.md). Si vous avez besoin d’options d’authentification plus avancées pour votre webhook, pensez à utiliser API Gateway.
**Créer le point de terminaison d’URL de fonction**
1. Dans l’onglet **Configuration** de votre fonction, sélectionnez **URL de la fonction**.
1. Choisissez **Create function URL** (Créer une URL de fonction).
1. Pour **Type d’authentification**, sélectionnez **NONE**.
1. Choisissez **Enregistrer**.
Le point de terminaison de l’URL de fonction que vous venez de créer s’affiche dans le volet **URL de fonction**. Copiez le point de terminaison ; vous l’utiliserez ultérieurement dans le didacticiel.
## Tester la fonction dans console
Avant d’utiliser une requête HTTP pour invoquer votre fonction à l’aide du point de terminaison d’URL, testez-la dans la console pour vérifier que votre code fonctionne comme prévu.
Pour vérifier la fonction dans la console, vous devez d’abord calculer une signature de webhook à l’aide du secret que vous avez généré plus tôt dans le didacticiel avec les données utiles JSON de test suivantes :
```
{
"type": "payment.success",
"orderId": "1234",
"amount": "99.99"
}
```
Utilisez l’un des exemples de code Python ou Node.js suivants pour calculer la signature du webhook à l’aide de votre propre secret.
------
#### [ Python ]
**Calculer la signature du webhook**
1. Enregistrez le code suivant dans un fichier nommé `calculate_signature.py`. Remplacez le secret de webhook dans le code par votre propre valeur.
```
import secrets
import hmac
import json
import hashlib
webhook_secret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M"
body = json.dumps({"type": "payment.success", "orderId": "1234", "amount": "99.99"})
signature = hmac.new(
webhook_secret.encode('utf-8'),
body.encode('utf-8'),
hashlib.sha256
).hexdigest()
print(signature)
```
1. Calculez la signature en exécutant la commande suivante à partir du répertoire où vous avez enregistré le code. Copiez la signature émise par le code.
```
python calculate_signature.py
```
------
#### [ Node.js ]
**Calculer la signature du webhook**
1. Enregistrez le code suivant dans un fichier nommé `calculate_signature.mjs`. Remplacez le secret de webhook dans le code par votre propre valeur.
```
import crypto from 'crypto';
const webhookSecret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M"
const body = "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}";
let hmac = crypto.createHmac('sha256', webhookSecret);
let signature = hmac.update(body).digest('hex');
console.log(signature);
```
1. Calculez la signature en exécutant la commande suivante à partir du répertoire où vous avez enregistré le code. Copiez la signature émise par le code.
```
node calculate_signature.mjs
```
------
Vous pouvez désormais tester le code de votre fonction à l’aide d’une requête HTTP de test dans la console.
**Tester la fonction dans console**
1. Sélectionnez l’onglet **Code** correspondant à votre fonction.
1. Dans la section **ÉVÉNEMENTS DE TEST**, choisissez **Créer un nouvel événement de test**.
1. Dans **Event Name (Nom de l'événement)**, saisissez **myEvent**.
1. Remplacez le JSON existant en copiant et en collant ce qui suit dans le volet **JSON d’événement**. Remplacez la signature de webhook par la valeur calculée à l’étape précédente.
```
{
"headers": {
"Content-Type": "application/json",
"x-webhook-signature": "2d672e7a0423fab740fbc040e801d1241f2df32d2ffd8989617a599486553e2a"
},
"body": "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}"
}
```
1. Choisissez **Enregistrer**.
1. Sélectionnez **Invoquer **.
Vous devez voir des résultats similaires à ce qui suit :
------
#### [ Python ]
```
Status: Succeeded
Test Event Name: myEvent
Response:
{
"statusCode": 200,
"body": "{\"received\": true}"
}
Function Logs:
START RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Version: $LATEST
Processing successful payment for order 1234
END RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6
REPORT RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Duration: 1.55 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 36 MB Init Duration: 136.32 ms
```
------
#### [ Node.js ]
```
Status: Succeeded
Test Event Name: myEvent
Response:
{
"statusCode": 200,
"body": "{\"received\":true}"
}
Function Logs:
START RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Version: $LATEST
2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234
END RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4
REPORT RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Duration: 60.10 ms Billed Duration: 61 ms Memory Size: 128 MB Max Memory Used: 72 MB Init Duration: 174.46 ms
Request ID: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4
```
------
## Tester la fonction avec une requête HTTP
Utilisez l’outil de ligne de commande curl pour tester votre point de terminaison webhook.
**Tester la fonction avec des requêtes HTTP**
1. Dans un terminal ou un programme shell, exécutez la commande curl suivante. Remplacez l’URL par la valeur du point de terminaison de votre URL de fonction et remplacez la signature du webhook par la signature que vous avez calculée à l’aide de votre propre clé secrète.
```
curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \
-H "Content-Type: application/json" \
-H "x-webhook-signature: d5f52b76ffba65ff60ea73da67bdf1fc5825d4db56b5d3ffa0b64b7cb85ef48b" \
-d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}'
```
Vous devriez voir la sortie suivante :
```
{"received": true}
```
1. Examinez les CloudWatch journaux de votre fonction pour confirmer qu'elle a correctement analysé la charge utile en procédant comme suit :
1. Ouvrez la page du [groupe Logs](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) dans la CloudWatch console Amazon.
1. Sélectionnez le groupe de journaux de votre fonction (`/aws/lambda/myLambdaWebhook`).
1. Sélectionnez le flux de journaux le plus récent.
Vous devez voir des résultats similaires à ce qui suit dans les journaux de votre fonction :
------
#### [ Python ]
```
Processing successful payment for order 1234
```
------
#### [ Node.js ]
```
2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234
```
------
1. Confirmez que votre code détecte une signature non valide en exécutant la commande curl suivante. Remplacez l’URL par le point de terminaison de l’URL de votre propre fonction.
```
curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \
-H "Content-Type: application/json" \
-H "x-webhook-signature: abcdefg" \
-d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}'
```
Vous devriez voir la sortie suivante :
```
{"error": "Invalid signature"}
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
Lorsque vous avez créé la fonction Lambda dans la console, Lambda a également créé un [rôle d’exécution](lambda-intro-execution-role.md) pour votre fonction.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que Lambda a créé. Le nom du rôle est au format `myLambdaWebhook-role-`.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).