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 icon expand , que muestra la configuración de la política seleccionada.

La columna ACTIONS contiene iconos para editar icon edit y eliminar icon delete políticas.

policies details

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.
Si utiliza la Sensedia API Platform para esto, aquí tiene cómo obtener la URL de autorización.

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 icon add 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 y access_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.

policies oauth

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.

policies flow

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 retorno 2xx significa que el evento se entregó con éxito y no es necesario enviarlo de nuevo.

policies retry settings

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:

**Recomendados**
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.

**No recomendados**
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.

Thanks for your feedback!

EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]