Integração: autorização flussonic¶
Esta página é para o desenvolvedor de um backend de autorização — o serviço que o seu negócio já opera para decidir, por cada espectador, se ele pode reproduzir. Se esse backend foi escrito para o Flussonic, o Catena fala a mesma requisição, então ele funciona sem alterações.
Prefira Tickets do Catena para tudo o que é novo: um backend responde a cada novo espectador, então a sua velocidade e disponibilidade ficam no caminho até o primeiro quadro. Esta página é para manter uma integração existente enquanto você migra.
Como o Catena chama o seu backend¶
Em um novo espectador o streamer envia ao seu backend uma requisição e reproduz só o que ele aprova. Um allow é então lembrado durante a janela de reautorização — três minutos por padrão — em vez de ser perguntado de novo a cada segmento, então o seu serviço é consultado quando um espectador começa e uma vez por janela, não milhares de vezes por minuto. Um backend pode encurtar ou alongar essa janela por sessão com o cabeçalho de resposta X-AuthDuration.
Você conecta um backend em Auth & DRM → Upstreams: a sua URL e um protocolo. Pode adicionar mais de um; o Catena os consulta em paralelo e basta um allow. Se todos os backends estão inalcançáveis o espectador é recusado, a menos que Allow by default esteja ativo.
O protocolo flussonic-get¶
Defina o protocolo do upstream como flussonic-get e o Catena emite um GET à sua URL com estes parâmetros de query:
| Parâmetro | Significado |
|---|---|
name |
Nome do stream (canal) |
proto |
Protocolo de entrega: hls, dash, mpegts, … |
ip |
Endereço IP do espectador |
request_type |
new_session na primeira requisição, update_session numa reautorização |
request_number |
Contagem de requisições de autorização desta sessão, a partir de 0 |
session_id |
Id estável da sessão do espectador |
token |
O token que o reprodutor apresentou, se houver |
user_agent |
O user agent do reprodutor, se conhecido |
duration, bytes, dvr |
Idade da sessão em segundos, bytes servidos, se reproduz o arquivo — nas atualizações |
stream_clients, total_clients |
Espectadores neste stream e no streamer |
Responda com o código de status e, opcionalmente, cabeçalhos:
2xx— allow.403— deny. Qualquer outro status é tratado como erro do backend.X-UserId— a conta a que a sessão pertence; aparece na tela Sessões e agrupa as telas do espectador.X-AuthDuration— segundos que a decisão dura antes de uma reautorização; sobrepõe a janela padrão para esta sessão.X-Max-Sessions— o limite de telas da conta (aceito e registrado).
O protocolo native¶
Para uma integração nova, defina o protocolo como native: o Catena envia um POST JSON em vez do GET acima, carregando os mesmos dados de sessão (kind, stream_name, proto, user_agent, token, session_id). Um 2xx permite, 401/403 recusam. Os cabeçalhos de resposta são lidos exatamente como no flussonic-get.
Saúde do backend¶
O Catena não sonda o seu backend com uma requisição sintética — um middleware real só veria uma requisição que não sabe responder. Em vez disso, o selo de saúde ao lado de cada upstream em Auth & DRM é lido do último minuto de tráfego de autorização real: um backend que para de responder, ou começa a errar a cada espectador, muda o selo de ok para degraded ou down, com o seu tempo de resposta recente ao lado. O selo é o que os seus espectadores recebem de verdade.
Próximos passos¶
- Tickets do Catena — o caminho recomendado e para onde migrar esta integração.
- Proteger a reprodução — a mesma política vista pelo operador.
- Ciclo de vida da sessão — o que acontece a um espectador depois que o seu backend o deixou entrar.