2010-09-14 2 views
2

У меня есть защищенный паролем каталог Apache, заполненный текстовыми файлами и файлами фильмов. В настоящее время я загружаю содержимое текстовых файлов, используя cURL, передавая имя пользователя и пароль информацию с CURLOPT_USERPWD. Для фильмов я установил для OBJECT и EMBED src значение http://username:[email protected]/file.mov. В обоих случаях имя пользователя и пароль выведены из $_SERVER['PHP_AUTH_USER'] и $_SERVER['PHP_AUTH_PW'], соответственно. Если это не сработает, пользователю будет предложено предоставить новые учетные данные универсальному всплывающему окну HTTP.Как правильно загружать и защищать HTML файлы с защитой паролем?

Есть ли более правильный способ сделать это? Или встраивает фильмы, защищенные паролем, только багги/плохие идеи?

Вышеуказанный метод приводит к двум (связанным?) Проблемам. Во-первых, (насколько я могу сказать) случайным образом кажется, что часть username:[email protected] не передается при встраивании фильма, и, следовательно, пользователь вынужден снова вводить свои учетные данные. Это редко происходит, и это только раздражает, но было бы неплохо исправить.

Во-вторых, это приводит к сбою Safari под Snow Leopard. Safari, в обязательном порядке, запрашивает у пользователя учетные данные, а затем зависает. Не защищенные паролем фильмы (или перемещение фильмов, защищенных паролем, в каталог, не защищенный паролем) загружаются штрафом. Эта проблема не существовала до Snow Leopard, но я не тестировал ее в более старых версиях Safari под Snow Leopard, так что это могло быть одним из последних обновлений.

ПРИМЕЧАНИЕ: Перемещение в другую систему входа (тем самым отрицая проблему), к сожалению, невозможно, поскольку другим программам, использующим эти файлы, требуется защита паролем Apache.

+0

Я хотел спросить раньше, как вы представляете (или привязываетесь) к текстовому контенту? – MrWhite

ответ

2

Вы Безопасное соединение? В противном случае, похоже, что имя пользователя/пароль открыты для любопытных глаз?

Я хотел бы иметь сценарий на стороне сервера (например, serve_content.php), который управляет службой вашего защищенного контента. А ссылка на него что-то вроде:.

src="serve_content.php?id=1234" 

serve_content.php проверяет, что пользователь вошел в систему Определяет файл из переданного идентификатора (который маскирует истинное расположение защищенного контента), так что может быть «1234» «mymovie .avi. И отправляет файл клиенту. например. используя readfile() с соответствующими заголовками.

Защищенный паролем каталог Apache предотвращает несанкционированный прямой доступ. Если вы регистрировали своих пользователей каким-либо другим способом, то ни один пользователь не мог бы напрямую получить доступ к файлу, только через serve_content.php.

+0

Защита паролем Apache требуется другими программами, поэтому, к сожалению, эти файлы будут всегда существовать в каталогах, защищенных паролем. :/ – mojojojo

+0

@mojojojo Это нормально. На самом деле хорошо, что эти файлы находятся в защищенном каталоге. Сценарий на стороне сервера (serve_content.php) является _immune_ для HTTP-аутентификации, поэтому вы можете напрямую читать файлы, но он все равно может проверить, чтобы убедиться, что пользователь аутентифицирован _before_, обслуживающий файл. – MrWhite

+0

, но не будет ли еще проблема, когда плагин QuickTime пытается загрузить файл. Это делается на стороне клиента, поэтому придется иметь дело с HTTP-аутентификацией, верно? – mojojojo

Смежные вопросы