Closed Bug 215479 Opened 21 years ago Closed 20 years ago

<form method=post> does not pass $_SERVER['PHP_AUTH_USER'] variable

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
FreeBSD
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: matt, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030801 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030801 Mozilla Firebird/0.6.1

While using <form method=post> on a page, after clicking the "submit" button,
the $_SERVER['PHP_AUTH_USER'] and $_SERVER['REMOTE_USER'] variables do not get
passed onto the next page.  In PHP, a var_dump() proves that the variables are
not being passed.  The variables are passed using IE and Konqueror (I believe
that in 0.6.0 they did work.)

Reproducible: Always

Steps to Reproduce:
1.  Create a PHP File with a form ... <form method=post> (register globals off)
2.  Click submit on the form
3.  The variables $_SERVER['PHP_AUTH_USER'] and $_SERVER['REMOTE_USER'] will not
be passed by firebird.

Actual Results:  
The variables are not accessible on the next page.

Expected Results:  
They should appear in the var_dump()
I confirm than i have the same problem on Windows 2000.
it's pretty ugly removing the dust from IE for this bug. I confirm, it happens
on my xp.
lately i'll try this on my slackware. 
regards
Does this also occur on Mozilla instead of Firebird?  If so this should go to
the correct Browser component.
QA Contact: asa → mpconnor
yes of course. it happens on them both
Might it be worth nabbing a copy of Mozilla and testing it?  If someone has a
mozilla build I can give them an example URL...
i'm sorry, i didn't understand what you told, what is 'nabbing'?
Sorry ...

I meant to say... would it be worth it to download and compile a build of
mozilla and test it? (I only have Firebird) ... or ... if someone has a copy of
mozilla already built on their machine, I can give them a test URL to see if
this bug affects mozilla too (although I would assume it would)...
ok thanks, I just wrote that it happens on them both. in any circustamces and
any OS 
thanks for the quick responses :)

moving to correct component and confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mpconnor → asa
.
Component: General → Form Submission
Product: Firebird → Browser
Version: unspecified → Trunk
it's a honor for me helping for this great purpose
What HTTP headers do these PHP variables correspond to?
Assignee: blake → form-submission
QA Contact: asa → ashishbhatt
should be these: header("WWW-Authenticate: Basic realm=\"My Realm\"");
This seems to be a well known issue.  Is there any fix?
I just received the following from a site I was trying to register on :
****************
"We detected an order that was received from a Gecko enabled browser. Gecko enabled browsers have a Mozilla bug in them that drops all form variables as they pass thru a secure server running formmail, a common form to email script used by most order forms.

Please resubmit your order using a standard MSIE web browser or we can phone you to reenter the information and complete the order process."

****************
It is true that I bumped into this bug through https...it may work for http too,
unsure.
Do we have a testcase?
Have there been anymore updates on the status of this bug?
Matt: There probably won't be any progress on this bug unless someone can create
a testcase.
Not a problem.  Do I just set one up on one of my servers and post the
information and a step by step to cause the problem?  Is that how that works?

-Matt
OK, here is a test case for both HTTP and HTTPS:

http://www.atopia.net/test/mozbug215479/step1.php

https://secure.webaries.com/atopia/test/mozbug215479/step1.php

http authentication is test/test

There is one difference since the original bug.  The $_SERVER['PHP_AUTH_USER']
variable seems to be being passed in both situations (http and https), but the
$_SERVER['REMOTE_USER'] variable is still not being passed in either case (http
or https).  However, if you access any page and continue to refresh it, or visit
the source code (just change the .php to .source) and then go back to the .php
file, the variable $_SERVER['REMOTE_USER'] is still set.  It only dissapears
once the form is posted.

Hope this helps,

Matt
that looks like a PHP bug, not a Mozilla bug. The variables you speak of are PHP
variables, on the HTTP side Mozilla only sends one header, so if you get the
information at all (as you do) then it means it is getting through.
Agreed.  I tested my test case in IE and it did not work.  I know though that
last September I tested it in IE and it did work, which is why I filed the PR. 
Possibly I'm not setting up the test case the same way, but I'm pretty sure I
am.       Problem seems resolved as far as mozilla is concerned, I will forward
this onto PHP...
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #23)
> Agreed.  I tested my test case in IE and it did not work.  I know though that
> last September I tested it in IE and it did work, which is why I filed the 
PR. 
> Possibly I'm not setting up the test case the same way, but I'm pretty sure I
> am.       Problem seems resolved as far as mozilla is concerned, I will 
forward
> this onto PHP...

I believe this may still be an issue on the FireFox side. I have been working 
on a Java program that can listen and accept connections via HTTPs. I have 
been testing it by using MSIE or FireFox with a local URL https://localhost. 
My Java app then returns what was sent from the browser. I have tested both 
GET and POST operations. In the POST method with MSIE I see all the passed 
variables in the header as expected but in FireFox I don't get any variables 
in the header. Per HTTP 1.1 the variable data should be included in the 
header ?!?!

*** Here is an example POST result to my Java app from MSIE:
POST /testme.asp HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, 
application/x-shockwave-flash, */*
Referer: https://localhost:7000
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: localhost:7000
Content-Length: 86
Connection: Keep-Alive
Cache-Control: no-cache

TESTINPUT=777777777777777777777777777777777777777777777777777&ANOTHER=What+is+g
oing+on 

*** Here is an example POST result to my Java app from FireFox (notice the 
lack of variable data at the end):

POST /testme.asp HTTP/1.1
Host: localhost:7000
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) 
Gecko/20040707 Firefox/0.8
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8
,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://localhost:7000/testme.asp

*** Where is the POST data ! ***

I upgraded to the latest FireFox 0.9x and still get the same result with 
FireFox.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.