Используя PHP/Apache для ограничения доступа к статическим файлам (HTML, css, img, и т.д.)
Позволяет говорят, что у Вас есть много HTML, css, js, img и и т.д. файлов в рамках каталога на Вашем сервере. Обычно, любой пользователь на интернет-земле мог получить доступ к тем файлам путем простого ввода в полном URL как так: http://example.com/static-files/sub/index.html
Теперь, что, если Вы только хотите, чтобы авторизованные пользователи были в состоянии загрузить те файлы? Для этого примера, позволяет, говорят, что Ваши пользователи входят в систему сначала от URL как это: http://example.com/login.php
Как Вы позволили бы зарегистрированному пользователю просматривать файл index.html (или какой-либо из файлов под "статическими файлами"), но ограничивать файл всеми остальными?
Я предложил два возможных решения к настоящему времени:
Решение 1
Создайте следующий .htaccess файл под "статическими файлами":
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^(.*)$ ../authorize.php?file=$1 [NC]
И затем в authorize.php...
if (isLoggedInUser()) readfile('static-files/'.$_REQUEST['file']);
else echo 'denied';
Этот authorize.php файл чрезвычайно по упрощенному, но Вы получаете идею.
Решение 2
Создайте следующий .htaccess файл под "статическими файлами":
Order Deny,Allow
Deny from all
Allow from 000.000.000.000
И затем моя страница входа в систему могла добавить это .htaccess файл с IP для каждого пользователя, который входит в систему. Очевидно, это должно было бы также иметь некоторую стандартную программу очистки для чистки старый или больше используемый дюйм/с.
Я волнуюсь, что мое первое решение могло стать довольно дорогим на сервере как число пользователей и файлов, они получают доступ к увеличениям. Я думаю, что мое второе решение было бы намного менее дорогим, но является также менее безопасным из-за IP-спуфинга и и т.д. Я также волнуюсь, что запись этих IP-адресов в htaccess файл могла стать узким местом приложения, если существуют многие одновременные пользователи.
Какое из этих решений звучит лучше, и почему? С другой стороны, можно ли думать о совершенно другом решении, которое было бы лучше, чем любой из них?
4 ответа
Я бы подумал об использовании загрузчика PHP для обработки аутентификации и последующего возврата нужных файлов. Например, вместо сделайте что-нибудь вроде 
. 
Ваш загрузчик изображений может проверять сеансы, проверять учетные данные и т. Д., А затем решать, возвращать ли запрашиваемый файл в браузер. Это позволит вам хранить все ваши защищенные файлы вне корневого каталога, доступного через Интернет, поэтому никто не собирается просто загружать их или просматривать их «случайно».
Просто не забудьте вернуть правильные заголовки в PHP и сделать что-то вроде readfile () в php, и это вернет содержимое файла в браузер.
Я использовал эту настройку на нескольких крупных защищенных веб-сайтах, и она отлично работает.
Редактировать: Система, которую я сейчас создаю, использует этот метод для загрузки Javascript, изображений и видео, но CSS мы не очень беспокоимся о защите.
Создайте перезапишите карту , которая проверяет учетные данные пользователя и либо перенаправляет их на соответствующий ресурс, либо на страницу "доступ запрещен".
Сохранение содержимого файлов htaccess кажется кошмаром. Кроме того, ваша заявленная цель - предотвратить доступ к этому контенту неаутентифицированных пользователей неаутентифицированных IP-адресов клиентов , поэтому подход не подходит для этой цели:
Несколько пользователей может показаться, что они исходят с одного и того же IP-адреса
. Сеанс одного пользователя может исходить с нескольких адресов.
Я беспокоюсь, что мое первое решение может оказаться довольно дорогим на сервере, так как количество пользователей и файлов, к которым они обращаются, увеличивается
Если вы хотите предотвратить вымывание вашего контента и не хотите используйте HTTP-аутентификацию, тогда единственный разумный выбор - обернуть весь доступ к файлам дополнительным уровнем логики. Кроме того, вы не знаете, что использование PHP для этого является проблемой - вы это тестировали? Я думаю, вы были бы удивлены, насколько он может обеспечить пропускную способность, особенно если вы используете кеш-код операции.
Я предполагаю, что ваше «упрощение» оболочки решает такие проблемы, как mime-тип и кеширование.
С.
Я много думал над тем же вопросом. Мне одинаково не нравится, что движок PHP работает для каждого небольшого ресурса, который обслуживается. Я задавал вопрос в том же ключе несколько месяцев назад здесь, хотя и с другим фокусом.
Но у меня только что возникла ужасно интересная идея, которая может сработать.
Храните каталог под названием
/sessionsгде-нибудь на вашем веб-сервере.Каждый раз, когда пользователь входит в систему, создавайте пустой текстовый файл с идентификатором сессии в
/sessions. Например,123456В вашем приложении PHP, передавайте изображения следующим образом:
/sessions/123456/images/test.jpgВ вашем файле htaccess есть две команды перенаправления.
Одна переводит
/sessions/123456/images/test.jpgв/sessions/123456?filename=images/test.jpgВторая перехватывает любые обращения к
//sessions/(.*)и проверяет, существует ли указанный файл, используя флаг-f. Если/sessions/123456не существует, это означает, что пользователь вышел из системы или его сессия истекла. В этом случае Apache посылает сообщение 403 или перенаправляет на страницу ошибки - ресурс больше недоступен.
Таким образом, мы имеем квази-сессионную аутентификацию в mod_rewrite, выполняющую всего одну проверку "файл существует"!
У меня нет достаточного количества рутины, чтобы создавать утверждения mod_rewrite на лету, но их должно быть достаточно легко написать. (Я с надеждой смотрю в вашу сторону @Gumbo :)
Примечания и предостережения:
Просроченные файлы сессий должны быть быстро удалены с помощью задания cron, если только нет возможности проверить время жизни файла в .htaccess (что вполне возможно).
Изображение / ресурс доступен любому клиенту до тех пор, пока существует сессия, поэтому 100% защиты нет. Вы можете обойти это, добавив IP клиента в уравнение (= имя файла, который вы создаете) и выполнив дополнительную проверку на %{REMOTE_ADDR}. Это продвинутый уровень владения .htaccess, но я уверен, что это выполнимо.
URL-адреса ресурсов не статичны и должны быть получены каждый раз при входе в систему, поэтому кэширование невозможно.
Мне очень интересны отзывы об этом, любые недостатки или невозможности, которые я мог упустить из виду, и любые успешные реализации (у меня сейчас нет времени, чтобы провести тест самостоятельно).