Безопасные псевдо-потоковые FLV-файлы

Question

Мы используем RTMP для обеспечения потока медиаконтента через Wowza, и это работает как шарм. Wowza - действительно сильный и надежный медиа-сервер для бизнес-целей.

Но мы встретили проблему, она становится все больше и больше для нас. Многие новые клиенты не могут использовать RTMP по своим правилам брандмауэра, и проблема заключается в том, чтобы доставить для них мультимедийный контент для бизнеса. Но у всех нет проблем с http-псевдопотоком или просто прогрессивным, например, youtube или vimeo. Итак, мы должны сделать то же самое, но обеспечить безопасные ссылки на псевдо-потоковый трафик, чтобы предотвратить прямую загрузку, украв ссылки.

Мы используем несколько серверов, одно для Rails-приложения, второе для DB и третье - как медиа-сервер Wowza. Мое мышление - установить nginx на Wowza медиа-сервер и настроить на исходные файлы с псевдопотоком (в той же файловой системе, которую Wowza использует для потоковой передачи через веб-камеру).

Можете ли вы предложить использовать nginx с модулями http_secure_link_module и http_flv_module? Еще одна идея моего коллеги - создать крошечное приложение на стороне Wowza, чтобы получить зашифрованные ссылки и перевести его в локальную файловую систему, а затем получить доступ к файлам через X-Accel-Redirect и проверить аутентификацию через прямое подключение к БД.

спасибо

Answer 1

Я нашел решение, позвольте мне поделиться с кем-либо заинтересован в нем.

Прежде всего, мои ограничения заключались в том, чтобы использовать минимальные инструменты, насколько это возможно, поэтому идеально иметь встроенный модуль только на веб-сервере, а не на исходные бэкэнд-скрипты. И теперь у меня есть решение.

server { 
     listen  8080 ssl; 
     server_name your_server.com; 

     location /video/ { 
     rewrite /video/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.flv$ /flv/$3.flv?st=$1&e=$2; 
     } 

     location /flv/ { 
     internal; 
     secure_link $arg_st,$arg_e; 
     secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; 

     if ($secure_link = "") { return 403; } 
     if ($secure_link = "0") { return 403; } 

     root /var/www/; 
     flv; 

     add_header Cache-Control    'private, max-age=0, must-revalidate'; 
     add_header Strict-Transport-Security 'max-age=16070400; includeSubdomains'; 
     } 
} 

Реальные файлы FLV, расположенные в каталоге «/ var/www/flv». Для шифрования URL на стороне Руби, вы можете использовать этот скрипт:

expiration_time = (Time.now + 2.hours).to_i # 1326559618 
s = "#{YOUR_SECRET_PASSWORD_HERE}#{expiration_time}/flv/video1.flv" 
a = Base64.encode64(Digest::MD5.digest(s)) 
b = a.tr("+/", "-_").sub('==', '').chomp # HLz1px_YzSNcbcaskzA6nQ 
# => "http://your_server.com:8080/video/#{b}/#{expiration_time}/video1.flv" 

Так обеспеченный 2 часа URL (вы можете поместить его в флэш-плеер) выглядит следующим образом:

"http://your_server.com:8080/video/HLz1px_YzSNcbcaskzA6nQ/1326559618/video1.flv" 

P.S. Nginx должен быть скомпилирован со следующими опциями --with-http_secure_link_module --with-http_flv_module

$ cd /usr/src 
$ wget http://nginx.org/download/nginx-1.2.2.tar.gz 
$ tar xzvf ./nginx-1.2.2.tar.gz && rm -f ./nginx-1.2.2.tar.gz 

$ wget http://zlib.net/zlib127.zip 
$ unzip zlib127.zip && rm -f zlib127.zip 

$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.30.tar.gz 
$ tar xzvf pcre-8.30.tar.gz && rm -f ./pcre-8.30.tar.gz 

$ wget http://www.openssl.org/source/openssl-1.0.1c.tar.gz 
$ tar xzvf openssl-1.0.1c.tar.gz && rm -f openssl-1.0.1c.tar.gz 

$ cd nginx-1.2.2 && ./configure --prefix=/opt/nginx --with-pcre=/usr/src/pcre-8.30 --with-zlib=/usr/src/zlib-1.2.7 --with-openssl-opt=no-krb5 --with-openssl=/usr/src/openssl-1.0.1c --with-http_ssl_module --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --with-http_stub_status_module --with-http_secure_link_module --with-http_flv_module 
$ make && make install 

Answer 2

JW игрок и Flowplayer автоматически вернется к RTMPT (через HTTP), когда соединение RTMP не удается, и Wowza делает оба доступны. Я столкнулся с портом 1935, заблокированным в нескольких местах, и резервное копирование RTMPT через порт 80 обычно работает. Опасение там, конечно, состоит в том, что вам нужно, чтобы Wowza прослушивал порт 80 (в VHost.xml, где определено 1935, измените его на 80,1935), и это исключает возможность прослушивания любого вида веб-сервера на одном и том же порт.

Answer 3

Мы используем Wowza с портом 80 с нашими клиентами