Skip to content

Autorização

O Sapsan protege a reprodução e a publicação de streams. Há dois mecanismos: tokens estáticos na configuração e backends de auth externos a quem o servidor delega as decisões.

Como o token é passado

Um token é aceito de duas formas (o cabeçalho tem prioridade):

  • o cabeçalho Authorization: Bearer <token>;
  • o parâmetro de URL ?token=<token>.

Para o HLS basta abrir a playlist mestra com o token — o próprio Sapsan acrescenta ?token= em todos os URLs aninhados (variantes, segmentos, partes, init).

Tokens estáticos

auth:
  play_tokens:
  - viewer-secret-1
  publish_tokens:
  - publisher-secret-1
  • play_tokens — tokens de reprodução;
  • publish_tokens — tokens de publicação.

Uma requisição sem um token válido é negada. Se a seção auth existe, mas nem os tokens nem os backends corresponderam, o acesso é negado.

Backends de auth externos

As decisões podem ser delegadas a backends HTTP:

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

O Sapsan faz um POST para o url do backend com um corpo JSON:

{
  "kind": "play",                  // play ou publish
  "stream_name": "cam1",
  "proto": "hls",                  // protocolo: hls, dash, rtsp, m4f, ...
  "user_agent": "Mozilla/5.0 ...", // pode estar ausente
  "token": "viewer-secret-1",      // pode estar ausente
  "session_id": "..."              // identificador estável da sessão
}

A decisão é tomada pelo status HTTP da resposta (o corpo não é analisado):

  • 2xx — permitir;
  • 401 ou 403 — negar (a negação é cacheada — uma requisição idêntica repetida não chega ao backend);
  • qualquer outro status, a indisponibilidade ou o excesso de timeout_ms (padrão 1000 ms) marca o backend como caído;
  • vários backends são consultados em paralelo: basta um «permitir»; só negações — negar; todos os backends caídos — erro de «backend caído» (não uma negação silenciosa).

Sessões

A sessão de um espectador é identificada por quatro elementos: stream, tipo (play/publish), IP, token — requisições repetidas do mesmo espectador não criam sessões novas. Conexões de longa duração (RTSP, WebRTC) são reautorizadas periodicamente: se o backend revogar o acesso, a sessão é fechada. Os contadores de sessões (abertas, negadas, autorizadas) estão disponíveis no monitoramento.

Acesso ao Admin API

O Admin API é protegido por uma seção separada api_auth — veja Admin API.

Próximos passos