Ориентированный на производительность способ защитить файлы на уровне PHP?
Существует доллар :
// build the List 10, 11, 12, 13, 14
List list2 = $(10, 15).toList();
maven:
org.bitbucket.dollar
dollar
1.0-beta3
7 ответов
РЕДАКТИРОВАТЬ: Как насчет гибрида для административного интерфейса? В 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, если они захотят это сделать).
Я бы пошел по этому пути, если вы не хотите правильно создавать настройки HTTP AUTH для каждой серверной платформы. Кроме того, если вы сделаете это правильно, вы можете сделать свою систему расширяемой, чтобы в будущем вы или ваши пользователи могли использовать другие типы (включая вариант на основе php, если они захотят это сделать).
Я бы пошел по этому пути, если вы не хотите правильно создавать настройки HTTP AUTH для каждой серверной платформы. Кроме того, если вы сделаете это правильно, вы можете сделать свою систему расширяемой, чтобы в будущем вы или ваши пользователи могли использовать другие типы (включая вариант на основе php, если они захотят это сделать).
Я бы просто запретил хотлинкинг любого файла, отличного от 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.
Я бы пошел с внедрением шлюза. Вы устанавливаете файл .htaccess на URL-адрес / assets /, указывающий на сценарий gateway.php, который будет отклонять, если оба учетных данных недействительны и этот конкретный файл не опубликован или не отображается.
Я немного запутался. Вам нужно защитить также файлы таблиц стилей и изображения? Возможно, лучше всего переместить эту папку.
Я полностью понимаю, откуда вы пришли с этим вопросом. У меня уже был OpenID на www.myopenid.com, но мне кажется немного странным полагаться на стороннюю организацию для такого важного входа в систему (также известного как мой постоянный «дом» в Интернете).
К счастью, легко перейти на использование собственного сервера в качестве сервера openID - фактически, это можно сделать всего с двумя файлами с phpMyID.
- Загрузите "phpMyID-0.9.zip" с http : //siege.org/projects/phpMyID/
- Переместите его на свой сервер и разархивируйте, чтобы просмотреть файл README, в котором все объясняется.
- В zip-архиве есть два файла: MyID.config.php, MyID .php . Я создал каталог с именем
/ OpenID http: /// OpenID - Определите имя пользователя и пароль, а затем создайте их хеш, используя:
echo -n ': phpMyID: '| openssl md5 - Откройте index.php в текстовом редакторе и добавьте хэш имени пользователя и пароля в заполнитель. Сохраните его.
- Протестируйте, перейдя на
http: /// OpenID / - ID теста работает с использованием: http://www.openidenabled.com/resources/openid-test / checkup /
Дополнительная информация: http://www.wynia.org/wordpress/2007/01/15/setting-up-an-openid-with-php/ , http : //siege.org/projects/phpMyID/ , http: //blog.stackoverflow. PHP может запрашивать загрузку, или вы можете передавать файлы через PHP, в зависимости от ваших потребностей.
Если вы сохраните HTML в базе данных CMS, это оставит только нечувствительные изображения и CSS.
Если у вас абсолютно есть Я думаю, что для включения и отключения доступа ко всем материалам лучше всего использовать символические ссылки. Храните все в области, недоступной для веб-доступа, и связывайте каждую папку с активами с помощью символьной ссылки на веб-область. Таким образом, если вам нужно полностью заблокировать людей, просто удалите символическую ссылку, а не все файлы.
Мне это не нравится, но это единственное, что я могу придумать, что соответствует вашим критериям.