Policies
Las políticas (policies) son una herramienta para administrar dos aspectos del proceso de recepción y distribución de eventos:
-
autorización de editores: las validaciones de seguridad garantizan que solo los editores autorizados puedan enviar eventos al Events Hub;
-
entrega de eventos: los reintentos automáticos que el sistema debe hacer si falla el primer envío de un evento.
Listado de políticas
La pantalla Políticas muestra todas las políticas existentes por orden de creación. En el campo Order by, puede seleccionar el orden que prefiera entre:
-
Creation (desc): por defecto. Lista las políticas desde la fecha de creación más reciente hasta la más antigua.
-
Creation (asc): lista las políticas desde la fecha de creación más antigua hasta la más reciente.
-
Name (desc): lista las políticas en orden alfabético, de la Z a la A.
-
Name (asc): lista las políticas en orden alfabético, de la A a la Z.
También puede buscar políticas por nombre utilizando el campo NAME.
La columna DETAILS contiene el icono , que muestra la configuración de la política seleccionada.
La columna ACTIONS contiene iconos para editar y eliminar políticas.
Opciones de seguridad
Los interceptores se utilizan para autorizar a los editores. Hay cinco tipos disponibles:
-
Access Token Validation
-
Client ID Validation
-
OAuth Validation
-
JWT Validation
-
IP Filtering Validation
Los endpoints de autorización se configuran por contextos en la pantalla Authorizations. Hay dos secciones:
-
OAUTH: para los interceptores OAuth Validation, Client ID Validation y Access Token Validation;
-
JWT: para el interceptor JWT Validation.
El uso de interceptores de seguridad es opcional. Sin embargo, si añade políticas a su handler, deberá configurar la URL de autorización vinculada al interceptor.
Con la excepción de "IP Filtering Validation", todas las políticas dependen de esta configuración para funcionar. |
Intentos automáticos de entrega
Cuando el primer intento de entregar un evento a un suscriptor falla, Events Hub puede reintentar la entrega, siguiendo los ajustes registrados. Estos ajustes incluyen:
-
número de reintentos (hasta 10 veces);
-
código de estado HTTP que desencadena un reintento;
-
tiempo de espera de la petición.
El Events Hub intenta reenviar eventos hasta que lo consigue o alcanza el número de intentos automáticos definidos en la configuración. Para aumentar las posibilidades de envío, se utiliza el algoritmo exponential backoff. Esto significa que el sistema espera un tiempo cada vez más largo entre intentos, evitando la congestión de la red.
Si la entrega sigue sin éxito, puede intentar la entrega manual a través de la pantalla Delivery Retry.
Creación de una política
Para crear una nueva política:
-
haga clic en el botón +;
-
rellene Name y Description (opcional). El nombre debe ser único. No es posible crear dos políticas con el mismo nombre;
-
Si lo desea, configure las opciones de seguridad y entrega de la política. Vea a continuación:
Seguridad
La sección HANDLER PUBLISHER SECURITY FLOW incluye los interceptores de seguridad que se pueden agregar al flujo.
Consulte cómo utilizar la Sensedia API Platform para proporcionar autorización de los publicadores. |
Elija el interceptor que desea aplicar haciendo clic en el icono junto al nombre del interceptor. Puede añadir más de uno:
-
Access Token Validation: valida un token de acceso pasado en la petición. Al seleccionarlo, debe introducir los siguientes datos:
-
Location: dónde se pasará el token de acceso, puede ser any (se seleccionarán todas las opciones); cookie; header; header o cookie; o query param.
-
Name: el nombre con el que se pasará el valor del token de acceso.
-
-
Client ID Validation: valida un ID de cliente pasado en la petición. Al seleccionarlo, debe introducir los siguientes datos:
-
Location: dónde se pasará el ID del cliente, puede ser any (se seleccionarán todas las opciones); cookie; header; header o cookie; o query param.
-
Name: el nombre con el que se pasará el valor de ID de cliente.
-
-
IP Filtering Validation: lista de IPs que pueden o no enviar peticiones.
-
En el campo List Type, se puede elegir entre:
-
Block List: lista de IPs que tendrán sus peticiones bloqueadas;
-
Allow List: lista de IPs que pueden enviar peticiones.
-
-
IP List: para incluir las direcciones IP. Debe separarlas por comas.
-
-
OAuth Validation: valida
client_id
yaccess_token_
pasados en el header de la petición.
La URL que proporciona la validación debe incluirse en la pantalla Authorizations y no hay campos para registrar.
-
JWT Validation: valida el token JWT (que debe enviarse en el patrón Bearer) pasado en la petición.
La URL que proporciona la validación debe incluirse en la pantalla Authorizations. Al seleccionar este interceptor, debe introducir:-
Location: dónde se pasará el token, que puede ser header; default JWT header (header JWT predeterminado); o query param.
-
Name: el nombre con el que se pasará el valor del token.
-
Los interceptores seleccionados se muestran en la sección Execution Flow. Si lo desea, puede:
-
editarlos haciendo clic en el icono
-
desactivarlos haciendo clic en el icono
-
reordenarlos haciendo clic en el interceptor y arrastrándolo a la posición deseada.
Las validaciones tendrán lugar en el orden en que aparecen en la pantalla. Si alguna de ellas falla, la petición se interrumpe.
Configuración de entrega
La sección Delivery Settings define el número máximo de intentos de reenvío automático y los códigos de estado que activarán estos intentos.
Configure los campos:
-
Automatic Retry Quantity: el número de intentos automáticos que se realizarán si falla el primer envío. Permite hasta 10;
-
Requisition Timeout: tiempo límite para esperar a que la URL del suscriptor devuelva cada intento de entrega. Permite hasta 30 segundos;
-
Status Code For Automatic Retry: códigos de estado HTTP que deben activar un intento automático.
-
Si introduce más de uno, sepárelos con una coma.
-
Si desea introducir una familia de códigos, utilice "xx":
4xx, 5xx
. -
Los códigos de la familia
200
no son aceptados en este campo. Esto se debe a que un retorno2xx
significa que el evento se entregó con éxito y no es necesario enviarlo de nuevo.
-
Códigos de estado recomendados
El campo Status Code For Automatic Retry permite la inclusión de códigos de la familia 400 y 500. Sin embargo, no todos son adecuados para el reintento. En las tablas a continuación, detallamos cuáles se recomiendan y cuáles no:
Código de estado |
Descripción |
¿Tiene sentido el reintento? |
Motivo |
408 |
Request Timeout |
Sí |
El servidor no respondió a tiempo. |
429 |
Too Many Requests |
Sí |
El usuario envió demasiadas peticiones en un periodo determinado. |
500 |
Internal Server Error |
Sí |
Código genérico que indica un fallo del servidor. Este fallo puede ocurrir debido a picos temporales de carga. |
502 |
Bad Gateway |
Sí |
Un servidor intermedio recibió una respuesta inválida de un servidor upstream. |
503 |
Service Unavailable |
Sí |
El servidor no está listo para procesar la solicitud. Esto puede deberse a mantenimiento o sobrecarga. |
504 |
Gateway Timeout |
Sí |
El servidor intermedio no respondió a tiempo. |
Código de estado |
Descripción |
¿Tiene sentido el reintento? |
Motivo |
400 |
Bad Request |
No |
La solicitud estaba mal formulada. Reintentar la misma petición resultará en el mismo error. |
401 |
Unauthorized |
No |
Se requiere autenticación o ha fallado. Reintentar no resolverá el problema sin la autenticación adecuada. |
403 |
Forbidden |
No |
El cliente no tiene permiso para realizar la acción. No hay motivo para reintentar. |
404 |
Not Found |
No |
No se ha encontrado el recurso solicitado. Reintentar no producirá la respuesta esperada. |
Share your suggestions with us!
Click here and then [+ Submit idea]