Integración: autorización flussonic¶
Esta página es para el desarrollador de un backend de autorización — el servicio que su negocio ya opera para decidir, por cada espectador, si puede reproducir. Si ese backend fue escrito para Flussonic, Catena habla la misma petición, así que funciona sin cambios.
Prefiera Tickets de Catena para todo lo nuevo: un backend responde en cada nuevo espectador, así que su velocidad y disponibilidad están en la ruta hacia el primer fotograma. Esta página es para mantener una integración existente mientras migra.
Cómo Catena llama a su backend¶
En un nuevo espectador el streamer envía a su backend una petición y reproduce solo lo que aprueba. Un allow se recuerda durante la ventana de reautorización — tres minutos por defecto — en lugar de preguntar de nuevo por cada segmento, así que su servicio se consulta cuando un espectador empieza y una vez por ventana, no miles de veces por minuto. Un backend puede acortar o alargar esa ventana por sesión con la cabecera de respuesta X-AuthDuration.
Conecte un backend en Auth & DRM → Upstreams: su URL y un protocolo. Puede añadir más de uno; Catena los consulta en paralelo y basta un allow. Si todos los backends están inalcanzables se rechaza al espectador, salvo que Allow by default esté activo.
El protocolo flussonic-get¶
Ponga el protocolo del upstream en flussonic-get y Catena emite un GET a su URL con estos parámetros de query:
| Parámetro | Significado |
|---|---|
name |
Nombre del stream (canal) |
proto |
Protocolo de entrega: hls, dash, mpegts, … |
ip |
Dirección IP del espectador |
request_type |
new_session en la primera petición, update_session en una reautorización |
request_number |
Cuenta de peticiones de autorización de esta sesión, desde 0 |
session_id |
Id estable de la sesión del espectador |
token |
El token que presentó el reproductor, si lo hay |
user_agent |
El user agent del reproductor, si se conoce |
duration, bytes, dvr |
Edad de la sesión en segundos, bytes servidos, si reproduce el archivo — en las actualizaciones |
stream_clients, total_clients |
Espectadores en este stream y en el streamer |
Responda con el código de estado y, opcionalmente, cabeceras:
2xx— allow.403— deny. Cualquier otro estado se trata como error del backend.X-UserId— la cuenta a la que pertenece la sesión; aparece en la pantalla Sesiones y agrupa las pantallas del espectador.X-AuthDuration— segundos que dura la decisión antes de una reautorización; anula la ventana por defecto para esta sesión.X-Max-Sessions— el límite de pantallas de la cuenta (aceptado y registrado).
El protocolo native¶
Para una integración nueva, ponga el protocolo en native: Catena envía un POST JSON en lugar del GET de arriba, con los mismos datos de sesión (kind, stream_name, proto, user_agent, token, session_id). Un 2xx permite, 401/403 deniegan. Las cabeceras de respuesta se leen exactamente como en flussonic-get.
Salud del backend¶
Catena no sondea su backend con una petición sintética — un middleware real solo vería una petición que no sabe responder. En su lugar, la insignia de salud junto a cada upstream en Auth & DRM se lee del último minuto de tráfico de autorización real: un backend que deja de responder, o empieza a fallar con cada espectador, pasa la insignia de ok a degraded o down, con su tiempo de respuesta reciente al lado. La insignia es lo que sus espectadores reciben de verdad.
Siguientes pasos¶
- Tickets de Catena — la vía recomendada y a dónde migrar esta integración.
- Proteger la reproducción — la misma política vista por el operador.
- Ciclo de vida de la sesión — qué le pasa a un espectador una vez que su backend lo dejó entrar.