Skip to content

Autorización

Sapsan protege la reproducción y la publicación de los streams. Hay dos mecanismos: tokens estáticos en la configuración y backends de auth externos a los que el servidor delega las decisiones.

Cómo se pasa el token

Un token se acepta de dos formas (la cabecera tiene prioridad):

  • la cabecera Authorization: Bearer <token>;
  • el parámetro de URL ?token=<token>.

Para HLS basta con abrir el playlist maestro con el token — Sapsan añade ?token= por sí mismo a todos los URL anidados (variantes, segmentos, partes, init).

Tokens estáticos

auth:
  play_tokens:
  - viewer-secret-1
  publish_tokens:
  - publisher-secret-1
  • play_tokens — tokens de reproducción;
  • publish_tokens — tokens de publicación.

Una petición sin un token válido se deniega. Si la sección auth existe pero no encajan ni los tokens ni los backends, el acceso se deniega.

Backends de auth externos

Las decisiones se pueden delegar a backends HTTP:

auth:
  upstreams:
    main:
      url: http://backend.example.com/auth
      timeout_ms: 3000

Sapsan hace un POST al url del backend con un cuerpo JSON:

{
  "kind": "play",                  // play o publish
  "stream_name": "cam1",
  "proto": "hls",                  // protocolo: hls, dash, rtsp, m4f, ...
  "user_agent": "Mozilla/5.0 ...", // puede estar ausente
  "token": "viewer-secret-1",      // puede estar ausente
  "session_id": "..."              // identificador estable de sesión
}

La decisión se toma por el estado HTTP de la respuesta (el cuerpo no se analiza):

  • 2xx — permitir;
  • 401 o 403 — denegar (la denegación se cachea — una petición idéntica repetida no llega al backend);
  • cualquier otro estado, la inaccesibilidad o superar timeout_ms (por defecto 1000 ms) marca el backend como caído;
  • varios backends se consultan en paralelo: basta con un «permitir»; si solo hay denegaciones — se deniega; si todos los backends están caídos — error de «backend caído» (no una denegación silenciosa).

Sesiones

La sesión de un espectador se identifica por cuatro elementos: stream, tipo (play/publish), IP, token — las peticiones repetidas del mismo espectador no generan sesiones nuevas. Las conexiones de larga vida (RTSP, WebRTC) se reautorizan periódicamente: si el backend revoca el acceso, la sesión se cierra. Los contadores de sesiones (abiertas, denegadas, autorizadas) están disponibles en el monitoreo.

Acceso al Admin API

El Admin API está protegido por una sección aparte api_auth — véase Admin API.

Siguientes pasos