Normally when a publicly-accessible directory requires basic HTTP authentication, the value of $_SERVER['HTTP_AUTHORIZATION']
and/or $_SERVER['REMOTE_USER']
(or $_SERVER['PHP_AUTH_USER']
, etc) will be set and accessible to PHP once a valid username/password combination have been provided to the server.
For example, if http://www.example.com/members
requires basic authentication, and a user successfully authenticates using the credentials myusername
and mypassword
by manually typing http://myusername:[email protected]/members
into their browser, the value of $_SERVER['HTTP_AUTHORIZATION']
would be something like:
Basic bXl1c2VybmFtZTpteXBhc3N3b3Jk
... and the value of $_SERVER['REMOTE_USER']
would simply be:
myusername
However if authentication is not required in the same directory, but the URL is still visited with the username/password inside of it, the values of the username/password don't seem to be set anywhere (running PHP 5.3.10 as CGI/FastCGI on Apache/2.2.22).
From within PHP (and/or .htaccess
if necessary), when no authentication is required, is there a way to retrieve the values of the username (and/or password) that have been provided by a visitor who manually added them to the URL?
TLDR; As far as I can see that information is never sent to server so I claim it's not possible.
The way http authentication works if you have it set is that server sends a request for user/pass if it's not already set, and browser then adds that information in encoded form to a Authorization
header and sends it to the server along with the request.
As specified in RFC 2617, describing Basic and Digest authentication mechanisms For basic authentication, server sends HTTP 401 Not Authorized
status and WWW-Authenticate
header fields to request this information. (RFC 2617, Access Authentication Framework)
With tests one can see that if authentication is never configured on the server to be required, server won't request authentication information from browser, and browser won't add user/pass information into the request. RFC does not mandate browser (user agent) to not pass that information, but says instead
A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request.
In practice, if you watch the sent headers you can see that if this information is requested by the server, it's sent in encoded form using Authorization
header like specified by the RFC. However, if you're not using any authentication the request you send just doesn't seem to contain that information in any form. I've confirmed this with IE, Firefox and Chrome browsers myself.
If you want to test this yourself for your setup, this can be done for example using netcat like this:
First, run netcat on your server:
nc -l 8888
Then issue a request from your browser to http://testvalue:testvalue@yourdomain:8888/
As a result, observe from netcat output all the information that get sent to server, something like this:
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
There is no information about user or password anywhere. I claim that unless the server requests it, it won't be there.
The addition of user and password in a url using http(s)://user:[email protected] has been disabled by at least Internet Explorer for several years now, as far as i know.
https://support.microsoft.com/en-us/kb/834489
So I am not sure if what you are trying to reach is even usefull. I think the browsers dont even pass that part of the url on anymore.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With