Я ищу информацию о том, о чем я давно думал. Это очень общая проблема, может быть, есть решения, о которых я еще не думал.
У меня есть CMS на основе PHP.
Для каждой страницы, созданной в CMS, пользователь может загружать активы (файлы для загрузки, изображения и т. Д.).
Эти активы хранятся в каталоге, назовем его «/ myproject / assets» на основе каждой страницы (1 подкаталог = 1 страница, например «/ myproject / assets / page19283»)
Пользователь может «публиковать» (скрывать) страницы в CMS. Когда страница скрыта, и кто-то пытается получить к ней доступ, потому что они запомнили URL-адрес или они пришли из Google или что-то в этом роде, они получают сообщение «Не найдено».
Однако активы все еще доступны. Я также хочу защитить их, так что, когда пользователь не публикует страницу, они могут доверять, что она полностью исчезла. (Очень важно, чтобы судебные проблемы, такие как судебные приказы, опускали контент … Такие вещи могут произойти).
Наиболее очевидным способом является сохранение всех активов в защищенном каталоге (= недоступный веб-серверу) и использование PHP «front gate», который передает файлы через проверку. Когда проект должен быть водонепроницаемым, это то, как я сейчас иду, но мне это не нравится, потому что интерпретатор PHP работает для каждого крошечного изображения, сценария и таблицы стилей на сайте. Я бы хотел быстрее.
.htaccess (Deny from all or similar) не идеальна, потому что CMS должна быть портативной и способной работать в общей среде. Я бы хотел, чтобы он работал даже на IIS и других веб-серверах.
Лучший способ, о котором я могу думать сейчас, – переместить каталог активов конкретной страницы в безопасное место, когда он не опубликован, и переместить его обратно, когда он будет опубликован. Тем не менее, пользователь-администратор должен иметь возможность видеть страницу, даже если она не опубликована, поэтому мне придется обойти тот факт, что я должен обслуживать эти активы из безопасного каталога.
Может ли кто-нибудь подумать о способе, который позволяет прямому доступу Apache к файлам (= нет прохождения через PHP-скрипт), но все же контролируя доступ с помощью PHP? Я не могу.
Я также рассмотрел бы простое решение .htaccess, которое, вероятно, будет работать в большинстве общих средах.
EDIT: Как насчет гибрида для административного интерфейса? В ACP вы можете получить доступ с помощью метода PHP, в основном, отправлять все запросы файлов в файл аутентификации PHP, но для публики вы можете использовать HTTP AUTH / htaccess, чтобы определить доступность результата. это дает вам производительность на публичной стороне, но защита на стороне ACP.
СТАРОЕ СООБЩЕНИЕ:
.htaccess совместим с большинством сред Apache и IIS <7 (с использованием различных модулей ISAPI) при использовании операций типа mod_rewrite. Единственным исключением является IIS7 + новый модуль Rewrite, который использует файл web.config. ОДНАКО, я бы хотел быть тем, что вы могли бы эффективно генерировать / изменять файл web.config для этого экземпляра вместо использования .htaccess.
Учитывая это, вы можете настроить перенаправления с использованием метода перезаписи и перенаправить на свою страницу 404 (которая, надеюсь, отправит правильный заголовок 404). Это не соответствует 100%, потому что фактический актив должен быть тем, который дает заголовок 403, но … он работает.
Это маршрут, по которому я должен идти, если вы не хотите правильно создавать настройки HTTP AUTH для каждой серверной платформы. Кроме того, если вы сделаете это правильно, вы можете сделать вашу систему расширяемой, чтобы в будущем вы могли использовать другие типы вас или ваших пользователей (включая опцию на основе php, если они этого захочет).
Все, что нужно, должно храниться в безопасном месте, как вы предполагали.
если ваш сайт находится в / var / www / public_html
Вы размещаете активы за пределами доступной в Интернете области в / var / www / assets, которые PHP может вызывать для загрузки, или вы можете кормить файлы через PHP в зависимости от ваших потребностей.
Если вы сохранили HTML в базе данных CMS, это оставило бы только нечувствительные изображения и CSS.
Если вам абсолютно необходимо включить и отключить доступ ко всем материалам, я думаю, что ваш лучший выбор может быть символическим. Храните -все-в области, не доступной в Интернете, и sym свяжите каждую папку с активами в веб-области. Таким образом, если вам нужно полностью заблокировать людей, просто удалите символическую ссылку, а не удалите все файлы.
Мне это не нравится, но это единственное, что я могу придумать, что подходит вашему crtieria.
Я бы просто запретил Hotlinking любого не-HTML-файла, поэтому все материалы «активов» доступны только с HTML-страницы. Удаление (или защита) страницы просто удаляет все, не испортив всю файловую систему.
Я предполагаю, что «страница» генерируется PHP, а «активы» не требуют PHP. (Дайте мне знать, если я ошибаюсь.)
Вы можете переименовать папку с ресурсами. Например, переименуйте '/ myproject / assets / page19283' в '/ myproject / assets / page19283-hidden'. Это сломает все старые, заученные ссылки. Когда вы создаете страницу для пользователей-администраторов, которые ее видят, вы просто пишете URL-адреса, используя новое имя папки. В конце концов, вы знаете, скрыта ли страница или нет. Доступ к активам можно получить напрямую, если вы знаете «секретный» URL-адрес.
Для дополнительной безопасности переименуйте папку с кучей случайного текста и сохраните ее в своей таблице страниц (где бы вы не скрывали скрытый флаг): '/ myproject / assets / page19283-78dbf76B & 76daz1920bfisd6g & dsag'. Это значительно усложнит угадывание скрытого URL-адреса.
Просто добавьте или добавьте GUID в имя страницы в базе данных и каталог ресурсов в файловой системе. Администратор все равно сможет просмотреть его из интерфейса администратора, потому что ссылка будет обновлена, но GUID эффективно делает страницу незаметной для внешнего пользователя или поисковой системы.
Храните информацию в каталоге вне корневого веб-узла (то есть: один каталог за пределами public_html или htdocs). Затем используйте оператор readfile в скрипте php для проксирования файлов по запросу. readfile (…) в основном принимает один параметр – путь к файлу – и печатает содержимое этого файла.
Таким образом, вы можете создать барьер, где, если посетитель запрашивает информацию, скрытую за прокси-сервером, даже если они «запомнили» URL-адрес, вы можете отключить их с помощью 404 или 403.
Использовать X-Sendfile
Лучшим и наиболее эффективным способом является использование X-Sendfile. Однако перед использованием X-Sendfile вам необходимо будет установить и настроить его на своем веб-сервере.
Метод о том, как это сделать, будет зависеть от используемого веб-сервера, поэтому найдите инструкции для своего конкретного сервера. Это должно быть всего лишь несколько шагов для реализации. После внедрения не забудьте перезагрузить веб-сервер.
Как только X-Sendfile будет установлен, ваш PHP-скрипт просто должен будет проверить зарегистрированного пользователя, а затем предоставить файл. Очень простой пример использования сеансов можно увидеть ниже:
session_start(); if (empty($_SESSION['user_id'])){ exit; } $file = "/path/to/secret/file.zip"; $download_name = basename($file); header("X-Sendfile: $file"); header("Content-type: application/octet-stream"); header('Content-Disposition: attachment; filename="' . $download_name . '"'); Важная заметка:
Если вы хотите обслуживать файл с другой веб-страницы, такой как значение src изображения, вам нужно убедиться, что вы дезинфицируете свое имя файла. Вы не хотите, чтобы кто-то переписывал ваш скрипт и использовал «..» и т. Д. Для доступа к любому файлу в вашей системе.
Поэтому, если у вас есть код, который выглядит так:
<img src="myscript.php?file=myfile.jpg">
Затем вы захотите сделать что-то вроде этого:
session_start(); if (empty($_SESSION['user_id'])){ exit; } $file = preg_replace('/[^-a-zA-Z0-9_\.]/', '', $_GET['file']); $download_name = basename($file); header("X-Sendfile: $file"); header("Content-type: application/octet-stream"); header('Content-Disposition: attachment; filename="' . $download_name . '"');
Я бы пошел с внедрением шлюза. Вы устанавливаете файл .htaccess в / assets / URL, указывающий на скрипт gateway.php, который будет отрицать, что оба учетных данных недействительны, и этот конкретный файл не опубликован или не показывает его.
Я немного запутался. Вам нужно также защищать файлы и изображения стилей? Возможно, переместить эту папку – лучшая альтернатива.