Http basic auth php
Аутентификация и авторизацияvна PHP
Предопределённые PHP переменные
Basic HTTP Authentication
Чтобы создать проверку пользователя во всплывающем окне достаточно следующего кода:
Тем не менее, желательно добавить немного функционала:
В Firefox это Library → History → Clear Recent History → Active Logins
В Chrome это Passwords and other sing-in data (в Clear browsing data → Advanced)
В Safari это Clear History
Если пароль поменялся, пользователя со старым паролем не выкинет и т.д.
Примечание о совместимости
Пожалуйста, будьте осторожны при кодировании строк заголовка HTTP.
Чтобы гарантировать максимальную совместимость со всеми клиентами, ключевое слово «Basic» должно быть написано с прописной буквой «B», строка realm должна быть заключена в двойные (а не одинарные) кавычки, и ровно один пробел должен предшествовать коду 401 в строке заголовка HTTP/1.0 401. Параметры аутентификации должны быть разделены запятыми, как показано в приведенном выше примере дайджеста.
Очистить глобальные переменные
HTTP Digest Authentication
Дайджест-аутентификация доступа — один из общепринятых методов, используемых веб-сервером для обработки учетных данных пользователя веб-браузера.
Аналогичный метод используется в рамках VoIP-протокола SIP для аутентификации сервером обращения со стороны клиента, т.е. оконечного терминала.
Данный метод отправляет по сети хеш-сумму логина, пароля, адреса сервера и случайных данных, и предоставляет больший уровень защиты, чем базовая аутентификация, при которой данные отправляются в открытом виде.
Технически, аутентификация по дайджесту представляет собой применение криптографической хеш-функции MD5 к секрету пользователя с использованием случайных значений для затруднения криптоанализа и предотвращения replay-атак. Работает на уровне протокола HTTP.
Это более продвинутый вариант HTTP Аутентификации.
Можно использовать следующие опции ( полный список в RFC )
Необязательный список URI (через пробел), которые защищены данным запросом на аутентификацию.
algorithm
Указывает на алгоритм, используемый для создания дайджеста.
opaque
base64 или HEX строка которую генерирует сервер. Клиент должен вернуть opaque неизменённым.
nonce должен быть в одинарных кавычках (не в двойных)
stale
Флаг, который показывает на то, что предыдущий запрос от клиента был отклонён из за того, что значение nonce было несвежим.
Сервер должен ставить флаг stale в TRUE (регистронечувствительный) если пароль и имя пользователя верные и только nonce устарел.
В этом случае клиент может попытаться отправить ещё один зашифрованный запрос не запрашивая у пользователя ввод пароля.
Если сервер отказал в соединении а stale поставлен в FALSE, либо любое значение кроме TRUE, либо вообще отсутствует, значит клиент должен запросить логин и пароль снова.
Опция для HTTP Digest Authentication. Может принимать значения «auth» или «auth-int». Влияет на то как создается хэш.
Если поставить в «auth» будет использоваться только запрошенный URI. Если в «auth-int» то также будет использовано тело запроса.
Обзор Digest Аутентификации
WWW-Authenticate: Digest realm=»AndreiR»,
qop=»auth,auth-int»,
nonce=»abcdefg…»,
opaque=»abcd…»,
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 Digest Аутентификация уязвима для атак посредника (MITM) так как сервер не может проверить идентичность клиента.
Невозможно использовать более сложные алгоритмы хэширования паролей, такие как bcrypt
HTTP-аутентификация в PHP
Замечание: Замечание касательно версии PHP
Пример фрагмента скрипта, который вынуждает клиента авторизоваться для просмотра страницы:
Пример #1 Пример Basic HTTP-аутентификации
Пример #2 Пример Digest HTTP-аутентификации
Это пример реализации простого скрипта Digest HTTP-аутентификации. За подробностями обращайтесь к » RFC 2617.
die( ‘Текст, отправляемый в том случае, если пользователь нажал кнопку Cancel’ );
>
Замечание: Замечание касательно совместимости
Будьте особенно внимательны при указании HTTP-заголовков. Для того, чтобы гарантировать максимальную совместимость с наибольшим количеством различных клиентов, слово «Basic» должно быть написано с большой буквы «B», регион (realm) должен быть взят в двойные (не одинарные!) кавычки, и ровно один пробел должен предшествовать коду 401 в заголовке HTTP/1.0 401. Параметры аутентификации должны разделяться запятыми, как это было показано в примере Digest аутентификации выше.
Вы можете пронаблюдать особенности работы браузера Internet Explorer. Он очень требователен к параметру передаваемых заголовков. Трюк с указанием заголовка WWW-Authenticate перед отправкой статуса HTTP/1.0 401 пока что работает для него.
Замечание: Замечание касательно конфигурации
PHP использует указание директивы AuthType для указания того, используется внешняя аутентификация или нет.
Следует заметить, что все вышесказанное не предотвращает похищения паролей к страницам, требующим авторизацию, кем-либо, кто контролирует страницы без авторизации, расположенные на том же сервере.
И Netscape Navigator и Internet Explorer очищают кэш аутентификации текущего окна для заданного региона (realm) при получении от сервера статуса 401. Это может использоваться для реализации принудительного выхода пользователя и повторного отображения диалогового окна для ввода имени пользователя и пароля. Некоторые разработчики используют это для ограничения авторизации по времени или для предоставления кнопки «Выход».
Пример #3 Пример HTTP-аутентификации с принудительным вводом новой пары логин/пароль
function authenticate () <
header ( ‘WWW-Authenticate: Basic realm=»Test Authentication System»‘ );
header ( ‘HTTP/1.0 401 Unauthorized’ );
echo «Вы должны ввести корректный логин и пароль для получения доступа к ресурсу \n» ;
exit;
>
Это поведение не регламентируется стандартами HTTP Basic-аутентификации, следовательно, вы не должны зависеть от этого. Тестирование браузера Lynx показало, что Lynx не очищает кэш авторизации при получении от сервера статуса 401, и, нажав последовательно «Back», а затем «Forward» возможно открыть такую страницу, при условии, что требуемые атрибуты авторизации не изменились. Однако, пользователь может нажать клавишу ‘_’ для очистки кеша аутентификации.
Для того, чтобы добиться корректной работы HTTP-аутентификации в IIS сервере с CGI версией PHP, вы должны отредактировать конфигурационную настройку IIS под названием «Directory Security«. Щелкните на надписи «Edit» и установите опцию «Anonymous Access«, все остальные поля должны остаться неотмеченными.
Замечание: Замечание касательно IIS:
Для того, чтобы HTTP-аутентификация корректно работала в IIS, в конфигурации PHP опция cgi.rfc2616_headers должна быть установлена значением 0 (значение по умолчанию).
В случае, если используется безопасный режим, UID текущего скрипта будет добавлен в realm-часть заголовка WWW-Authenticate.
PHP HTTP Basic Auth using Form
How can I use HTTP basic Authentication and have the user submit their Username and Password in a HTML form and have it Authenticate using HTTP Basic Authentication.
I heard that Internet Explorer no longer supports the use of http://user:password@website.com no more so I don’t know the best way to approach this.
Use of PHP and javascript and HTML is OK. I don’t want to use PERL and I perfer no big javascript libs.
If you don’t think HTTP Basic Auth. is the best way, please recommend something easy and simple to do. It will only be a login site for 5-6 people. No need to complicate it.
4 Answers 4
IMHO, the whole point of using HTTP authentication is being able to delegate authentication tasks:
So you have a working system with minimum effort.
Now, if you use an HTML form to ask for credentials, the server will know who you are but the browser won’t: it’ll ask for credentials as soon as it finds the WWW-Authenticate response header and the 401 status code. For this to work, the browser has to send an Authorization request header on every HTTP request; however, your form cannot instruct the browser to send the appropriate HTTP header.
Of course, you can write your own server-side authentication code in PHP, configure the server to parse static files through it and omit 401 and WWW-Authenticate as soon as you get valid credentials (which then need to be stored somewhere else, e.g., a PHP session). But then you’ve lost all the advantages of HTTP authentication: at this point, a custom login handler with PHP sessions will be a much easier solution.
Аутентификация и авторизацияvна PHP
Предопределённые PHP переменные
Basic HTTP Authentication
Чтобы создать проверку пользователя во всплывающем окне достаточно следующего кода:
Тем не менее, желательно добавить немного функционала:
В Firefox это Library → History → Clear Recent History → Active Logins
В Chrome это Passwords and other sing-in data (в Clear browsing data → Advanced)
В Safari это Clear History
Если пароль поменялся, пользователя со старым паролем не выкинет и т.д.
Примечание о совместимости
Пожалуйста, будьте осторожны при кодировании строк заголовка HTTP.
Чтобы гарантировать максимальную совместимость со всеми клиентами, ключевое слово «Basic» должно быть написано с прописной буквой «B», строка realm должна быть заключена в двойные (а не одинарные) кавычки, и ровно один пробел должен предшествовать коду 401 в строке заголовка HTTP/1.0 401. Параметры аутентификации должны быть разделены запятыми, как показано в приведенном выше примере дайджеста.
Очистить глобальные переменные
HTTP Digest Authentication
Дайджест-аутентификация доступа — один из общепринятых методов, используемых веб-сервером для обработки учетных данных пользователя веб-браузера.
Аналогичный метод используется в рамках VoIP-протокола SIP для аутентификации сервером обращения со стороны клиента, т.е. оконечного терминала.
Данный метод отправляет по сети хеш-сумму логина, пароля, адреса сервера и случайных данных, и предоставляет больший уровень защиты, чем базовая аутентификация, при которой данные отправляются в открытом виде.
Технически, аутентификация по дайджесту представляет собой применение криптографической хеш-функции MD5 к секрету пользователя с использованием случайных значений для затруднения криптоанализа и предотвращения replay-атак. Работает на уровне протокола HTTP.
Это более продвинутый вариант HTTP Аутентификации.
Можно использовать следующие опции ( полный список в RFC )
Необязательный список URI (через пробел), которые защищены данным запросом на аутентификацию.
algorithm
Указывает на алгоритм, используемый для создания дайджеста.
opaque
base64 или HEX строка которую генерирует сервер. Клиент должен вернуть opaque неизменённым.
nonce должен быть в одинарных кавычках (не в двойных)
stale
Флаг, который показывает на то, что предыдущий запрос от клиента был отклонён из за того, что значение nonce было несвежим.
Сервер должен ставить флаг stale в TRUE (регистронечувствительный) если пароль и имя пользователя верные и только nonce устарел.
В этом случае клиент может попытаться отправить ещё один зашифрованный запрос не запрашивая у пользователя ввод пароля.
Если сервер отказал в соединении а stale поставлен в FALSE, либо любое значение кроме TRUE, либо вообще отсутствует, значит клиент должен запросить логин и пароль снова.
Опция для HTTP Digest Authentication. Может принимать значения «auth» или «auth-int». Влияет на то как создается хэш.
Если поставить в «auth» будет использоваться только запрошенный URI. Если в «auth-int» то также будет использовано тело запроса.
Обзор Digest Аутентификации
WWW-Authenticate: Digest realm=»AndreiR»,
qop=»auth,auth-int»,
nonce=»abcdefg…»,
opaque=»abcd…»,
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 Digest Аутентификация уязвима для атак посредника (MITM) так как сервер не может проверить идентичность клиента.
Невозможно использовать более сложные алгоритмы хэширования паролей, такие как bcrypt
Релогин и HTTP Basic Auth
Вэб разработчикам давно известна проблема разлогина и перелогина на сайтах, защищённых HTTP Basic Authorization. И хотя существуют другие методы аутентификации, не страдающие от этой проблемы, до сих пор Basic Authorization зачастую является наиболее оптимальным выбором. В сети хватает материалов, описывающих различные общие и частные решения. Но все они, найденные мной, к сожалению, описывают только какие-то частичные решения, работающие в одном браузере и не работающие в другом. Под катом привожу обобщённый конечный результат своего исследования этой проблемы
Сразу оговорюсь, что я не фронтенд-разработчик, и во всё многообразие «брендов» и версий браузеров не углублялся. Только мейнстримовые с версиями, актуальными на момент написания статьи. Для большинства вэб-задач этого достаточно. Для тех же разработчиков, кому нужна поддержка всего «зоопарка» браузеров, статья может стать хорошей отправной точкой
Суть проблемы в том, что стандартом HTTP Basic Authorization не предусмотрена возможность разлогина. Вообще. При заходе на страницу, защищённую Basic Authorization, браузер сам выводит вам своё собственное окно с запросом на логин/пароль и при успешном логине сохраняет их где-то у себя в глубинных недрах. Затем все последующие запросы к другим защищённым страницам данного сайта автоматически использует эти значения в заголовке Authorization:
Authorization: Basic bm9uZTpub25l
где bm9uZTpub25l — это base64-кодированная связка логин/пароль none:none (у вас логин и пароль, возможно, будут другие)
Для того, чтобы перелогиниться, нужно всего лишь сбросить значения старых логина/пароля в тех самых глубинных недрах браузера и на их место записать новые. Вот тут нас и поджидает сюрприз. Поскольку никакой стандарт не регламентирует это действо, каждый браузер творит это по своему собственному разумению.
Хуже того, поскольку окно запроса логина/пароля является собственным окном браузера, реагирующее уже на одни только HTTP заголовки страницы, это окно всплывает до какой бы то ни было обработки тела страницы. То есть выполнить какой-нибудь javascript при получении ответа сервера со статусом 401 не получится. Перед пользователем снова и снова будет вылезать это окно с повторным запросом на логин/пароль.
На самом деле этот момент критичен, так как почти для всех браузеров единственным способом разлогиниться является отправка на сервер запроса с заведомо неправильными логином/паролем, получение ответа сервера со статусом 401 и последующий сброс браузером своего логин/парольного кэша. Но если при этом браузер не даёт вам обработать ответ 401 и продолжить процесс логина уже для нового пользователя, перехватывая управление ещё на этапе чтения HTTP заголовков и выкидывания вам в лицо ту самую форму авторизации, в которую что ни вводи, работать не будет, то это уже проблема. Причём не имеет значения, обычный ли это запрос по ссылке или XMLHttpRequest или fetch. Браузер всё равно перехватывает управление на этапе разбора заголовков.
Исходные данные:
Internet Explorer
В нашем продукте не требуется поддержка этого браузера, поэтому решение мною лично не тестировалось. Тем не менее, как утверждает гугл, решение для него есть, и оно, пожалуй, самое простое и элегантное из всех. Более того, я нигде не встречал информации, что это решение для браузеров от Microsoft утратило актуальность:
В IE существует метод ClearAuthenticationCache, который сбрасывает «те самые глубинные недра». Просто и элегантно. И никаких плясок со вспомогательной страницей 401. Работает ли данный метод в Edge, не знаю. Скорее всего да.
Конструкция document.execCommand возвращает true, если метод существует и «сработал». После чего window.location.assign(url) перенаправляет пользователя для ввода новых логина и пароля
Firefox (72.0.1)
В контексте нашей задачи это самый проблемный браузер. Для него полноценного решения не существует до сих пор. В баг-трекере команды его разработчиков вот уже лет 15-20 висит запрос на указанную проблему. Но «воз и ныне там». Максимум чего можно добиться — это кривой разлогин.
Вводные данные:
Firefox не сбрасывает парольный кэш после получения ответа 401 ни через XMLHttpRequest, ни через fetch запрос. Только через обычный запрос с указанием логина/пароля в самом URL. То есть что-то вроде
После чего пользователь получает форму ввода логина/пароля, в которую что ни вводи, она будет выскакивать вновь и вновь. Дело в том, что введённые значения не будут переопределять значения логина/пароля, заданные в URL-е. То есть вместо введённых значений на сервер всякий раз будет уходить связка none:none. И чтобы перелогиниться под другим именем, пользователь должен нажать отмену, перейти на стартовую страницу (http ://mysite.com/) и уже там ввести новые логин/пароль.
Криво? Но увы, другого решения нет
Google Chrome (79.0.3945.88)
Для Хрома замечательно работает метод fetch. А вот XMLHttpRequest не работает ((( Кэш не сбрасывается, и разлогина не происходит. Причём пробовал логин/пароль задавать и как параметрами к методу open, так и установкой заголовка.
Делаем fetch запрос на страницу 401 с заведомо неверными логином/паролем, получаем ответ 401 от сервера, браузер сбрасывает свой кэш.
ВАЖНО! Сервер НЕ должен возвращать заголовок WWW-Authenticate. Иначе браузер перехватит управление, и перенаправления со страницы 401 не произойдёт никогда. По общепринятому соглашению сервер не должен возвращать этот заголовок, если в запросе указано X-Requested-With: XMLHttpRequest. Поэтому в запрос добавлен заголовок X-Requested-With.
Safari (12)
Для Сафари ситуация в точности до наоборот: работает XMLHttpRequest, но не работает fetch
Действия те же, что и в Хроме, только через XMLHttpRequest
Должно работать для версий Сафари 6+. В более ранних версиях были свои баги. В частности, например, в версиях от 5.1 при каждом перенаправлении браузер принудительно перезапрашивал авторизацию, из-за чего авторизация с перенаправлением на конечную страницу не работала в принципе. А в версиях до 5.0 не работал разлогин.