Результата, подобному результату выполнения предыдущего сценария, можно достичь и без PHP-сценария. Сервер Apache предоставляет множество различных методов аутентификации, которые можно применять для определения правильности введенных пользователем данных. Наиболее простой из этих методов предполагает использование функциональных возможностей модуля mod_auth_digest, который сравнивает пары имя-пароль со строками текстового файла, хранящегося на сервере.
Чтобы вывод на экране пользователя был аналогичен результату выполнения предыдущего сценария, потребуется создать два HTML-файла — один для содержимого страницы, другой для сообщения об отказе в доступе. В предыдущих примерах были опущены некоторые элементы HTML-кода, но на самом деле в HTML-файлах присутствуют HTML-дескрипторы <html> и <body>.
Создадим несколько файлов. Содержимое файла content.php будут видеть пользователи, успешно прошедшие аутентификацию. В коде файла error401.php будет сообщение об отказе в доступе. Создавать страницу, которая будет отображаться в случае ошибки, вовсе не обязательно, но наличие такой страницы с полезной информацией свидетельствует о хорошем стиле и должном профессионализме. Учитывая, что такая страница будет отображаться пользователю при неудачной попытке войти в "закрытую" зону, полезной может оказаться информация о том, как зарегистрироваться и получить пароль, или как его переопределить и отправить по электронной почте, если вдруг пароль забыт.
content.php — пример содержимого
<html >
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251" />
<title>Вы на месте!</title>
</head>
<body>
<h1>Вы на месте!</h1>
<p>Вы зашли на секретную страницу</p>
</body>
</html>
error401.php — простое сообщение об ошибке 401
<body>
<h1>Покиньте эту страницу!</h1>
<p>Вам не разрешено просматривать этот ресурс.</p>
</body>
</html>
В этих файлах нет ничего нового. Для данного примера интерес представляет файл .htaccess. Он будет управлять доступом к файлам и подкаталогам каталога, включая активацию аутентификации.
.htaccess — с помощью файла .htaccess можно установить различные параметры сервера Apache, включая активацию аутентификации
C помощью файла .htaccess, можно устанавливать различные параметры, однако в этом примере все шесть строк относится к аутентификации.
Первая строка
ErrorDocument 401 /home/error401.php
указывает серверу Apachе, какой документ следует отобразить посетителям, не прошедшим аутентификацию. Директиву ErrorDocument можно использовать несколько раз в одном файле, чтобы предоставлять собственные страницы для сообщений одругих ошибках протокола HTTP? например, об ошибке 401. Синтаксис директивы такой:
ErrorDocument номер_ошибки URL
Важно, чтобы страница с сообщением об ошибке 401, в нашем случае error401.php, была доступна для посетителей. Она должна находится вне директории, которую защищают паролем.
Строка
AuthUserFile /home/test/.htpass
указывает серверу, где искать файл, содержащий пароли пользователей. Часто этот файл имеет имя .htpass, но можно выбрать произвольное имя. Не важно как этот файл называется, но важно, где он хранится. Он должен храниться в рамках дерева веб-каталогов — там, откуда пользователи его могут загрузить с помощью веб-сервера.
При базовой аутентификации имя пользователя и его пароль передаются в сеть в открытом виде в течение всего сеанса, когда посетитель работает с защищенным каталогом. Злоумышленник может перехватить эту информацию, используя сетевой анализатор пакетов. Данный вид аутентификации не должен использоваться там, где нужна реальная защита коммерческой информации.
Веб-север Apache поддерживает еще один вид защиты —digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленного по алгоритму необратимого шифрования MD5. Поэтому пароль, перехваченный при сканировании трафика, практически невозможно подобрать, особенно если он имеет большую длину. Для использования digest-аутентификации расскомментируйте в файле httpd.conf следующую строку:
LoadModule auth_digest_module modules/mod_auth_digest.so
.htpass — файл паролей хранит имена пользователей и зашифрованные пароли
Фай с паролями создается улитой htpasswd.exe. Если на локальной машине установлен веб-сервер Apahe? то данная улита находится в подкаталоге bin корневого каталога сервера.
Для работы с улитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы, как Far, Windows Commander и др. Мы рассмотрим работу с командной строкой с помощью улиты cmd, которая входит в поставку Windows.
В меню Пуск выберите команду Выполнить, и введите в строку ввода cmd и нажмите кнопку ОК.
Далее необходимо перейти в каталог, где находится улита htpasswd.exe. Если сервер Apache установлен в каталог С:/Apache2.2, тогда следует выбрать команду:
cd../../apache2.2/bin
и нажать клавишу <Enter>
После того как осуществлен переход в каталог bin, следует ввести команду для создания файла с паролем:
htpasswd -cm .htpass user1
Здесь:
В ответ на введенную команду улита htpasswd.exe предложит ввести парольи его подтверждение. Если оба пароля совпадают, то в завершении в каталоге С:/Apache2.2/bin появится файл .htpass, в котором будет находиться строка с именем пользователя и хеш-кодом его пароля.
Общий синтаксис вызова программы выглядит следующим образом:
htpasswd [-cmdps] файл_пароля имя_пользователя
или
htpasswd -b[cmdps] файл_пароля имя_пользователя пароль
Единственным ключем, который потребуется указывать, является -с. Этот ключ уведомляет программу htpasswd, что требуется создать новый файл. Используйте этот аргумент для создания первого пользователя. Будте внимательны и применяйте его для следующих пользователей, поскольку если файл уже существует, то программа htpasswd удалит его и создаст новый файл с тем же именем.
Необязательные ключи m, d, p, и s следует применять для выбора алгоритма шифрования (включая отказ от шифрования).
Ключ b заставляет программу ожидать пароль в качестве параметра, а не запрашивать его отдельно.
Итак, файл с паролями создан. Теперь переместим его директорию, которую мы защищаем паролем. Для этого откроем каталог apache2.2/bin/.htpass. Переместим созданный файл .htpass в директорию указанную в файле .htaccess.
Кроме указания отдельных санкционированных пользователей, можно указать, что доступ к ресурсу разрешен только прошедшим аутентификацию пользователям из определенной группы. В данном примере эта возможность не используется, и строка
AuthGroupFile /del/null
устанавливает параметр AuthGroupFile равным /del/null — специальный файл в системах Unix, который является гарантированно пустым.
Как и в примере с PHP, для использования HTTP-аутентификации защищаемой области следует присвоить имя. Это выполняет следующая строка:
AuthName "Realm-Name"
Имя области может быть произвольным, но следует помнить, что имя будет видно посетителям и поможет им понять, куда он пытается получить доступ. В нашем случае это "Realm-Name" (Имя области).
Поскольку сервер использует различные методы аутентификации, следует указать, какой именно метод будет использоваться:
AuthType Basic
Так же необходимо задать, кому разрешен доступ. Можно указать определенных пользователей, определенные группы или, как в данном примере, всех санкционированных пользователей.
Строка
require valid-user
определяет, что доступ разрешен всем пользователям прошедшим аутентификацию.
Аутентификацию такого типа легко настроить, однако с ней связано несколько проблем.
Имена и пароли пользователей храняться в текстовом файле. Каждый раз, когда браузер запрашивает файл, защищенный с помощью .htaccess, сервер должен проанализировать этот файл, а затем еще и файл пароля, чтобы попытаться найти соответствующее имя пользователя и пароль. Вместо использования файла .htaccess то же самое можно указать в файле httpd.conf — главном файле конфигурации веб-сервера. В то время как файл .htaccess анализируется при каждом запросе, файл httpd.conf анализируется только в момент запуска сервера. Подобный подход ускорит обработку запросов, но для внесения изменений придется остановить и перезапустить сервер.
Независмо от места хранения директив сервиса, файл паролей анализируется при каждом запросе. Это означает, что подобно другим рассмотренным технологиям, в которых используется двумерный файл, данный метод не годится в случае поддержки сотен или тысяч посетителей.
Веб-инструмент
Обсудить на форуме