Документация на Flussonic Media Server

  1. Быстрый старт
  2. How To
  3. Потоковое вещание
    1. Публикация
    2. Прием мультикаста
    3. Варианты источников
    4. Переключение источников
    5. Плейлисты
    6. Наложение логотипа
    7. Миксер
    8. WebRTC публикация
    9. SDI
    10. Отправка на другие сервера
    11. Распознавание DVB субтитров
  4. Транскодер
    1. Логотип
    2. Hardware
    3. Скриншоты
    4. Мозаика
  5. DRM
    1. Simple CAS
    2. Conax DRM
    3. BuyDRM (KeyOS)
  6. Авторизация
    1. Конструктор бэкендов
    2. Сервис сбора статистики
    3. Domain lock
    4. Middleware
    5. Secure links
    6. Ограничение сессий
    7. Мультиавторизация
    8. Бан IP адресов
    9. DVR
    10. Aliaser
  7. API
    1. HTTP API
    2. Events API
    3. MySQL API
    4. SQL API для кластеров
    5. SNMP
  8. Кластер
    1. Ретрансляция
    2. Кластерный захват
    3. Балансировщик нагрузки
    4. Пиринг
    5. Организация CDN
  9. VOD
    1. Кэш
    2. Облако
    3. Транскодирование файлов
  10. DVR
    1. Настройка
    2. Timeshift
    3. Catchup
    4. Проигрывание
    5. Экспорт в MP4
    6. Доступ по протоколам
    7. Timelapse
    8. API
    9. Кластеризация DVR
    10. Репликация
    11. Облако
  11. Воспроизведение
    1. HLS
    2. embed.html
    3. HTML5 с низкой задержкой
    4. Плеер HTML5 с низкой задержкой
    5. MPEG-TS
    6. RTMP
    7. DASH
    8. HDS
    9. RTSP
    10. multicast, CBR UDP
    11. WebRTC проигрывание
    12. H.265
  12. Администрирование
    1. Установка
    2. Обновление

    3. Конфигурация
    4. Мониторинг
    5. Производительность
    6. Лицензия
    7. LUA скрипты
    8. Безопасность
    9. Let's Encrypt
    10. Миграция
  13. IPTV
    1. Захват спутникового видео
    2. Транскодирование
    3. Middleware в IPTV OTT
    4. Экспорт EPG со спутника
    5. Группы каналов

Авторизация

В Flussonic Media Server реализован механизм идентификации пользователей и отслеживания подключений с помощью авторизационных бэкендов. По протоколам HLS и HDS используются HTTP механизмы отслеживания сессий, а по протоколам RTMP, RTSP и MPEG-TS обрабатываются постоянные TCP сессии. Также отслеживается экспорт архива в формате MPEG-TS и MP4.

Процесс работы Flussonic Media Server с бэкендом описан в разделе «Авторизация через бэкенд».

Кроме того, Flussonic Media Server имеет встроенный механизм базовой защиты от вставки плеера на других сайтах. Более подробно про эту защиту вы можете прочесть в разделе Domain lock.

Flussonic Media Server также может проверять пароль при публикации потока. Более подробно про это вы можете прочесть в разделе Авторизация при публикации потока.

Авторизация через бэкенд Anchor Anchor x2

Flussonic Media Server поддерживает несколько авторизационных бэкендов.

Включение бэкенда

Бэкенды включаются путем добавления в конфигурационный файл директивы auth:

auth http://host;

Где host:

  • Оставлен пустым (по умолчанию)

    Если у директивы auth не указана опция, то Flussonic Media Server разрешает все обращения.

  • Сетевой адрес HTTP

    Если в качестве бэкенда указан сетевой адрес HTTP, то Flussonic Media Server будет делать HTTP запросы по этому адресу, передавая параметры сессии бэкенду.

  • Путь на диске

    Если в качестве бэкенда указан путь на диске, то он интерпретируется как путь к Lua скрипту, который будет выступать в роли бэкенда. Подробнее про скриптовое расширение Flussonic Media Server вы можете прочесть в статье, посвященной Lua скриптам.

Процедура авторизации через бэкенд Anchor Anchor x2

Схематически работа с бэкендом выглядит так:

Более детальное описание процедуры авторизации:

  1. Вы размещаете Flash-плеер или HTML тег video на веб-сайте или middleware, указывая в пути ключ авторизации (token), который был создан веб-сайтом, одним из этих способов:

    • В виде query string для HLS, HDS, HTTP MPEG-TS и других доступов по HTTP:

      http://192.168.2.3:8080/stream1/manifest.f4m?token=60334b207baa

      http://192.168.2.3:8080/stream1/index.m3u8?token=60334b207baa

    • В виде адреса для RTMP: rtmp application rtmp://192.168.2.3/static stream name: stream1?token=60334b207baa

    • В виде адреса для RTSP: rtsp://192.168.2.3/stream1?token=60334b207baa

    Если веб-сайт или middleware не указывает ключ token в пути к видео, то Flussonic Media Server генерирует token автоматически.

    Если в конфигурационном файле есть глобальная опция no_auto_token, то Flussonic Media Server не будет генерировать token и будет сразу возвращать статус 403, запрещая доступ к контенту.

  2. Получив запрос к потоку с ключом token, сервер Flussonic Media Server проверяет, открыта ли сессия (транслируется ли уже поток с сервера на этот клиент). Идентификатором сессии служит хеш-сумма, создаваемая для имени потока, IP-адреса клиента и token следующим образом:

    hash(name + ip + token)

    Если пользователь меняет свой IP адрес или переключается на другой поток, создается новая сессия.

  3. Если сессия не открыта, то Flussonic Media Server делает запрос к авторизационному бэкенду со следующими параметрами:

    • token.
      Token, переданный с веб-сайта или сгенерированный автоматически
    • name. Имя потока или файла
    • ip. IP пользователя
    • referer. HTTP Referer или RTMP pageUrl
    • total_clients. Общее количество открытых сессий на сервере
    • stream_clients. Количество открытых сессий на этом потоке
    • request_type. Значение new_session если создается новая сессия или update_session, если перепроверяется старая
    • type. Запрашиваемый протокол: hds, hls, rtmp, rtsp, mpegts или mp4
  4. Если бэкенд возвращает статус HTTP 200, сессия открывается или продолжается. Если бэкенд возвращает статус 403 или 401, сессия закрывается. Если бэкенд возвращает статус HTTP 301 или 302, запрос перенаправляется на адрес из HTTP заголовка Location. Все остальные статусы и таймауты интерпретируются как отсутствие данных, и запрос повторяется.

Сессия открыта

Если бэкенд разрешил открытие сессии, то, по умолчанию, Flussonic Media Server будет перепроверять сессию раз в 3 минуты, чтобы определять, что сессия всё ещё активна.

Чтобы поменять это время, отправьте HTTP заголовок X-AuthDuration. X-AuthDuration указывается в секундах.

Через 3 минуты (или другой промежуток времени, если он был изменен с помощью X-AuthDuration) запрос к сессии приведет к повторному обращению к бэкенду.

Если бэкенд недоступен или возвращает статус 500, то Flussonic Media Server сохранит предыдущий статус, полученный от бэкенда, и попробует ещё раз обратиться к нему.

Важно! Если вы поменяли в файле конфигурации настройку auth (добавили её, например), то это новое значение не применится к сессиям, которые уже открыты.

Сессия закрыта

Если бэкенд запретил открытие сессии, то информация о ней кешируется на сервере. В случае если пользователь пытается ещё раз с тем же token-ом открыть поток, Flussonic Media Server будет отказывать, не делая повторных обращений к бэкенду.

Веб-интерфейс

При просмотре из веб-интерфейса, администратор может смотреть видео без авторизации. То есть, обращений к бэкенду авторизации не производится.

Технически это реализовано так: при просмотре из веб-интерфейса генерируется специальный токен "ADM-xxx", который перехватывается Flussonic Media Server. Такой токен воспринимается как разрешение воспроизводить видео без авторизации.

Простейший пример скрипта авторизации (PHP) Anchor Anchor x2

Будем хранить авторизацию в файле auth.txt, заполненном такими данными:

user1:token1
user2:token2
user3:token3

Следующий скрипт на PHP будет проверять, содержится ли токен в этом файле, и если да - разрешать открытие сессии:

<?php

$get = print_r($_GET, true);
$token = $_GET["token"];
if(!$token || !strlen($token)) {
    header('HTTP/1.0 403 Forbidden');
    error_log("No token provided", 4);
    die();
}

$tokens = array();
$contents = explode("\n", file_get_contents("auth.txt"));
foreach($contents as $line) {
    if(strlen($line) > 3) {
        $parts = explode(":", $line);
        $tokens[$parts[1]] = $parts[0];
    }
}


if($tokens[$token]) {
    header("HTTP/1.0 200 OK");
    header("X-UserId: ".$tokens[$token]."\r\n");
    header("X-Max-Sessions: 1\r\n"); // Turn this on to protect from multiscreen
} else {
    header('HTTP/1.0 403 Forbidden');
}
?>

Сбор статистики с помощью X-UserId Anchor Anchor x2

Бэкенд при открытии сессии может отправить Flussonic Media Server HTTP заголовок X-UserId (к примеру, X-UserId: 100), который после закрытия сессии будет записан во внутреннюю базу данных вместе с данными о сессии. Вы можете запрашивать данные о сессии по протоколу MySQL с указанием X-UserId для сборки статистики.

Если бэкенд отправляет заголовок X-Unique: true вместе с X-UserId, то происходит отключение всех остальных открытых сессий, которые имеют такой же X-UserId. Важно отметить, что отключенные сессии на некоторое время остаются в памяти сервера и клиенты с теми же сочетаниями IP-адреса, имени потока и token не смогут получить доступ к контенту.

При использовании опции X-Unique следует генерировать различные token-ы при каждом обращении пользователя к странице.

Логирование запросов к бэкенду Anchor Anchor x2

Подробное описание того, как сделать логирование запросов с помощью PHP, находится в отдельной статье.

Таймаут авторизационного бекенда Anchor Anchor x2

В случае если авторизационный бекенд не успевает ответить за 3 секунды, то происходит следующая ситуация:

Cостояние сессии Что происходит
Не открыта Не открывается
Разрешена Остается открытой
Запрещена Остается запрещенной