Skip to content

Integration: flussonic authorization

This page is for the developer of an authorization backend — the service your business already runs to decide, per viewer, whether they may play. If that backend was written for Flussonic, Catena speaks the same request, so it works unchanged.

Prefer Catena tickets for anything new: a backend answers on every new viewer, so its speed and availability sit on the path to the first frame. This page is for keeping an existing integration working while you migrate.

How Catena calls your backend

On a new viewer the streamer sends your backend one request and plays only what it approves. An allow is then remembered for the reauthorization window — three minutes by default — instead of being asked again for every segment, so your service is hit when a viewer starts and once per window, not thousands of times a minute. A backend may shorten or lengthen that window per session with the X-AuthDuration response header.

You connect a backend in Auth & DRM → Upstreams: its URL and a protocol. You can add more than one; Catena queries them in parallel and one allow is enough. If every backend is unreachable the viewer is refused, unless Allow by default is on.

The flussonic-get protocol

Set the upstream protocol to flussonic-get and Catena issues a GET to your URL with these query parameters:

Parameter Meaning
name Stream (channel) name
proto Delivery protocol: hls, dash, mpegts, …
ip Viewer's IP address
request_type new_session on the first request, update_session on a reauthorization
request_number Count of authorization requests for this session, from 0
session_id Stable id of the viewer's session
token The token the player presented, if any
user_agent The player's user agent, if known
duration, bytes, dvr Session age in seconds, bytes served, whether it plays the archive — on updates
stream_clients, total_clients Viewers on this stream and on the streamer

Answer with the status code and, optionally, headers:

  • 2xx — allow. 403 — deny. Any other status is treated as a backend error.
  • X-UserId — the account this session belongs to; it shows up on the Sessions screen and groups a viewer's screens.
  • X-AuthDuration — seconds this decision holds before a reauthorization; overrides the default window for this session.
  • X-Max-Sessions — the account's screen limit (accepted and recorded).

The native protocol

For a new integration, set the protocol to native: Catena sends a JSON POST instead of the GET above, carrying the same session facts (kind, stream_name, proto, user_agent, token, session_id). A 2xx allows, 401/403 deny. The response headers are read exactly as for flussonic-get.

Backend health

Catena does not probe your backend with a synthetic request — a real middleware would only see a request it cannot answer. Instead, the health badge next to each upstream in Auth & DRM is read from the last minute of real authorization traffic: a backend that stops answering, or starts erroring on every viewer, turns the badge from ok to degraded or down, with its recent response time beside it. The badge is what your viewers are actually getting.

Next steps