Авторизация публикации

Как закрыть приём видео по RTMP(S) и WHIP: действие publish, учётные данные в строке запроса RTMP-URL и коды отказа, которые увидит кодировщик.

Завести видео в SirinVideo можно двумя принципиально разными способами, и авторизуются они по-разному.

Эта страница — про первый случай.

Общее правило: действие publish#

Публикация авторизуется отдельным действием, а не «правом на поток». Токен на просмотр публиковать не даёт, и наоборот — проверено на стенде для обоих протоколов.

{"sub":"encoder-1","exp":1787200000,
 "grants":[{"action":"publish","path":"ingest/cam1","protocols":["rtmp"]}]}

Привилегии (live, dvr, export, preview) описывают просмотр и к публикации отношения не имеют: маска привилегий никогда не может случайно стать правом публиковать. Поэтому компактный грант по метке (<метка>.<маска>) публикацию не открывает — нужно обычное разрешение с action: publish.

RTMP и RTMPS#

Конфигурация#

rtmp  1935;
rtmps 1936;

auth_backend {
    type   hs256;
    secret "секрет-подписи-токенов-публикаторов";
}

stream ingest/cam1 { input publish://rtmp; }

Поток без объявленного publish://-источника публикацию не принимает вовсе. Если ни один порт приёма не поднят, конфигурация не пройдёт проверку:

stream "ingest/cam1": a publish:// source needs an `rtmp`/`rtmps` listener (RTMP publish) or a `webrtc_udp_port` (WHIP)

Как адресуется публикатор#

Кодировщик идёт на rtmp://media.example.com:1935/<приложение>/<поток>. Сервер разрешает ключ так:

1. сначала ищет поток с путём <приложение>/<поток> — например ingest/cam1;
2. если не нашёл — ищет поток с голым именем <поток>.

Совпавший ключ и становится путём потока. Благодаря второму шагу поток с плоским именем (stream cam1) принимает публикатора, пушащего в любое приложение (rtmp://host/live/cam1).

Учётные данные едут только в строке запроса URL#

У RTMP нет заголовков — предъявить Authorization: Bearer физически негде. Единственный носитель — строка запроса:

rtmp://media.example.com:1935/ingest/cam1?token=$TOKEN

Хвост ?… срезается с обеих половин адреса — и с приложения (оно приезжает в составе tcUrl), и с ключа потока — до любого поиска потока. Это важно практически: без такой обрезки имя с хвостом просто не находилось бы, и включение авторизации выглядело бы как поломка совместимости.

Обе распространённые формы настройки кодировщика работают, обе проверены на стенде:

Если хвост стоит на обеих половинах, побеждает тот, что на ключе потока.

Проверка идёт до захвата шлюза потока#

У потока ровно один публикатор одновременно, и слот занимается после успешной авторизации. Порядок здесь — не деталь реализации, а свойство безопасности: если бы слот занимался первым, любой желающий без единого удостоверения занимал бы его и удерживал до истечения дедлайна чтения, запирая законного публикатора. Это отказ в обслуживании, не требующий вообще ничего.

Что увидит кодировщик при отказе#

Проверенная матрица (сервер с auth_backend { type hs256; }, поток ingest/cam1 с источником publish://rtmp):

В журнале сервера отказ виден одной строкой; успешный приём — тоже:

[ingest/cam1] rtmp publish denied — unauthorized
[ingest/cam1] rtmp publish denied — forbidden
[ingest/cam1] rtmp publisher connected

Выдача по RTMP авторизуется тоже#

Забрать поток по RTMP (rtmp://media.example.com:1935/ingest/cam1) — это отдельный гейт с действием read и привилегией live, полный аналог DESCRIBE в RTSP. Учётные данные передаются так же, строкой запроса; отказ приходит как NetStream.Play.Failed с той же парой причин (unauthorized / forbidden). Проверено:

Подробнее о просмотре — Авторизация просмотра.

WHIP (публикация WebRTC из браузера)#

Конфигурация#

webrtc 40000;

auth_backend {
    type   hs256;
    secret "секрет-подписи-токенов-публикаторов";
}

stream ingest/studio { input publish://whip; }

Точка входа — POST /s/{поток}/whip. В отличие от RTMP, здесь есть заголовки, поэтому токен можно передать и заголовком Authorization: Bearer, и как ?token=.

{"sub":"studio-1","exp":1787200000,
 "grants":[{"action":"publish","path":"ingest/studio","protocols":["whip"]}]}

Решение принимается до разбора SDP и до занятия слота публикатора — по той же причине, что и в RTMP.

Адрес сессии, который сервер возвращает в заголовке Location, — одноразовый идентификатор, привязанный к пути и роли. DELETE по чужому пути, неизвестный и уже удалённый идентификатор неотличимы: все три отвечают 404.

Активный забор источника#

Для input rtsp://…, input https://…m3u8, input udp://… соединение инициирует сам сервер — авторизовывать входящего некого. Учётные данные источника передаются в самом URL и являются исходящими:

stream cam1 { input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101; }

Подробнее — Приём видео: обзор.

Сводная таблица#

Проверка#

# 1. без токена — должно быть отказано
ffmpeg -re -f lavfi -i testsrc -c:v libx264 -t 3 -f flv \
  rtmp://media.example.com:1935/ingest/cam1
# 2. с токеном публикации — должно быть принято
ffmpeg -re -f lavfi -i testsrc -c:v libx264 -t 3 -f flv \
  "rtmp://media.example.com:1935/ingest/cam1?token=$TOKEN"

[rtmp @ 0x…] Server error: unauthorized
Error opening output rtmp://media.example.com:1935/ingest/cam1: Operation not permitted