Простое ограничение доступа по паролю.
When setting up a web server, there are often sections of the site that you wish to restrict access to. Web applications often provide their own authentication and authorization methods, but the web server itself can be used to restrict access if these are inadequate or unavailable.
In this guide, we"ll demonstrate how to password protect assets on an Apache web server running on Ubuntu 14.04.
Prerequisites
To get started, you will need access to an Ubuntu 14.04 server environment. You will need a non-root user with sudo privileges in order to perform administrative tasks. To learn how to create such a user, follow our .
Install the Apache Utilities Package
In order to create the file that will store the passwords needed to access our restricted content, we will use a utility called htpasswd . This is found in the apache2-utils package within the Ubuntu repositories.
Update the local package cache and install the package by typing this command. We will take this opportunity to also grab the Apache2 server in case it is not yet installed on the server:
- sudo apt-get update
- sudo apt-get install apache2 apache2-utils
Create the Password File
We now have access to the htpasswd command. We can use this to create a password file that Apache can use to authenticate users. We will create a hidden file for this purpose called .htpasswd within our /etc/apache2 configuration directory.
The first time we use this utility, we need to add the -c option to create the specified file. We specify a username (sammy in this example) at the end of the command to create a new entry within the file:
- sudo htpasswd -c /etc/apache2/.htpasswd sammy
You will be asked to supply and confirm a password for the user.
Leave out the -c argument for any additional users you wish to add:
- sudo htpasswd /etc/apache2/.htpasswd another_user
If we view the contents of the file, we can see the username and the encrypted password for each record:
- cat /etc/apache2/.htpasswd
Configure Apache Password Authentication
Now that we have a file with our users and passwords in a format that Apache can read, we need to configure Apache to check this file before serving our protected content. We can do this in two different ways.
The first option is to edit the Apache configuration and add our password protection to the virtual host file. This will generally give better performance because it avoids the expense of reading distributed configuration files. If you have this option, this method is recommended.
If you do not have the ability to modify the virtual host file (or if you are already using .htaccess files for other purposes), you can restrict access using an .htaccess file. Apache uses .htaccess` files in order to allow certain configuration items to be set within a file in a content directory. The disadvantage is that Apache has to re-read these files on every request that involves the directory, which can impact performance.
Choose the option that best suits your needs below.
Configuring Access Control within the Virtual Host Definition
Begin by opening up the virtual host file that you wish to add a restriction to. For our example, we"ll be using the 000-default.conf file that holds the default virtual host installed through Ubuntu"s apache package:
- sudo nano
Inside, with the comments stripped, the file should look similar to this:
/etc/apache2/sites-enabled/000-default.conf
Authentication is done on a per-directory basis. To set up authentication, you will need to target the directory you wish to restrict with a
/etc/apache2/sites-enabled/000-default.conf
Within this directory block, specify that we wish to set up Basic authentication. For the AuthName , choose a realm name that will be displayed to the user when prompting for credentials. Use the AuthUserFile directive to point Apache to the password file we created. Finally, we will require a valid-user to access this resource, which means anyone who can verify their identity with a password will be allowed in:
/etc/apache2/sites-enabled/000-default.conf
Save and close the file when you are finished. Restart Apache to implement your password policy:
- sudo service apache2 restart
The directory you specified should now be password protected.
Configuring Access Control with .htaccess Files
If you wish to set up password protection using .htaccess files instead, you should begin by editing the main Apache configuration file to allow .htaccess files:
- sudo nano /etc/apache2/apache2.conf
Find the
/etc/apache2/apache2.conf
. . .
Save and close the file when you are finished.
Next, we need to add an .htaccess file to the directory we wish to restrict. In our demonstration, we"ll restrict the entire document root (the entire website) which is based at /var/www/html , but you can place this file in any directory you wish to restrict access to:
- sudo nano /var/www/html/.htaccess
Within this file, specify that we wish to set up Basic authentication. For the AuthName , choose a realm name that will be displayed to the user when prompting for credentials. Use the AuthUserFile directive to point Apache to the password file we created. Finally, we will require a valid-user to access this resource, which means anyone who can verify their identity with a password will be allowed in:
/var/www/html/.htaccess
AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user
Save and close the file. Restart the web server to password protect all content in or below the directory with the .htaccess file:
- sudo service apache2 restart
Confirm the Password Authentication
To confirm that your content is protected, try to access your restricted content in a web browser. You should be presented with a username and password prompt that looks like this:
If you enter the correct credentials, you will be allowed to access the content. If you enter the wrong credentials or hit "Cancel", you will see the "Unauthorized" error page:
Conclusion
You should now have everything you need to set up basic authentication for your site. Keep in mind that password protection should be combined with SSL encryption so that your credentials are not sent to the server in plain text. To learn how to create a self-signed SSL certificate to use with Apache, follow . To learn how to install a commercial certificate, follow .
If you want to let more than one person in, you"ll need to create a group file that associates group names with a list of users in that group. The format of this file is pretty simple, and you can create it with your favorite editor. The contents of the file will look like this:
GroupName: rbowen dpitts sungo rshersey
That"s just a list of the members of the group in a long line separated by spaces.
To add a user to your already existing password file, type:
htpasswd /usr/local/apache/passwd/passwords dpitts
You"ll get the same response as before, but it will be appended to the existing file, rather than creating a new file. (It"s the -c that makes it create a new password file).
Mod_auth_basic and mod_authz_host which contain some more information about how this all works. The directive can also help in simplifying certain authentication configurations.
The various ciphers supported by Apache for authentication data are explained in Password Encryptions .
And you may want to look at the Access Control howto, which discusses a number of related topics.
Защита сайта средствами самого сервера Apache является одним из самых простых и в тоже время достаточно надежных способов. В этом случае Вам не нужно досконально продумывать стратегию безопасности, осуществлять ее проектирование и реализацию в коде. К тому же, для того, чтобы создать хорошую систему защиты нужно обладать достаточной квалификацией в этом вопросе. Используя встроенную защиту WEB-сервера Apache, Вы значительно упрощаете себе задачу - все, что Вы должны сделать - это выполнить несложную последовательность действий и Ваш сайт будет в достаточной мере защищен. В данной статье будут подробно описаны шаги и действия, которые Вам необходимо совершить. А в конце статьи будут приведены примеры файлов.htaccess .
Базовая аутентификация
В данной статье будет рассмотрен самый простой и доступный способ защиты - базовая аутентификация.
Замечание
Аутентификация - процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.
Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.
Замечание
При базовой аутентификации имя пользователя и его пароль передаются в сеть в открытом виде в течении всего сеанса, когда посетитель работает с защищенной директорией. Хакер может перехватить эту информацию, используя сетевой анализатор пакетов. Данный вид аутентификации не должен использоваться там, где нужна реальная защита коммерческо-ценной информации.
Замечание
WEB-сервер Apache поддерживает еще один вид защиты - digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль - mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.
Защита сайта - это просто
Для того чтобы защитить сайт, нужно выполнить следующую последовательность действий: создать файл с паролями, переписать его на сервер, создать файл.htaccess и тоже переписать его на сервер.
Для организации защиты понадобится.
- WEB-сайт и FTP-доступ к нему.
- Права на создание файлов.htpaccess и организацию защиты с помощью них.
- Утилита генерации паролей htpasswd.exe
Проверка работы файла.htaccess на сервере
Для того чтобы проверить есть ли у Вас права на организацию защиты с помощью файлов.htaccess создайте текстовый файл с именем.htaccess (первым символом идет точка, расширение отсутствует).
Замечание
Удобно создавать файлы.htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.
Замечание
Чтобы блокнот не подставлял автоматически расширение txt, в диалоге сохранения в выпадающем списке "тип файла" следует выбрать опцию "Все файлы".
Рис. Сохранение файлов.htaccess в блокноте
Проверка работы.htaccess
AuthType Basic
AuthName admin
require valid-user
Затем, через FTP-доступ, перепишите файл.htaccess на сайт, в ту директорию, которую вы хотите защитить.
Замечание
Действие файлов.htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.
Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл.htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.
Если после этого Вам открылся запрос на ввод логина и пароля, как на рисунке ниже, то тестирование прошло успешно и можно продолжать защиту директории.
Рис. Окно ввода логина и пароля
Если вы все сделали правильно, но окошко ввода пароля не появилось, то это значит, что настройки сервера запрещают Вам использовать файлы.htaccess для защиты директорий. Для решения данного вопроса Вам следует связаться с администрацией сервера, либо использовать другой тип защиты.
После того, как было выяснено, что файлы.htaccess работают, следует удалить с сайта только что написанный тестовый файл.
Замечание
Если по каким либо причинам Вы не можете удалить файл.htaccess, то создайте пустой файл.htaccess и замените им файл, лежащий на сервере.
Создание файла с паролями.htpasswd
Файл с паролями создается утилитой htpasswd.exe . Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache -ем в подкаталоге bin .
Замечание
Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: .
Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите "Пуск"->"Выполнить"
, введите в строку ввода cmd
и нажмите ОК
. Вам откроется окно утилиты CMD.
Рис. Окно утилиты CMD
Далее необходимо перейти в директорию, где находится утилита htpasswd.exe . Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.
Вы перешли в директорию с:Apache2in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:
Htpasswd -cm .htpasswd admin
- -cm - это ключи для утилиты. Ключ с - указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m - определяет шифрование по алгоритму MD5.
.htpasswd - имя файла с паролями (можете использовать любое имя).
admin - имя посетителя, которому будет разрешен доступ в закрытую область сайта.
В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2in появится файл.htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл.htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe
Htpasswd -m .htpasswd admin
Замечание
Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.
Итак, файл с паролями создан. Теперь Вам необходимо переписать его на сервер. Файлы с паролями очень желательно класть выше корневой директории сайта - туда, куда не будет доступа посетителям.
Если это невозможно, то файлы с паролями следует обязательно защитить. Это можно сделать с помощью файлов.htaccess. Чтобы защитить файлы с паролями создайте файл со строками, представленными в следующем листинге.
Защита файлов.htpasswd
deny from all
И положите его в ту директорию, где находится Ваш файл с паролями. Теперь посетители сайта не смогут получить к нему доступ.
Файл с паролем создан и защищен от несанкционированного доступа. Теперь необходимо создать файл.htaccess, который будет использоваться в защищаемой директории.
Создание файла.htaccess
Для защиты директории могут использоваться следующие директивы:
- AuthType - Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
AuthName - Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: "Private zone. Only for administrator!"
AuthUserFile - путь к файлу с паролями (.htpasswd).
AuthGroupFile - путь к файлу групп, если он существует.
Require - Одно или несколько требований, которые должны быть выполнены для получения доступа к закрытой области.
Пример файла.htaccess
AuthType Basic
require group admins
Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.
Внимание!
Относительные пути работать не будут!
Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.
Директива Require определяет кому разрешен доступ к закрытой области. Например,
- require valid-user - разрешен доступ всем прошедшим проверку
- require user admin alex mango - разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-userДоступ только пользователям admin и root
AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require user admin rootДоступ только пользователей из группы admins
AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
AuthGroupFile /usr/host/mysite/group
require group adminsЗапрет доступа только к файлу private.zip
AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user
Помимо этих модулей есть также mod_authn_core и mod_authz_core . Эти модули реализуют основные директивы, которые являются основными для всех модулей auth.
Вы, вероятно, также хотите взглянуть на « Контроль доступа» , в котором обсуждаются различные способы контроля доступа к вашему серверу.
Введение
Если у вас есть информация на вашем веб-сайте, которая чувствительна или предназначена только для небольшой группы людей, методы в этой статье помогут вам убедиться, что люди, которые видят эти страницы, являются людьми, которых вы хотели их видеть.
В этой статье рассматривается «стандартный» способ защиты частей вашего веб-сайта, который большинство из вас собирается использовать.
Заметка:
Если ваши данные действительно должны быть безопасными, рассмотрите возможность использования mod_ssl в дополнение к любой аутентификации.
Предпосылки
Директивы, обсуждаемые в этой статье, должны будут отправляться либо в файл конфигурации вашего основного сервера (обычно в разделе
Если вы планируете использовать файлы.htaccess , вам нужно будет иметь конфигурацию сервера, которая позволяет устанавливать директивы аутентификации в эти файлы. Это делается с AllowOverride директивы AllowOverride , которая указывает, какие директивы, если таковые имеются, могут быть помещены в файлы конфигурации для каждого каталога.
Поскольку мы говорим здесь об аутентификации, вам понадобится директива AllowOverride например:
AllowOverride AuthConfig
Или, если вы просто собираетесь указывать директивы непосредственно в файле конфигурации основного сервера, вам, конечно же, необходимо будет иметь разрешение на запись в этот файл.
И вам нужно немного узнать о структуре каталогов вашего сервера, чтобы узнать, где хранятся некоторые файлы. Это не должно быть ужасно сложно, и я постараюсь это понять, когда мы подошли к этому моменту.
Вам также необходимо убедиться, что модули mod_authn_core и mod_authz_core либо были встроены в двоичный файл httpd, либо загружены конфигурационным файлом httpd.conf. Оба этих модуля обеспечивают основные директивы и функциональные возможности, которые имеют решающее значение для конфигурации и использования аутентификации и авторизации на веб-сервере.
Получение работы
Вот основные принципы защиты паролем каталога на вашем сервере.
Во-первых, вам нужно создать файл паролей. Именно то, как вы это сделаете, будет зависеть от того, какой именно поставщик проверки подлинности вы выбрали. Об этом позже. Для начала мы будем использовать текстовый файл паролей.
Этот файл должен быть размещен где-то недоступным из Интернета. Это значит, что люди не могут загрузить файл паролей. Например, если ваши документы поданы из /usr/local/apache/htdocs , вы можете захотеть поместить файлы с паролями в /usr/local/apache/passwd .
Чтобы создать файл, используйте утилиту htpasswd , поставляемую с Apache. Это будет находиться в каталоге bin везде, где вы установили Apache. Если вы установили Apache из стороннего пакета, это может быть в вашем пути выполнения.
Чтобы создать файл, введите:
htpasswd -c /usr/local/apache/passwd/passwords rbowen
Предоставление более чем одному лицу в
Указанные выше директивы позволяют только одному человеку (в частности, кому-то с именем пользователя rbowen) войти в каталог. В большинстве случаев вы захотите AuthGroupFile более одного человека. Здесь находится AuthGroupFile .
Если вы хотите включить более одного человека, вам нужно создать файл группы, который связывает имена групп со списком пользователей в этой группе. Формат этого файла довольно прост, и вы можете создать его с помощью своего любимого редактора. Содержимое файла будет выглядеть так:
GroupName: rbowen dpitts sungo rshersey
Это всего лишь список членов группы в длинной строке, разделенной пробелами.
Чтобы добавить пользователя в уже существующий файл паролей, введите:
htpasswd /usr/local/apache/passwd/passwords dpitts
Вы получите тот же ответ, что и раньше, но он будет добавлен к существующему файлу, а не к созданию нового файла. (Это -c делает его созданием нового файла паролей).
Теперь вам нужно изменить файл.htaccess или блок
AuthType Basic AuthName "By Invitation Only" # Optional line: AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Require group GroupName
Теперь любой, кто указан в группе GroupName и имеет запись в файле password , будет включен, если они введут правильный пароль.
Есть еще один способ, чтобы несколько пользователей в этом были менее конкретными. Вместо создания группового файла вы можете просто использовать следующую директиву:
Require valid-user
Использование этой, а не Require user rbowen строки Require user rbowen позволит любому, кто указан в файле паролей, и кто правильно вводит свой пароль.
Возможные проблемы
Из-за того, как указана базовая проверка подлинности, ваше имя пользователя и пароль должны быть проверены каждый раз, когда вы запрашиваете документ с сервера. Это даже если вы перезагружаете одну и ту же страницу и для каждого изображения на странице (если они происходят из защищенного каталога). Как вы можете себе представить, это немного замедляет работу. Объем, который он замедляет, пропорционален размеру файла паролей, потому что он должен открыть этот файл и перейти по списку пользователей до тех пор, пока он не получит ваше имя. И он должен делать это каждый раз, когда страница загружается.
Следствием этого является то, что существует практическое ограничение того, сколько пользователей вы можете поместить в один файл паролей. Это ограничение будет зависеть от производительности вашего конкретного сервера, но вы можете ожидать замедление после получения нескольких сотен записей и, возможно, захотите рассмотреть другой метод аутентификации в то время.
Альтернативное хранение паролей
Поскольку сохранение паролей в текстовых файлах имеет указанные выше проблемы, вы можете захотеть сохранить свои пароли в другом месте, например, в базе данных.
Использование нескольких поставщиков
С внедрением новой архитектуры аутентификации и авторизации, основанной на провайдере, вы больше не заблокированы ни одним методом проверки подлинности или авторизации. Фактически любое количество поставщиков может быть смешано и согласовано, чтобы предоставить вам именно ту схему, которая соответствует вашим потребностям. В следующем примере используются оба поставщика аутентификации на основе файлов и LDAP.
В этом примере поставщик файлов сначала попытается выполнить аутентификацию пользователя. Если он не может аутентифицировать пользователя, будет вызываться поставщик LDAP. Это позволяет расширить область проверки подлинности, если ваша организация реализует несколько хранилищ проверки подлинности. Другие сценарии аутентификации и авторизации могут включать в себя смешивание одного типа аутентификации с другим типом авторизации. Например, аутентификация в отношении файла паролей, который авторизовался в отношении каталога LDAP.
Подобно тому, как могут быть реализованы несколько поставщиков аутентификации, можно использовать несколько методов авторизации. В этом примере используется авторизация группы файлов, а также авторизация группы LDAP.
Чтобы получить авторизацию немного дальше, директивы контейнера разрешений, такие как
Помимо просто авторизации
Применение логики и упорядочения
Контроль того, как и в каком порядке будет применяться авторизация, в прошлом был загадкой. В Apache 2.2 был внедрен механизм аутентификации на основе провайдера, чтобы отделить фактический процесс аутентификации от полномочий авторизации и поддержки. Одним из побочных преимуществ было то, что поставщики аутентификации могли быть сконфигурированы и вызваны в определенном порядке, который не зависел от порядка загрузки самого модуля auth. Этот же механизм, основанный на поставщиках, был также перенесен в авторизацию. Это означает, что директива Require не только указывает, какие методы авторизации следует использовать, но также определяет порядок их вызова. Несколько методов авторизации вызывают в том же порядке, в котором в конфигурации появляются директивы Require .
С введением директив контейнера авторизации, таких как
Кэширование аутентификации
Могут быть случаи, когда аутентификация ставит неприемлемую нагрузку на поставщика или в вашу сеть. Это, скорее всего, затронет пользователей mod_authn_dbd (или сторонних / пользовательских поставщиков). Чтобы справиться с этим, HTTPD 2.3 / 2.4 вводит новый поставщик кэширования mod_authn_socache для кэширования учетных данных и снижения нагрузки на поставщиков (поставщиков) источника.
Это может значительно повысить производительность некоторых пользователей.
Больше информации
Вы также должны прочитать документацию для mod_auth_basic и mod_authz_host которые содержат дополнительную информацию о том, как все это работает. Директива также может помочь в упрощении определенных конфигураций проверки подлинности.
Различные шифры, поддерживаемые Apache для данных аутентификации, объясняются в разделе «Шифрование паролей» .
И вы можете захотеть взглянуть на « Контроль доступа» , в котором обсуждается ряд связанных тем.
Часто бывает нужно ограничить доступ пользователей к определенным зонам вашего сайта. Например, к административной части. Часто это делают, создавая свой механизм авторизации. Однако, существует способ защитить зоны сайта с помощью встроенных средств сервера и браузера. Простейшая авторизация носит название Apache Basic authorization. Это будет большая статья, так что приготовьтесь к основательному чтению. Но зато в ней будет все, что вам когда-нибудь понадобится для работы с этим видом авторизации.
Как это работает
Сначала, мы кладем на сервере файл.htaccess. В нем мы указываем, какую зону (или конкретный файл) хотим запаролить. Это может выглядеть примерно так:
AuthType Basic #тип авторизации
AuthName "Name" #имя авторизации
#местоположение файла с паролями
AuthUserFile /usr/host/mysite/.htpasswd
#пропускать любого пользователя,
#который ввел верные логин и пароль
require valid-user
Кроме того, на сайте может присутствовать файл паролей. У него простая структура:
логин:зашифрованный пароль
логин:зашифрованный пароль
...
Путь к этому файлу указывается в htaccess.
Разговор с сервером под увеличительным стеклом
Теперь давайте предположим, что кто-то набрал адрес запароленой директории. Что при этом произойдет? А вот что:
1.
Браузер просит у сервера страницу по адресу http://сайт/secret.
Сервер видит, что для этой страницы установлена защита. Он посылает браузеру заголовки:
WWW-Authenticate: Basic realm="My Realm"
Status: 401 Unauthorized
HTTP-Status: 401 Unauthorized
Здесь нужно сказать, что зона (realm) — важный параметр. Если требуется вести пользователя через несколько запароленых зон, не ко всем из которых пользователь должен иметь доступ, то как раз имя зоны будет определять залогинен пользователь для этого места или еще нет.
2. Получив эти заголовки, браузер рисует на экране форму запроса логина и пароля. Если пользователь нажимает "Cancel", браузер выдает все те данные, что шли за этими заголовками.
3. Если пользователь ввел логин и пароль, то они отсылаются серверу. Тот лезет в файл с паролями и смотрит там такую пару. Если находит, то посылает в ответ ту страницу, которую просил браузер в самом начале. Если нет, то вновь посылает заголовки авторизации.
4. В случае, если пользователь ввел верные логин и пароль, а сервер ответил запрашиваемой страницей, браузер запоминает введенные логин и пароль для этой зоны.
5. Затем, если браузер посылает серверу любой (!!!) запрос, он прикрепляет к нему пару — логин и пароль. Выглядит это так:
Authorization: Basic base64(login:pass)
То есть, пара логин-пароль зашифрована в base64. Еще раз обращу внимание — логин и пароль посылается теперь с любым запросом браузера. Для картинок, файлов стилей, скриптов, favico и всего остального. По сути, для получения каждого файла, вы проходите авторизацию. Только браузер это делает за вас.
6. Сервер, когда получает запрос, проверяет, не идут ли с ним еще и логин с паролем. Если идут, то сразу проводит проверку на авторизованность.
Запрос авторизации на Perl и PHP
Теперь настало время разобраться, как же вывести окно авторизации апача не силами htaccess, а силами скрипта на Perl или PHP. Я специально поставил эти два решения, на двух разных языках под один заголовок. Потому что теперь, зная механику, мы можем быстро прийти к выводу, что для появления окошка запроса авторизации, нужно лишь послать нужные заголовки. Этим и займемся.
#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
print "Status: 401 Unauthorized\n";
print "HTTP-Status: 401 Unauthorized\n";
print "Content-type: text/html\n\nCancel";
#PHP
header("WWW-Authenticate: Basic realm=\"My Realm\"");
header("Status: 401 Unauthorized");
header("HTTP-Status: 401 Unauthorized");
print "Вы нажали Cancel";
Результатом и в том и в другом случае, будет форма запроса авторизации.
Перехват авторизации на Perl
Допустим, пользователь ввел логин и пароль. Они отправляются на сервер. Но тут возникает проблема. Дело в том, что когда апач получает логин и пароль, он хочет сверить их в файле паролей. Но что если логины и пароли хранятся не в файле паролей а в базе данных? В этом случае, нужно проводить авторизацию скриптом до того, как это сделает апач.
Возникает затруднение: апач не передает в переменных окружения введенные логин и пароль. То есть, получить к ним доступ из Perl проблематично. Но возможно. Самое простое решение — использовать mod_rewrite. Допишите в файл htaccess строки:
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) —
Они добавят новую переменую окружения. Из Perl она будет видна как $ENV{HTTP_CGI_AUTHORIZATION}. Она будет содержать пару логин-пароль, закодированную в base64. Конечно, придется немного повозиться с тем, чтобы их перекодировать обратно, но это уже кое-что. Тем более, что возни там, собственно, не много:
$ENV{HTTP_CGI_AUTHORIZATION} =~ s/basic\s+//i;
my ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV{HTTP_CGI_AUTHORIZATION}));
Теперь у нас есть две переменные $REMOTE_USER и $REMOTE_PASSWD, с помощью которых можно проводить авторизацию силами скрипта, сверяя логин и пароль с чем душе угодно.
Перехват авторизации на PHP
Поддержка сессии на Perl и PHP
Кроме всего прочего, после того, как авторизация прошла успешно, в переменной окружения будет находиться логин авторизованного пользователя, который вызывает исполняемый скрипт. То есть, вы всегда будете знать кто именно сейчас запустил скрипт. Логин содержится в переменных:
#perl
$ENV{REMOTE_USER}
#php
$_SERVER
Вот такие дела
Большая получилась статья, как я и обещал. Но зато в ней рассмотрены основные принципы работы апачевой base-автроизации, а так же собраны решения некоторых проблем, которые могут возникнуть при работе с ней. Скажу честно, провел не один час, в поисках ответов на некоторые вопросы, решенные в этой статье. Надеюсь, она поможет сэкономить время другим программистам.
Ссылки по теме
- htaccess и htpasswd — как сделать авторизаию только силами апача
- htaccess.net.ru — сайт, посвященный возможностям управления сервером, при помощи файлов htaccess