Как извлечь попытку $ _SERVER [‘REMOTE_USER’] из URL, когда аутентификация не требуется

Обычно, когда общедоступный каталог требует базовой аутентификации HTTP, значение $_SERVER['HTTP_AUTHORIZATION'] и / или $_SERVER['REMOTE_USER'] (или же $_SERVER['PHP_AUTH_USER']и т. д.) будут установлены и доступны для PHP после того, как на сервере будет предоставлена ​​правильная комбинация имени пользователя и пароля.

Например, если http://www.example.com/members требует базовой аутентификации, и пользователь успешно аутентифицируется с использованием учетных данных myusername а также mypassword вручную набрав http://myusername:[email protected]/members в их браузере, значение $_SERVER['HTTP_AUTHORIZATION'] будет что-то вроде:

Basic bXl1c2VybmFtZTpteXBhc3N3b3Jk

… и значение $_SERVER['REMOTE_USER'] будет просто:

myusername

Однако, если аутентификация не требуется в том же каталоге, но URL-адрес все еще посещается с именем пользователя / паролем внутри него, значения имени пользователя / пароля, кажется, нигде не установлены (при запуске PHP 5.3.10 в качестве CGI / FastCGI на Apache / 2.2.22).

Изнутри PHP (и / или .htaccess если необходимо), когда аутентификация не требуется, Есть ли способ получить значения имени пользователя (и / или пароля), предоставленные посетителем, который вручную добавил их в URL?

11

Решение

TLDR; Насколько я вижу, информация никогда не отправляется на сервер, поэтому я утверждаю, что это невозможно.

HTTP-аутентификация работает, если она установлена, когда сервер отправляет запрос на пользователя / пароль, если он еще не установлен, а затем браузер добавляет эту информацию в зашифрованном виде в Authorization заголовок и отправляет его на сервер вместе с запросом.

Как указано в RFC 2617, описывающем механизмы базовой и дайджест-аутентификации. Для базовой аутентификации сервер отправляет HTTP 401 Not Authorized статус и WWW-Authenticate поля заголовка для запроса этой информации. (RFC 2617, структура аутентификации доступа)

С помощью тестов можно увидеть, что если на сервере никогда не требуется проверка подлинности, сервер не будет запрашивать информацию об аутентификации из браузера, а браузер не будет добавлять информацию о пользователе / ​​передавать в запрос. RFC не обязывает браузер (пользовательский агент) не передавать эту информацию, но вместо этого говорит

Пользовательский агент, который хочет аутентифицировать себя с источником
сервер — обычно, но не обязательно, после получения 401
(Несанкционировано) — МОЖЕТ сделать это, включив поле заголовка Авторизация
с просьбой.

На практике, если вы посмотрите отправленные заголовки, вы увидите, что если эта информация запрашивается сервером, она отправляется в закодированной форме с использованием Authorization заголовок, как указано в RFC. Однако, если вы не используете какую-либо аутентификацию, отправляемый вами запрос просто не содержит эту информацию в какой-либо форме. Я сам подтвердил это в браузерах IE, Firefox и Chrome.


Если вы хотите проверить это самостоятельно, это можно сделать, например, с помощью netcat:

Сначала запустите netcat на вашем сервере:

nc -l 8888

Затем отправьте запрос из вашего браузера на http://testvalue:testvalue@yourdomain:8888/

В результате наблюдаем из вывода netcat всю информацию, которая отправляется на сервер, примерно так:

GET / HTTP/1.1
Host: yourdomain:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

Нет информации о пользователе или пароле. Я утверждаю, что если сервер не запросит его, его там не будет.

9

Другие решения

Насколько мне известно, добавление имени пользователя и пароля в URL с использованием http (s): // user: [email protected] было отключено, по крайней мере, Internet Explorer уже несколько лет.

https://support.microsoft.com/en-us/kb/834489

Так что я не уверен, что то, что вы пытаетесь достичь, даже полезно. Я думаю, что браузеры даже не передают эту часть URL.

3

По вопросам рекламы [email protected]