Чтобы создать проверку пользователя во всплывающем окне достаточно следующего кода:
$username = 'admin';
$password = '111';
if (!isset($_SERVER['PHP_AUTH_USER'])) { header('WWW-Authenticate: Basic realm="Andrei"'); }
Тем не менее, желательно добавить немного функционала:
$username = 'admin';
$password = '111';
if (!isset($_SERVER['PHP_AUTH_USER'])) { header('WWW-Authenticate: Basic realm="Andrei"');
header('HTTP/1.0 401 Unauthorized');
echo 'Введите логин и пароль, чтобы получить доступ к странице'; exit; }
else { echo "<p>Привет {$_SERVER['PHP_AUTH_USER']}.</p>";
echo "<p>Вы ввели пароль {$_SERVER['PHP_AUTH_PW']} .</p>"; }
if ($_SERVER['PHP_AUTH_USER'] !== $username || $_SERVER['PHP_AUTH_PW'] !== $password )
{ header('HTTP/1.0 401 Unauthorized'); echo 'Имя пользователя или пароль введены неверно\n';
exit; }
Работать такой код будет довольно убого - если ввести пароль неверно не будет второй попытки. Придётся закрывать вкладку, идти в историю браузера и удалять там соответствующие данные.
Если пароль поменялся, пользователя со старым паролем не выкинет и т.д.
Пожалуйста, будьте осторожны при кодировании строк заголовка HTTP.
Чтобы гарантировать максимальную совместимость со всеми клиентами, ключевое слово "Basic" должно быть написано с прописной буквой "B", строка realm должна быть заключена в двойные (а не одинарные) кавычки, и ровно один пробел должен предшествовать коду 401 в строке заголовка HTTP/1.0 401. Параметры аутентификации должны быть разделены запятыми, как показано в приведенном выше примере дайджеста.
Очистить значения переменных $_SERVER['PHP_AUTH_USER']
и $_SERVER['PHP_AUTH_PW']
можно с помощью функции unset()
unset($_SERVER['PHP_AUTH_USER']); unset($_SERVER['PHP_AUTH_PW']);
Дайджест-аутентификация доступа — один из общепринятых методов, используемых веб-сервером для обработки учетных данных пользователя веб-браузера. Аналогичный метод используется в рамках VoIP-протокола SIP для аутентификации сервером обращения со стороны клиента, т.е. оконечного терминала. Данный метод отправляет по сети хеш-сумму логина, пароля, адреса сервера и случайных данных, и предоставляет больший уровень защиты, чем базовая аутентификация, при которой данные отправляются в открытом виде.
Технически, аутентификация по дайджесту представляет собой применение криптографической хеш-функции MD5 к секрету пользователя с использованием случайных значений для затруднения криптоанализа и предотвращения replay-атак. Работает на уровне протокола HTTP. Это более продвинутый вариант HTTP Аутентификации.
Можно использовать следующие опции:
domain
- домен, необязательный список URI (через пробел), которые защищены данным запросом на аутентификацию.algorithm
- указывает на алгоритм, используемый для создания дайджеста.opaque
- base64 или HEX строка которую генерирует сервер. Клиент должен вернуть opaque неизменённым.nonce
- Уникальное HEX число или base64 число, которое сервер генерирует вместе с каждый 401 запросом.Помогает серверу бороться с атаками повторного воспроизведения (replay attack)
nonce должен быть в одинарных кавычках (не в двойных)
nonce-count
- HEX число, содержащее количество запросов, которые клиент отправил с nonce в запросе.stale
- от английского stale - устаревший.Флаг, который показывает на то, что предыдущий запрос от клиента был отклонён из за того, что значение nonce было несвежим.
Сервер должен ставить флаг stale в TRUE (регистронечувствительный) если пароль и имя пользователя верные и только nonce устарел.
В этом случае клиент может попытаться отправить ещё один зашифрованный запрос не запрашивая у пользователя ввод пароля.
Если сервер отказал в соединении а stale поставлен в FALSE, либо любое значение кроме TRUE, либо вообще отсутствует, значит клиент должен запросить логин и пароль снова.
qop
- Quality of Protectioncnonce
- Уникальный id сгенерированный клиентом. Это число помогает клиенту и серверу подтвердить, что у них есть известный общий секрет. Необходимо когда сервер отправляет qop. Не должно посылаться если сервер не использовал qop директиву.Опция для HTTP Digest Authentication. Может принимать значения auth
или auth-int
. Влияет на то как создается хэш.
Если поставить в auth
будет использоваться только запрошенный URI. Если в auth-int
то также будет использовано тело запроса.
Клиент шлёт GET на сервер.
Сервер шлёт обратно HTTP 401 Unauthorized с набором (дайджестом) опций.
WWW-Authenticate: Digest realm="AndreiR",
qop="auth,auth-int",
nonce="abcdefg…",
opaque="abcd…",
Пользователь вводит свои учётные данные.
Генерируется Authorization Header:
HA1 = MD5 хэш из имени пользователя, пароля и строки realm.
HA2 = MD5 хэш из метода аутентификации и запрошенного URI
Response = MD5 хэш из HA1, HA2, nonce, nonce-count, cnonce и qop
Клиент отправляет новый запрос на основе сгенерированных данных
GET /
Authorization: Digest username="andrei", realm="AndreiR", uri="/"
qop=auth, nc=00000001,response="12345abc…"
nonce="abcdefg…",
opaque="abcd…",
Сервер проверяет пришедшие данные. Если всё верно возвращает HTTP 200 OK, если неверно HTTP 403 Forbidden Некоторые опции необязательны, поэтому гарантировать определённый уровень безопасности нельзя.
HTTP Digest Аутентификация уязвима для атак посредника (MITM) так как сервер не может проверить идентичность клиента. Невозможно использовать более сложные алгоритмы хэширования паролей, такие как bcrypt.