"` |
| `requestContext.http` | Un objeto que contiene detalles sobre la solicitud HTTP. | |
| `requestContext.http.method` | El método HTTP utilizado en esta solicitud. Los valores válidos son `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PATCH` y `DELETE`. | `GET` |
| `requestContext.http.path` | Ruta de acceso de la solicitud. Por ejemplo, si la URL de solicitud es `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, el valor de la ruta es `/example/test/demo`. | `/example/test/demo` |
| `requestContext.http.protocol` | El protocolo de la solicitud. | `HTTP/1.1` |
| `requestContext.http.sourceIp` | La dirección IP de origen de la conexión TCP inmediata que realiza la solicitud. | `123.123.123.123` |
| `requestContext.http.userAgent` | El valor del encabezado de solicitud usuario-agente. | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Gecko/20100101 Firefox/42.0` |
| `requestContext.requestId` | El ID de la solicitud de invocación. Puede utilizar este ID para realizar un seguimiento de los registros de invocación relacionados con la función. | `e1506fd5-9e7b-434f-bd42-4f8fa224b599` |
| `requestContext.routeKey` | Las URL de funciones no utilizan este parámetro. Lambda establece `$default` como marcador de posición. | `$default` |
| `requestContext.stage` | Las URL de funciones no utilizan este parámetro. Lambda establece `$default` como marcador de posición. | `$default` |
| `requestContext.time` | La marca de tiempo de la solicitud. | `"07/Sep/2021:22:50:22 +0000"` |
| `requestContext.timeEpoch` | La marca de tiempo de la solicitud, en fecha de inicio Unix. | `"1631055022677"` |
| `body` | El cuerpo de la solicitud. Si el tipo de contenido de la solicitud es binario, el cuerpo está codificado en base64. | `{"key1": "value1", "key2": "value2"}` |
| `pathParameters` | Las URL de funciones no utilizan este parámetro. Lambda establece esto como `null` o lo excluye de JSON. | `null` |
| `isBase64Encoded` | `TRUE` si el cuerpo es una carga binaria y está codificado en base64. `FALSE` en caso contrario. | `FALSE` |
| `stageVariables` | Las URL de funciones no utilizan este parámetro. Lambda establece esto como `null` o lo excluye de JSON. | `null` |
### Formato de carga de respuesta
Cuando la función devuelve una respuesta, Lambda analiza la respuesta y la convierte en una respuesta HTTP. Las cargas de respuesta de la función tienen el siguiente formato:
```
{
"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 le infiere el formato de respuesta. Si la función devuelve JSON válido y no devuelve un `statusCode`, Lambda asume lo siguiente:
+ `statusCode` is `200`.
**nota**
Los `statusCode` válidos están dentro del rango de 100 a 599.
+ `content-type` is `application/json`.
+ `body` es la respuesta de la función.
+ `isBase64Encoded` is `false`.
En los ejemplos siguientes se muestra cómo se asigna la salida de la función de Lambda a la carga de respuesta y cómo se asigna la carga de respuesta a la respuesta HTTP final. Cuando el cliente invoca la URL de función, ve la respuesta HTTP.
**Ejemplo de salida para una respuesta de cadena**
| Salida de función de Lambda | Salida de respuesta interpretada | Respuesta HTTP (lo que ve el cliente) |
| --- | --- | --- |
| "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!"
|
**Ejemplo de salida para una respuesta JSON**
| Salida de función de Lambda | Salida de respuesta interpretada | Respuesta HTTP (lo que ve el cliente) |
| --- | --- | --- |
| {
"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!"
}
|
**Ejemplo de salida para una respuesta personalizada**
| Salida de función de Lambda | Salida de respuesta interpretada | Respuesta HTTP (lo que ve el cliente) |
| --- | --- | --- |
| {
"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
Para devolver las cookies de su función, no agregue encabezados `set-cookie` manualmente. En su lugar, incluya las cookies en su objeto de carga de respuesta. Lambda interpreta esto automáticamente y las agrega como encabezados `set-cookie` de la respuesta HTTP, como en el siguiente ejemplo.
| Salida de función de Lambda | Respuesta HTTP (lo que ve el cliente) |
| --- | --- |
| {
"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!"
}
|
# Supervisión de las URL de funciones de Lambda
Puede utilizar AWS CloudTrail y Amazon CloudWatch para supervisar las URL de funciones.
**Topics**
+ [
## Supervisión de las URL de funciones con CloudTrail
](#urls-cloudtrail)
+ [
## Métricas de CloudWatch para las URL de funciones
](#urls-cloudwatch)
## Supervisión de las URL de funciones con CloudTrail
Para las URL de funciones, Lambda admite automáticamente el registro de las siguientes operaciones de API como eventos en archivos de registros de 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)
Cada entrada de registro contiene información sobre la identidad del intermediario, cuándo se realizó la solicitud y otros detalles. Puede ver todos los eventos de los últimos 90 días consultando el **historial de eventos** de CloudTrail. Para retener registros pasados 90 días, puede crear una traza.
De forma predeterminada, CloudTrail no registra solicitudes `InvokeFunctionUrl`, que se consideran eventos de datos. Sin embargo, puede activar el registro de eventos de datos en CloudTrail. Para obtener más información, consulte [Registro de eventos de datos para registros de seguimiento](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) en la *Guía del usuario de AWS CloudTrail*.
## Métricas de CloudWatch para las URL de funciones
Lambda envía métricas agregadas sobre las solicitudes de URL de funciones a CloudWatch. Con estas métricas, puede supervisar las URL de funciones, crear paneles y configurar alarmas en la consola de CloudWatch.
Las URL de funciones son compatibles con las siguientes métricas de invocación. Recomendamos ver estas métricas con la estadística `Sum`
+ `UrlRequestCount`: el número de solicitudes realizadas a esta URL de función.
+ `Url4xxCount`: el número de solicitudes que devolvió un código de estado HTTP 4XX. Los códigos de la serie 4XX indican errores del lado del cliente, como solicitudes erróneas.
+ `Url5xxCount`: el número de solicitudes que devolvió un código de estado HTTP 5XX. Los códigos de la serie 5XX indican errores del lado del servidor, como errores de función y tiempos de espera.
Las URL de funciones también son compatibles con la siguiente métrica de rendimiento. Recomendamos ver esta métrica con las estadísticas `Average` o `Max`.
+ `UrlRequestLatency`: el tiempo transcurrido entre el que la URL de función recibe una solicitud y el momento en que la URL de función devuelve una respuesta.
Cada una de estas métricas de invocación y rendimiento es compatible con las siguientes dimensiones:
+ `FunctionName`: visualiza métricas agregadas para las URL de las funciones asignadas a la versión `$LATEST` no publicada o a cualquiera de los alias de la función. Por ejemplo, `hello-world-function`.
+ `Resource`: visualiza métricas para una URL de función específica. Esto se define mediante el nombre de una función, junto con la versión `$LATEST` no publicada o uno de los alias de la función. Por ejemplo, `hello-world-function:$LATEST`.
+ `ExecutedVersion`: visualiza métricas para una URL de función específica en función de la versión ejecutada. Puede utilizar esta dimensión principalmente para realizar un seguimiento de la URL de función asignada a la versión `$LATEST` no publicada.
# Selección de un método para invocar una función de Lambda mediante una solicitud HTTP
En muchos casos de uso habituales de Lambda, se debe invocar una función mediante una solicitud HTTP. Por ejemplo, tal vez desee que una aplicación web invoque su función mediante una solicitud del navegador. Las funciones de Lambda también se pueden utilizar para crear API de REST completas, gestionar las interacciones de los usuarios de las aplicaciones móviles, procesar datos de servicios externos mediante llamadas HTTP o crear webhooks personalizados.
En las siguientes secciones, se explican cuáles son sus opciones para invocar a Lambda a través de HTTP y se proporciona información que ayudará a que tome la decisión correcta para su caso de uso concreto.
## ¿Cuáles son sus opciones a la hora de seleccionar un método para invocar una HTTP?
Lambda ofrece dos métodos principales para invocar una función mediante una solicitud HTTP: las [URL de función](urls-configuration.md) y [API Gateway](services-apigateway.md). Las diferencias clave entre estas dos opciones son las siguientes:
+ **Las URL de función de Lambda** proporcionan un punto de conexión HTTP simple y directo para una función de Lambda. Están optimizadas para ofrecer simplicidad y rentabilidad y ofrecen la ruta más rápida para exponer una función de Lambda a través de HTTP.
+ **API Gateway** es un servicio más avanzado para crear una API con todas las características. API Gateway está optimizado para crear y administrar una API de producción a escala y ofrece herramientas integrales para la seguridad, el monitoreo y la administración del tráfico.
## Recomendaciones si ya conoce sus requisitos
Si ya tiene claros sus requisitos, estas son nuestras recomendaciones básicas:
Recomendamos las **[URL de función](urls-configuration.md)** para aplicaciones sencillas o para la creación de prototipos cuando solo necesite métodos básicos de autenticación y gestión de solicitudes y respuestas y siempre que desee reducir al mínimo los costos y la complejidad.
**[API Gateway](services-apigateway.md)** es una mejor opción para aplicaciones de producción a gran escala o para los casos en los que se necesitan características más avanzadas, como la compatibilidad con la [descripción de OpenAPI](https://www.openapis.org/), una variedad de opciones de autenticación, nombres de dominio personalizados o una gestión rica de solicitudes y respuestas, que incluye la limitación, el almacenamiento en caché y la transformación de solicitudes y respuestas.
## Aspectos que deben tenerse en cuenta al seleccionar un método para invocar una función de Lambda
Al seleccionar entre las URL de función y API Gateway, deben tener en cuenta los siguientes factores:
+ Sus necesidades de autenticación, por ejemplo, si necesita OAuth o Amazon Cognito para autenticar a los usuarios
+ Sus requisitos de escalado y la complejidad de la API que desea implementar
+ Si necesita características avanzadas, como la validación de solicitudes y el formato de las solicitudes o respuestas
+ Sus requisitos de monitoreo
+ Sus objetivos de costos
Al comprender estos factores, puede seleccionar la opción que mejor equilibre sus requisitos de seguridad, complejidad y costo.
En la siguiente información, se comparan las principales diferencias entre las dos opciones.
### Autenticación
+ **Las URL de función** proporcionan opciones de autenticación básicas mediante AWS Identity and Access Management (IAM). Puede configurar sus puntos de conexión para que sean públicos (sin autenticación) o para que requieran la autenticación de IAM. Con la autenticación de IAM, puede utilizar credenciales de AWS estándar o roles de IAM para controlar el acceso. Si bien es fácil de configurar, este enfoque ofrece opciones limitadas en comparación con otros métodos de autenticación.
+ **API Gateway** proporciona acceso a una gama más completa de opciones de autenticación. Además de la autenticación de IAM, puede utilizar [autorizadores de Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (lógica de autenticación personalizada), grupos de usuarios de [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) y flujos de OAuth2.0. Esta flexibilidad permite implementar esquemas de autenticación complejos, que incluyen proveedores de autenticación de terceros, autenticación basada en tokens y autenticación multifactorial.
### Gestión de solicitudes y respuestas
+ **Las URL de función** proporcionan una gestión básica de solicitudes y respuestas HTTP. Son compatibles con los métodos HTTP estándar e incluyen soporte integrado de uso compartido de recursos entre orígenes (CORS). Si bien pueden gestionar las cargas útiles de JSON y los parámetros de consulta de forma natural, no ofrecen capacidades de transformación o validación de solicitudes. La gestión de las respuestas es igual de sencillo: el cliente recibe la respuesta de la función de Lambda exactamente como Lambda la devuelve.
+ **API Gateway** ofrece capacidades sofisticadas de gestión de solicitudes y respuestas. Puede definir validadores de solicitudes, transformar las solicitudes y las respuestas mediante la asignación de plantillas, la configuración de encabezados de solicitudes y respuestas y la implementación el almacenamiento en caché de las respuestas. API Gateway también es compatible con las cargas útiles binarias y los nombres de dominio personalizados y puede modificar las respuestas antes de que lleguen al cliente. Puede configurar modelos para la validación y transformación de solicitudes y respuestas mediante el esquema JSON.
### Escalado
+ **Las URL de función** se escalan directamente con los límites de simultaneidad de la función de Lambda y gestionan los picos de tráfico al escalar la función hasta el límite máximo de simultaneidad configurado. Una vez alcanzado ese límite, Lambda responde a las solicitudes adicionales con respuestas HTTP 429. No hay un mecanismo de colas integrado, por lo que la gestión del escalado depende totalmente de la configuración de la función de Lambda. De forma predeterminada, las funciones de Lambda tienen un límite de 1000 ejecuciones simultáneas por Región de AWS.
+ **API Gateway** proporciona capacidades de escalado adicionales además del escalado propio de Lambda. Incluye controles integrados de limitación y cola de solicitudes, lo que permite administrar los picos de tráfico con mayor facilidad. De forma predeterminada, API Gateway puede gestionar hasta 10 000 solicitudes por segundo por región, con una capacidad de ampliación de 5000 solicitudes por segundo. También proporciona herramientas para limitar las solicitudes en diferentes niveles (API, fase o método) a fin de proteger el backend.
### Supervisión
+ **Las URL de función** ofrecen un monitoreo básico a través de las métricas de Amazon CloudWatch, que incluyen el recuento de solicitudes, la latencia y las tasas de error. Obtiene acceso a métricas y registros estándar de Lambda, que muestran las solicitudes sin procesar que llegan a su función. Si bien esto proporciona una visibilidad operativa esencial, las métricas se centran principalmente en la ejecución de las funciones.
+ **API Gateway** proporciona capacidades de monitoreo integrales que incluyen métricas detalladas, registro y opciones de rastreo. Puede supervisar las llamadas a la API, la latencia, las tasas de error y las tasas de aciertos y errores de la caché a través de CloudWatch. API Gateway también se integra con AWS X-Ray para el rastreo distribuido y proporciona formatos de registro personalizables.
### Coste
+ **Las URL de función** siguen el modelo de precios estándar de Lambda: solo paga por las invocaciones de funciones y el tiempo de cálculo. No hay recargos adicionales para el punto de conexión URL en sí. Esto lo convierte en una opción rentable para API simples o aplicaciones de bajo tráfico si no necesita las características adicionales de la API Gateway.
+ **API Gateway** ofrece un [nivel gratuito](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) que incluye un millón de llamadas a la API recibidas para las API de REST y un millón de llamadas a la API recibidas para las API de HTTP. Después de esto, API Gateway cobra por las llamadas a la API, la transferencia de datos y el almacenamiento en caché (si están habilitados). Consulte la [página de precios](https://aws.amazon.com/api-gateway/pricing/) de API Gateway para conocer los costos de su propio caso práctico.
### Otras características
+ **Las URL de función** están diseñadas para ofrecer simplicidad e integración directa con Lambda. Son compatibles con los puntos de conexión HTTP y HTTPS, ofrecen soporte CORS integrado y proporcionan puntos de conexión de doble pila (IPv4 e IPv6). Si bien carecen de características avanzadas, destacan en situaciones en las que se necesita una forma rápida y sencilla de exponer las funciones de Lambda a través de HTTP.
+ **API Gateway** incluye numerosas características adicionales, como el control de versiones de las API, la administración de etapas, las claves de API para los planes de uso, la documentación de las API a través de Swagger/OpenAPI, las API de WebSocket, las API privadas dentro de una VPC y la integración de WAF para mayor seguridad. También es compatible con las implementaciones canarias, las integraciones simuladas para pruebas y la integración con otros Servicios de AWS más allá de Lambda.
## Selección de un método para invocar una función de Lambda
Ahora que ha leído los criterios para seleccionar entre las URL de función de Lambda y API Gateway y las principales diferencias entre ellas, puede seleccionar la opción que mejor se adapte a sus necesidades y utilizar los siguientes recursos para empezar a utilizarla.
------
#### [ Function URLs ]
**Comience a utilizar las URL de función con los siguientes recursos**
+ Siga el tutorial [Crear de una función de Lambda con una URL de función](urls-webhook-tutorial.md)
+ Obtenga más información sobre las URL de función en el capítulo [Creación y administración de URL de funciones de Lambda](urls-configuration.md) de esta guía
+ Pruebe el tutorial guiado integrado en la consola: **Crear una aplicación web sencilla** de la siguiente manera:
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Abra el panel de ayuda al elegir el icono de la esquina superior derecha de la pantalla.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/console_help_screenshot.png)
1. Seleccione **Tutoriales**.
1. En **Crear una aplicación web sencilla**, seleccione **Iniciar el tutorial**.
------
#### [ API Gateway ]
**Comience a utilizar Lambda y API Gateway con los siguientes recursos**
+ Siga el tutorial [Uso de Lambda con API Gateway](services-apigateway-tutorial.md) para crear una API de REST integrada con una función de Lambda de backend.
+ Obtenga más información sobre los distintos tipos de API que ofrece API Gateway en las siguientes secciones de la *guía para desarrolladores de Amazon API Gateway*:
+ [API de REST de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)
+ [API de HTTP de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)
+ [API de WebSocket de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html)
+ Pruebe uno o varios de los ejemplos de la sección de [tutoriales y talleres](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) de la *Guía para desarrolladores de Amazon API Gateway*.
------
# Tutorial: Creación de un punto de conexión de webhook mediante la URL de una función de Lambda
En este tutorial, creará la URL de una función de Lambda para implementar un punto de conexión de webhook. Un webhook es una comunicación ligera y basada en eventos que envía automáticamente datos entre aplicaciones mediante HTTP. Puede usar un webhook para recibir actualizaciones inmediatas sobre los eventos que ocurren en otro sistema, como cuando un nuevo cliente se registra en un sitio web, se procesa un pago o se carga un archivo.
Con Lambda, los webhooks se pueden implementar mediante URL de funciones de Lambda o API Gateway. Las URL de funciones son una buena opción para los webhooks sencillos que no requieren características como la autorización avanzada o la validación de solicitudes.
**sugerencia**
Si no está seguro de cuál es el mejor método para su caso específico, consulte [Selección de un método para invocar una función de Lambda mediante una solicitud HTTP](furls-http-invoke-decision.md).
## Requisitos previos
Para completar este tutorial, debe tener Python (versión 3.8 o posterior) o Node.js (versión 18 o posterior) instalados en su máquina local.
Para probar el punto de conexión mediante una solicitud HTTP, el tutorial utiliza [curl](https://curl.se/), una herramienta de línea de comandos que puede utilizar para transferir datos mediante varios protocolos de red. Consulte la [Documentación de curl](https://curl.se/docs/install.html) para obtener información sobre cómo instalar la herramienta si aún no la tiene.
## Crear la función de Lambda
Primero cree la función de Lambda que se ejecuta cuando se envía una solicitud HTTP a su punto de conexión de webhook. En este ejemplo, la aplicación remitente envía una actualización cada vez que se envía un pago e indica en el cuerpo de la solicitud HTTP si el pago se ha realizado correctamente. La función de Lambda analiza la solicitud y actúa de acuerdo con el estado del pago. En este ejemplo, el código solo imprime el ID del pedido para el pago, pero en una aplicación real, puede añadir el pedido a una base de datos o enviar una notificación.
La función también implementa el método de autenticación más común utilizado para los webhooks, la autenticación de mensajes basada en hash (HMAC). Con este método, tanto las aplicaciones de envío como las de recepción comparten una clave secreta. La aplicación de envío utiliza un algoritmo de hash para generar una firma única utilizando esta clave junto con el contenido del mensaje, e incluye la firma en la solicitud de webhook como un encabezado HTTP. Luego, la aplicación receptora repite este paso, genera la firma con la clave secreta y compara el valor resultante con la firma enviada en el encabezado de la solicitud. Si el resultado coincide, la solicitud se considera legítima.
Cree la función mediante la consola de Lambda con el tiempo de ejecución de Python o Node.js.
------
#### [ Python ]
**Crear la función de Lambda**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Cree una función básica “Hello world” de la siguiente manera:
1. Elija **Crear función**.
1. Seleccione **Crear desde cero**.
1. En **Nombre de la función**, introduzca **myLambdaWebhook**.
1. En **Tiempo de ejecución**, seleccione **python 3.14**.
1. Seleccione **Creación de función**.
1. En el panel **Código fuente**, sustituya el código existente al copiar y pegar lo siguiente:
```
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. En la sección **IMPLEMENTAR**, elija **Implementar** para actualizar el código de la función.
------
#### [ Node.js ]
**Crear la función de Lambda**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Cree una función básica “Hello world” de la siguiente manera:
1. Seleccione **Creación de función**.
1. Seleccione **Crear desde cero**.
1. En **Nombre de la función**, introduzca **myLambdaWebhook**.
1. En **Tiempo de ejecución**, seleccione **nodejs24.x**.
1. Seleccione **Creación de función**.
1. En el panel **Código fuente**, sustituya el código existente al copiar y pegar lo siguiente:
```
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. En la sección **IMPLEMENTAR**, elija **Implementar** para actualizar el código de la función.
------
## Crear la clave secreta
Para que la función de Lambda autentique la solicitud de webhook, utiliza una clave secreta que comparte con la aplicación que realiza la llamada. En este ejemplo, la clave se almacena en una variable del entorno. En aplicaciones de producción, no incluya información confidencial como contraseñas en el código de la función. En su lugar, [cree un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) y, a continuación, [utilice la extensión de Lambda AWS Parameters and Secrets](with-secrets-manager.md) para recuperar las credenciales en su función de Lambda.
**Crear y almacenar la clave secreta del webhook**
1. Genere una cadena larga y aleatoria utilizando un generador de números aleatorios criptográficamente seguro. Puede usar los siguientes fragmentos de código en Python o Node.js para generar e imprimir un secreto de 32 caracteres, o usar el método que prefiera.
------
#### [ Python ]
**Example código para generar un secreto**
```
import secrets
webhook_secret = secrets.token_urlsafe(32)
print(webhook_secret)
```
------
#### [ Node.js ]
**Example código para generar un secreto (formato de módulo ES)**
```
import crypto from 'crypto';
let webhookSecret = crypto.randomBytes(32).toString('base64');
console.log(webhookSecret)
```
------
1. Guarde la cadena generada como una variable de entorno para su función de la siguiente manera:
1. En la sección **Configuración** de su función, seleccione **Variables de entorno**.
1. Seleccione **Editar**.
1. Elija **Add environment variable** (Añadir variable de entorno).
1. En **Clave**, ingrese **WEBHOOK\$1SECRET**, y en **Valor**, ingrese el secreto que generó en el paso anterior.
1. Seleccione **Save**.
Tome nota de este secreto ahora, ya que tendrá que usarlo más adelante en el tutorial para probar la función.
## Crear el punto de conexión de la URL de función
Cree un punto de conexión de webhook mediante la URL de una función de Lambda. Dado que utiliza el tipo de autenticación `NONE` para crear un punto de conexión con acceso público, cualquier persona que disponga de la URL puede invocar su función. Para obtener más información sobre cómo controlar el acceso a las URL de las funciones, consulte [Control de acceso a las URL de las funciones de Lambda](urls-auth.md). Si necesita opciones de autenticación más avanzadas para su webhook, considere usar API Gateway.
**Crear el punto de conexión de la URL de función**
1. En la pestaña **Configuración** de su función, seleccione **URL de función**.
1. Elija **Create function URL** (Crear URL de función).
1. Para el **Tipo de autenticación**, seleccione **NINGUNO**.
1. Seleccione **Save**.
El punto de conexión de la URL de función que acaba de crear aparece en el panel **URL de función**. Copie el punto de conexión para usarlo más adelante en el tutorial.
## Probar la función en la consola
Antes de utilizar una solicitud HTTP para invocar la función mediante el punto de conexión de la URL, pruébela en la consola para confirmar que el código funciona según lo previsto.
Para verificar la función en la consola, primero debe calcular la firma de un webhook utilizando el secreto que generó anteriormente en el tutorial con la siguiente carga útil de JSON de prueba:
```
{
"type": "payment.success",
"orderId": "1234",
"amount": "99.99"
}
```
Use uno de los siguientes ejemplos de código de Python o Node.js para calcular la firma del webhook con su propio secreto.
------
#### [ Python ]
**Calcular la firma del webhook**
1. Guarde el siguiente código en un archivo denominado `calculate_signature.py`. Reemplace el secreto del webhook en el código por su propio valor.
```
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. Calcule la firma mediante la ejecución del siguiente comando desde el directorio donde haya guardado el código. Copie la firma que genera el código.
```
python calculate_signature.py
```
------
#### [ Node.js ]
**Calcular la firma del webhook**
1. Guarde el siguiente código en un archivo denominado `calculate_signature.mjs`. Reemplace el secreto del webhook en el código por su propio valor.
```
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. Calcule la firma mediante la ejecución del siguiente comando desde el directorio donde haya guardado el código. Copie la firma que genera el código.
```
node calculate_signature.mjs
```
------
Ahora puede probar el código de función mediante una solicitud HTTP de prueba en la consola.
**Probar la función en la consola**
1. Seleccione la pestaña **Código** para su función.
1. En la sección **EVENTOS DE PRUEBA**, elija **Crear nuevo evento de prueba**.
1. Para **Event name (Nombre de evento)**, escriba **myEvent**.
1. En el panel **Evento JSON**, sustituya el código JSON existente al copiar y pegar lo siguiente. Reemplace la firma del webhook por el valor que calculó en el paso anterior.
```
{
"headers": {
"Content-Type": "application/json",
"x-webhook-signature": "2d672e7a0423fab740fbc040e801d1241f2df32d2ffd8989617a599486553e2a"
},
"body": "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}"
}
```
1. Seleccione **Save**.
1. Elija **Invoke (Invocar)**.
Debería ver una salida similar a esta:
------
#### [ 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
```
------
## Probar la función mediante una solicitud HTTP
Use la herramienta de línea de comandos curl para probar su punto de conexión de webhook.
**Probar la función mediante solicitudes HTTP**
1. En un programa de terminal o intérprete de comandos, ejecute el siguiente comando curl. Sustituya la URL por el valor del punto de conexión de la URL de función y sustituya la firma del webhook por la firma que calculó con su propia clave secreta.
```
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"}'
```
Debería ver los siguientes datos de salida:
```
{"received": true}
```
1. Inspeccione los registros de CloudWatch de su función para confirmar que analizó la carga útil correctamente de la siguiente manera:
1. En la consola de Amazon CloudWatch, abra la página [Grupos de registro](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups).
1. Seleccione el grupo de registro de la función (`/aws/lambda/myLambdaWebhook`).
1. Seleccione el flujo de registros más reciente.
Debería ver una salida similar a la siguiente en los registros de su función:
------
#### [ 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. Ejecute el siguiente comando curl para confirmar que el código detecta una firma no válida. Sustituya la URL por el punto de conexión de su propia URL de función.
```
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"}'
```
Debería ver los siguientes datos de salida:
```
{"error": "Invalid signature"}
```
## Eliminación de sus recursos
A menos que desee conservar los recursos que creó para este tutorial, puede eliminarlos ahora. Si elimina los recursos de AWS que ya no utiliza, evitará gastos innecesarios en su Cuenta de AWS.
**Cómo eliminar la función de Lambda**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Seleccione la función que ha creado.
1. Elija **Acciones**, **Eliminar**.
1. Escriba **confirm** en el campo de entrada de texto y elija **Delete**(Eliminar).
Cuando creó una función de Lambda en la consola, Lambda también creó un [rol de ejecución](lambda-intro-execution-role.md) para la función.
**Cómo eliminar el rol de ejecución**
1. Abra la página [Roles](https://console.aws.amazon.com/iam/home#/roles) en la consola de IAM.
1. Seleccione el rol de ejecución que creó Lambda. El rol tiene el formato de nombre `myLambdaWebhook-role-`.
1. Elija **Eliminar**.
1. Si desea continuar, escriba el nombre del rol en el campo de entrada de texto y elija **Delete** (Eliminar).