Всем доброго времени!
Возникла задача следующего рода. На сайте имеется хранилище нетекстовых файлов (допустим, архивы, аудио или видео). Оно лежит выше DOCUMENT_ROOT, поэтому недоступно по прямому обращению через http. Имеется php-скрипт (например, get.php), к которому идет обращение через http. Ему передается ID файла. Скрипт проверяет, можно ли отдать данному пользователю этот файл. Если можно, то формирует заголовки, прочитывает файл и отдает его браузеру в двоичном виде.
Теперь самое главное. В личном кабинете пользователя может быть что-то вроде видео- или аудиоплеера, который воспроизводит файлы из этого хранилища, обращаясь к ним по URL. Т.е. плеер напрямую забирает файл из get.php, а проверка идет внутри get.php.
Нужно запретить прямой доступ к get.php, чтобы пользователь не мог просто взять и скачать файл, введя в браузер что-то вроде http//site.ru/get.php?file_id=137&user_id=15
Первое, что приходит в голову, это смотреть $_SERVER['HTTP_REFERER']. Если он есть, и значение в нем содежит site.ru, то отдавать файл, а нет - так нет. Но это легко подделать. Существует ли более надежный способ?
Полная Версия: Безопасный аналог HTTP_REFERER
У меня первое, что приходит в голову - это сделать аутентификацию. И только зарегистрированный юзер сможет получить инфу. Причем, только ту, что ему разрешена.
Второе, что приходит в голову
- это сделать временное ограничение для ссылки. Например, ввести какой-нибудь идентификатор и записывать в БД, с указанием времени действия.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Второе, что приходит в голову
- это сделать временное ограничение для ссылки. Например, ввести какой-нибудь идентификатор и записывать в БД, с указанием времени действия.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (sergeiss @ 27.04.2014 - 13:49) |
| это сделать аутентификацию. сделать временное ограничение для ссылки. |
В обоих случаях авторизованный пользователь сможет скачать файл. А надо, чтоб он мог лишь просматривать его плеером.
| Цитата (Novascriptum @ 27.04.2014 - 12:27) |
| Нужно запретить прямой доступ к get.php |
Эйчтиакцессом.
Если плеер тащит по http, то в эйчтиакцессе разрешить только айпишнику сервера.
_____________
Бесплатному сыру в дырки не заглядывают...
| Цитата (FatCat @ 27.04.2014 - 15:20) |
| Если плеер тащит по http, то в эйчтиакцессе разрешить только айпишнику сервера. |
IP будет не серверовский, а клиентский, потому что плеер - это JS. А он исполняется на клиентской стороне, и запрос, соответственно, со стороны клиента, а не сервера.
Нельзя.
"Просмотреть" в плеере - это загрузить в браузер.
Так что, в коде страницы все равно будут видны пути.
Помимо этого, еще есть кеш браузера, он вообще тебе неподконтролен.
Как вариант, сделай "превьюшки", ограниченные временем (10-15 секунд), и вот именно они будут доступны к просмотру.
_____________
[продано копирайтерам]
"Просмотреть" в плеере - это загрузить в браузер.
Так что, в коде страницы все равно будут видны пути.
Помимо этого, еще есть кеш браузера, он вообще тебе неподконтролен.
Как вариант, сделай "превьюшки", ограниченные временем (10-15 секунд), и вот именно они будут доступны к просмотру.
_____________
[продано копирайтерам]
| Цитата (AllesKlar @ 27.04.2014 - 16:39) |
| Так что, в коде страницы все равно будут видны пути. Помимо этого, еще есть кеш браузера, он вообще тебе неподконтролен. |
Браузеру можно запретить кешировать ресурсы, для этого, вроде, есть специальные теги и заголовки.
А вот про пути в коде страницы - это и суть вопроса. Если ресурс запрошен JavaScript-ом сайта - разрешаем доступ. Если пользователь пытается скачать по этой ссылке - запретить. Вопрос именно в этом.
HTTP_REFERER позволяет решить это, но, как я уже сказал, его можно подделать.
| Цитата |
| HTTP_REFERER позволяет решить это, но, как я уже сказал, его можно подделать. |
точно так же можно и проигнорировать запрет на кэширование.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (Novascriptum @ 27.04.2014 - 15:16) |
| плеер - это JS |
То есть, к гет.пхп обращается клиентская страница? Не важно, скриптом, флешкой или просто кодом вставки...
Тогда от скачивания не защитить никак. Даже чайники нынче умеют рыться в кеше в поисках желаемого файлика.
Я предположил, что отдается потоковое видео по какому-то хитрому протоколу...
_____________
Бесплатному сыру в дырки не заглядывают...
И все же скачивание можно запретить. Конечно это тоже не 100% защита, но 95% пользователей отсеет. Видео нужно отдавать как поток. Это умеют медиа-сервера, такие как red5 или wowza
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Здесь расположена полная версия этой страницы.