php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20441 PHP_AUTH_USER isn't set
Submitted: 2002-11-15 02:58 UTC Modified: 2003-01-13 12:54 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:2 of 3 (66.7%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: gerwout at notenbomer dot nl Assigned:
Status: Closed Package: Apache related
PHP Version: 4.3.0 OS: all
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gerwout at notenbomer dot nl
New email:
PHP Version: OS:

 

 [2002-11-15 02:58 UTC] gerwout at notenbomer dot nl 
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register globals on in php.ini.

My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-ftp --with-openssl

The script is using this .htaccess-file

AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user

I am sure that Apache is setting the PHP_AUTH_USER because the following script gives the correct output:

// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
    if ($header == "Authorization")
    {	
   	$value = str_replace(" ", "", $value);
   	$value = str_replace("Basic", "", $value);
   	$userArray = explode(":", base64_decode($value));
    	$PHP_AUTH_USER = $userArray[0];
    }
}
echo $PHP_AUTH_USER;
// end dirty hack

If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script I am getting a empty result.

Note: the script was functioning 100% properly with php 4.2.3

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-15 03:10 UTC] rasmus@php.net 
You need to decide if you are using an external auth mechanism or http auth from php.  You can't do both.
 [2002-11-15 03:52 UTC] gerwout at notenbomer dot nl 
So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and $_SERVER["PHP_AUTH_USER"] when I header the authentication?

Why is this behaviour changed without notice?
 [2002-11-15 09:10 UTC] sniper@php.net 
It was fixed to be like it should be since PHP 3.
 [2002-11-22 02:40 UTC] angry at notbogus dot net 
This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that.
 [2002-12-11 10:39 UTC] croatia at firstlinux dot net 
I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke.
 [2002-12-11 10:53 UTC] philip@php.net 
Can someone explain this?  Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed?

It has been documented forever but this behavior changed so please explain it.
 [2002-12-11 10:58 UTC] derick@php.net 
We fixed a bug, period.

Derick
 [2002-12-18 13:29 UTC] phildriscoll@php.net 
This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least  PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out.

I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this.

I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour  is widely relied upon, and perhaps we should consider an php.ini switch.

The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour.
 [2002-12-18 15:21 UTC] sas@php.net 
This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions.
 [2002-12-21 15:16 UTC] philip@php.net 
It has been agreed in php-dev to keep the PHP_AUTH_* variables but to disable them when in safe mode.  This change was made after 4.3.0-RC4 but will exist in PHP 4.3.0.  This is from the PHP 4.3.0 NEWS:


Make PHP_AUTH_* variables not available in safe mode 
under Apache when an external basic auth mechanism is 
used. (Philip)

REMOTE_USER will exist regardless.  In the future, a new ini directive such as expose_php_auth_vars may be available.

The docs will be updated.
 [2003-01-13 11:33 UTC] mklerx at eid dot nl 
The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a <form action=XXX method="post">.
With method="get" it works OK.

I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method="get" option is a workaround, but this does not work in upload scripts, which has to use "post".

Is this a new bug?
 [2003-01-13 12:54 UTC] philip@php.net 
For the record, the last comment was found to be bogus in bug #21620.

And on a unrelated note, it's recommended to not rely on the register_globals directive so use $_SERVER['REMOTE_USER'] not $REMOTE_USER.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Nov 05 12:00:01 2025 UTC