Skip to content

Авторизация

Во 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 также может проверять пароль при публикации потока. Подробнее см. раздел Авторизация при публикации потока.

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

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

Во Flussonic реализованы три типа авторизации с помощью бэкенда:

  • "Базовая" авторизация (auth)

Используется для авторизации пользователей. Применяется ко всем видам сессий.

  • Авторизация сессий проигрывания (on_play)

Позволяет изменить настройки потока в момент обращения Flussonic к авторизационному бэкенду. См. Авторизация сессий проигрывания.

  • Авторизация сессий публикации (on_publish)

Позволяет настроить поток в момент обращения Flussonic к авторизационному бэкенду. См. Авторизация сессий публикации.

Warning

auth и on_play не могут сосуществовать в рамках настроек одного и того же потока.

auth и on_play в рамках настроек одного и того же потока:

stream example-stream {
  input fake://fake;
  auth /etc/flussonic/auth.lua;
  on_play /etc/flussonic/auth-on_play.lua;
}

Note

В случае одновременной настройки авторизационного бэкенда с помощью auth в настройках потока (stream) и on_play с помощью шаблона (template), путём его наследования в рамках настроек потока, авторизация будет осуществляться через on_play.

template example-template {
  input fake://fake;
  on_play /etc/flussonic/auth-on_play.lua;  
}

stream example-stream {
  template example-template;
  auth /etc/flussonic/auth.lua;
}

Как определить в каком случае использовать тот или иной тип авторизации?

При большом количестве серверов для транскодирования, а также зрителей или клиентов, публикующих потоки, Вам необходимо достичь быстрой скорости перенаправления запроса клиента на сервер с нужным потоком. В таких случаях используйте on_play и on_publish. Они обеспечивают быстрый и точный редирект на сервер с необходимым потоком, поскольку авторизационный бэкенд имеет способность резервироваться.

Описание процедуры авторизации

Этап 1.

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

* В виде строки запроса (*query string*) для HLS, HDS, HTTP MPEG-TS и других доступов по HTTP:

    `http://192.168.2.3:80/stream1/manifest.f4m?token=60334b207baa` для HDS

    `http://192.168.2.3:80/stream1/index.m3u8?token=60334b207baa` для HLS

* В виде адреса для 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 генерирует его автоматически.

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

Этап 2.

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

*hash(name + ip + token)*

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

Этап 3.

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

Параметр Описание
token Токен, переданный с веб-сайта или сгенерированный автоматически.
name Имя потока или файла.
ip IP-адрес пользователя.
referer HTTP Referer или RTMP page URL.
total_clients Общее количество открытых сессий на сервере.
stream_clients Количество открытых сессий на этом потоке.
request_type Указывает на тип запроса: new_session при создании новой сессии и update_session при проверке уже существующей.
type Указывает на протокол передачи данных и принимает одно из следующих значений: hds, hls, rtmp, rtsp, mpegts или mp4.

Этап 4.

Бэкенд возвращает статус HTTP-запроса.

Возможны следующие варианты ответа бэкенда:

Статус бэкенда Значение
HTTP 200 Открытие или продолжение сессии.
HTTP 403 или 401 Закрытие сессии.
HTTP 301 или 302 Перенаправление запроса на адрес из HTTP-заголовка Location.

Все остальные статусы и таймауты интерпретируются как отсутствие данных, и запрос повторяется.

Включение auth бэкенда {auth-enable}

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

auth http://host;

, где в качестве host можно указать:

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

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

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

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

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

Если в качестве бэкенда указан путь на диске, то он интерпретируется как путь к Lua-скрипту, который будет выступать в роли бэкенда.

Как можно "сбросить сессию" при неизменном токене?

Бывают ситуации, когда необходимо, чтобы сервер "сбрасывал" сессию при одинаковом token. Под "сбросом" сессии подразумевается закрытие текущей и создание новой сессии. Поскольку каждая сессия характеризуется своим идентификатором (session_id), который как раз зависит от значений IP-адреса, названия потока и токена (token), то необходимо изменить саму схему генерации идентификатора сессии. Это можно сделать с помощью параметра session_keys в настройках URL опции auth. session_keys определяет названия ключей, участвующих в вычислении session_id, позволяя настроить схему авторизации. Идентификатор сессии рассчитывается по следующей формуле (хеш-сумма):

*hash(name + ip + proto)*

На список элементов session_keys накладываются следующие ограничения:

  • ключи ip, name и proto обязательны и указываются явно (порядок не имеет значения);
  • количество элементов списка не ограничено (3 и более);
  • список может содержать дубликаты, которые обрабатываются явно, что повлияет на конечный результат;
  • разрешены только префиксы вида query., header. и cookie., которые позволяют указать желаемый ключ из контекста запроса query string, header или cookie, соответственно;
  • названия ключей после префиксов чувствительны к регистру и обрабатываются явно, т.е. как есть**;
  • только ip, name, proto и token могут быть использованы без префиксов;
  • элементы списка перечисляются через запятую , без пробелов ;
  • если значение ключа не найдено, в хеш будет включён ключ со значением undefined.
Ключ Статус
proto обязательный
name обязательный
ip обязательный
token факультативный
query. факультативный
header. факультативный
cookie. факультативный

Пример конфигурации:

stream example_stream {
  input fake://fake;
  auth PATH_TO_SCRIPT session_keys=ip,name,proto,token,query.test,header.X-Playback-Session-Id,cookie.test;
}

В примере выше ip, name, proto, token, query.test, header.X-Playback-Session-Id и cookie.test используются для вычисления ID сессии (session_id).

Применяется не только для auth, но также для on_play и on_publish.

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

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

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

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

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

Caution

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

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

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

Просмотр видео в веб-интерфейсе

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

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

Можно запретить Администратору просматривать видео, защищенное при помощи механизма бэкенд-авторизации.

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

Будем хранить авторизацию в файле 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

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

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

Warning

Отключенные сессии на некоторое время остаются в памяти сервера. Клиенты с теми же сочетаниями IP-адреса, имени потока и токена не смогут получить доступ к контенту.

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

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

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

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

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

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

Авторизация сессий проигрывания и публикации

Flussonic позволяет настроить авторизацию сессий проигрывания и публикации потоков. Таким образом, у Вас есть возможность передавать изменения в конфигурации конкретного потока во время авторизации без прямого доступа к конфигурации Flussonic. Вы можете вносить изменения в настройки Flussonic Media Server извне. Например, Вы можете определить логику распределения запросов к транскодерам при публикации потоков.

В чём польза такого подхода?

У вас не будет необходимости трогать конфигурационный файл сервера Flussonic каждый раз, когда Вам нужно внести изменения в настройки потоков, что уменьшает ручное управление серверами. Это особенно полезно при наличии большого количества потоков и серверов.

Note

Опция on_publish уже существует во Flussonic, но в контексте live-локаций (см. Расширенная валидация публикации). Flussonic поддерживает совместимость нового on_publish и уже существующего. Таким образом, Вам необязательно менять конфигурацию, чтобы поддержать существующую логику работы Вашего сервиса, если у Вас уже используется on_publish.

Авторизация сессий проигрывания

Caution

В том случае, когда происходит перезапись конфигурации потока, например, для конкретного пользователя, то эти изменения затронут всех зрителей, как уже проигрывающих поток, так и тех, кто только собирается его проигрывать. Конфигурация потока не уникальна для каждого зрителя. Предположим, 1000 зрителей смотрят онлайн трансляцию. Как только 1001-ый зритель проходит процедуру авторизации, авторизационный бэкенд отправляет Flussonic запрос на изменение конфигурации потока, запрещая проигрывание по протоколу HLS. Все клиенты, проигрывающие поток по HLS будут отключены, а их сессии проигрывания прервутся.

Чтобы настроить авторизацию для сессии проигрывания, используйте опцию on_play в рамках шаблона конфигурации template или потока stream:

template on-play-example {
  on_play /etc/flussonic/auth_play_backend.lua;
}

Давайте рассмотрим пример: изменим (перезапишем) источник потока с помощью авторизационного бэкенда, чтобы минимизировать прямое взаимодействие с конфигурацией сервера и потоков.

Для этого выполните несколько простых шагов:

Шаг 1. Выберите авторизационный бэкенд.

Мы будем использовать Lua-скрипт (auth_play_backend.lua) в качестве примера:

/etc/flussonic/auth_play_backend.lua:

t = {}
play_config  = {}

url = {}
url["url"] = "copy://clock_test"

play_config["inputs"] = {url}

t["config"] = play_config

return true, t

Шаг 2. Подключите авторизацию.

Чтобы это сделать, используйте опцию on_play для шаблона конфигурации template или потока stream:

/etc/flussonic/flussonic.conf:

stream example-stream {
  input fake://fake;
  on_play /etc/flussonic/auth_on_play.lua
}
stream clock_test {
  input fake://fake;
}

Шаг 3. Проиграйте поток.

Выберите протокол и проиграйте поток. Мы будем использовать протокол HLS. Тогда URL будет выглядеть следующим образом:

http://FLUSSONIC-IP/example-stream/index.m3u8

Итог: мы переписали источник нашего потока example-stream с fake://fake на copy://clock_test.

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

Авторизация с помощью on_publish осуществляется в момент создания публикации потока. Таким образом, Вы можете определить настройки для публикации потока и применить их в момент авторизации. Вам не нужно заранее настраивать публикацию во Flussonic через конфигурационный файл.

В чём польза такого подхода?

Давайте рассмотрим чем отличаются "базовая" конфигурация публикации от публикации через авторизационный бэкенд.

Создание публикации, следуя логике "базовой" конфигурации, осуществляется из конфигурационного файла сервера, и только потом стример может публиковать свой поток. Таким образом, сначала создаётся точка публикации, а потом приходит запрос на саму публикацию.

При публикации через авторизационный бэкенд этап создания публикации происходит в момент обращения к авторизационому бэкенду. То есть, стример передаёт запрос на публикацию в авторизационный бэкенд, при этом Flussonic ещё не "знает" куда она будет производиться. Авторизационный бэкенд затем передаёт Flussonic Media Server настройки публикации. В этот момент и происходит создание публикации.

Таким образом, авторизация происходит как раз во временном промежутке между клиентским запросом на публикацию и созданием публикации для последующего стриминга.

Чтобы настроитьавторизацию для сессии публикации, используйте опцию on_publish в рамках шаблона конфигурации template или потока stream:

template on-publish-example {
  input publish://;
  on_publish /etc/flussonic/auth_publish_backend.lua;
}

Процесс настройки не отличается от on_play.