All users were logged out of Bugzilla on October 13th, 2018

Basic HTTP AUTH using WWW-authenticate and 401 Unauthorized b0rked (ignores Realm, sends stale data)

RESOLVED FIXED in Firefox 47

Status

()

P5
normal
RESOLVED FIXED
17 years ago
2 years ago

People

(Reporter: ccurtis0, Assigned: andreaio.it)

Tracking

({helpwanted})

Trunk
mozilla47
x86
Linux
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox47 fixed)

Details

(Whiteboard: [necko-active])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
I've been working on a site that authenticates using Basic HTTP Auth.  It assigns a realm based on the current time, and sets the time in a cookie.  
At logout, the cookie is removed and a new realm is generated.  This works correctly with Konqueror, but Mozilla continues to send old data.

Here is the code in PHP (edited slightly):

----------------------------------------------------
$c = $HTTP_COOKIE_VARS["realm"];
fwrite( $fp, "Cookie: $c, User: $PHP_AUTH_USER, Pass: $PHP_AUTH_PW\n" );

// We must first declare what our realm should be
if( !($realm = $HTTP_COOKIE_VARS["realm"] ))
{	$realm = "License Admin - " . time();
	$HTTP_COOKIE_VARS["realm"] = $realm;
	Header( "WWW-authenticate: basic realm=\"$realm\"" ); 
	Header( "HTTP/1.0 401 Unauthorized" ); 
	SetCookie( "realm", $HTTP_COOKIE_VARS["realm"], time() + 3600 );

	// delete any stale info from the old realm
	$PHP_AUTH_USER = null;
}

// If we have not authenticated, ask for it
if( !$PHP_AUTH_USER )
{	Header( "WWW-authenticate: basic realm=\"$realm\"" ); 
	Header( "HTTP/1.0 401 Unauthorized" ); 
	echo "Text to see if user hits 'Cancel'"; 
	exit; 
} 

// Verify the password for the user
if( "passwd" != $PHP_AUTH_PW )
{	Header( "HTTP/1.0 401 Unauthorized" );
	Header( "WWW-authenticate: basic realm=\"$realm\"" ); 
	echo "Text to see if the password is incorrect<br>"; 
	exit;
}

// Auto-logout: 1 hour
SetCookie( "realm", $HTTP_COOKIE_VARS["realm"], time() + 3600 );
----------------------------------------------------

And here is the trace (mozilla 0.9.9; 20020411)

----------------------------------------------------
Cookie: , User: admin, Pass: passwd
Creating new realm: License Admin - 1019008891
Asking for a username/password
Cookie: License Admin - 1019008891, User: admin, Pass: passwd
Cookie: , User: admin, Pass: passwd
Creating new realm: License Admin - 1019008912
Asking for a username/password
Cookie: License Admin - 1019008912, User: sales, Pass: passwd
Cookie: License Admin - 1019008912, User: admin, Pass: passwd
----------------------------------------------------

What seems to happen is this:

I log in as "Admin".
I do whatever.
I select "Log out".
I try to log in again.
I am prompted for a username and password.
I log in as "Sales"
The next Authentication data is old ("Admin").

I was just changing the realm to force a logout, but Mozilla completely ignored this, which I why I made it more elaborate.  I'm not sure if the 
less elaborate way would have worked or not, because I assume that Mozilla would do the right thing.  After trying to debug my code and then 
creating the trace file, I decided to try Konqueror, which behaves as I would expect.  This leads me to believe that Mozilla is misbehaving.

I see no bug of this sort with bug 61681 - perhaps it should be added there too

Chris

Comment 1

17 years ago
there is no standard to indicate that a user-agent should delete all auth tokens
for a particular realm when an URL under that realm is newly challenged.

is it possible for you to provide a live testcase on the internet so that i can
be sure that i understand correctly the problem you are describing?
Severity: normal → minor
(Reporter)

Comment 2

17 years ago
Unfortunately, the code is firewalled ... however, let me try to clear up a
little confusion:

The same URL under the same realm should give the same credentials.  Both IE and
NS4 delete these when the realm changes (according to my web research).  Then
supplying the original realm, the browers re-prompt for authorization.

However, here is what is happening here (activity interspersed):

Legend:
 [A]ction (taken by user)
 [L]ogs (recorded to file)
 [P]rogram logic
 [B]rowser responds

A: Visit URL
L: Cookie: , user=,pass=
P: No cookie, create "time realm"
L: Creating new realm
L: Prompt for Username/Password
P: Send "WWW-Authenticate" and "401 Unauthorized"
P: Set cookie with realm name in $realm (foo111)
B: Ask for Username and Password (1)
...
A: Enter Username and Password (credentials1)
B: Submit (credentials1) and session cookie
L: Realm = foo111, user=user1, pass=pass1
P: Allow access ... issue redirect (display page)
...
A: Logout
B: Submit (credentials1) and session cookie
L: Realm = foo111, user=user1, pass=pass1
P: remove cookie
...
A: Login again
L: Cookie: , user=user1,pass=pass1
P: No cookie, create "time realm 2"
L: Creating new realm
L: Prompt for Username/Password
P: Send "WWW-Authenticate" and "401 Unauthorized"
P: Set cookie with realm name in $realm (FOO222)
B: Ask for Username and Password
...
A: Enter Username and Password (Credentials_2)
B: Submit (Credentials_2) and session cookie
L: Realm = FOO222, user=User2, pass=Pass2
P: Allow access ... issue redirect
...
B: Load new page (based on redirect)
 ***
B: Submit (credentials1) and session cookie
L: Realm = FOO222, user=user1, pass=pass1
 ***

Notes (1):
  I don't know the spec, but "License Administration - <unixtime>" appears to
overflow a boundary (of about 30 characters) for the realm name.  This was the
first thing that I noted was broken with Mozilla.  It seems that this buffer
length should be expanded.

The credentials being passed are obviously wrong.  Whether you chose to delete
them at a realm change (as is the behavior of NS4, IE, etc) or not (like no
other) doesn't really change that there were new credentials submitted for a new
realm, and then not retained.  Not only were the old ones not deleted, they were
submitted for the wrong realm and in the stead of new ones!

My $0.02 is that this isn't really "minor", and apologies about the previous
word wrapping - Konqueror did it...

Comment 3

17 years ago
ah.. thanks for clarifying the bug.  i'll investigate this for mozilla 1.0.1.
Severity: minor → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1

Comment 4

17 years ago
I have a related problem when using lovely lovely MS Exchange server.  Again we
have both HTTP Basic auth and a session cookie.

Process is as follows:

Go to log in page, enter username (say, UserA), and the browser submits the form
sending:

==> GET /exchange/LogonFrm.asp?isnewwindow=0&mailbox=UserA HTTP/1.1

<== HTTP/1.1 401 Unauthorized
<== WWW-Authenticate: Basic realm="servername"

User is prompted for Basic auth details, browser retries and everything is fine.

User logs out and tries to re-login as UserB - different query string - sending
the auth and cookie data from the previous session.

==> GET /exchange/LogonFrm.asp?isnewwindow=0&mailbox=UserB HTTP/1.1
==> Authorization: Basic UserACypherText
==> Cookie: ASPSESSIONOLD=USELESSOLDDATA

<== HTTP/1.1 401 Unauthorized

<== WWW-Authenticate: Basic realm="servername"


At this point the browser should prompt the user to enter (or select) a new set
of authentication credentials.  Instead it repeats its previous request, which
puts Exchange in a huff and 302s you to an error page.

I've come back to Mozilla (presently testing with 2002042221 on RedHat 7.2)
after a spell with NS6.2 because 6.2.2 is unstable on my system.  I'm therefore
not sure when this problem was introduced.  Sorry.

Updated

17 years ago
Target Milestone: mozilla1.0.1 → ---

Comment 5

17 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future

Comment 6

17 years ago
related to bug 140645 ??

Updated

16 years ago
Blocks: 143575

Updated

16 years ago
Blocks: 201620

Comment 7

16 years ago
has anyone given mozilla 1.4 beta a try?  many things have improved in the HTTP
auth implementation, so perhaps this bug has been fixed?  can someone please
test? thx!!

Comment 8

15 years ago
using firefox 0.9, http basic auth still doesn't work.

I navigate to my web app, the auth dialog come up, enter a bad user/password on
purpose, close the browser.
go to my web app again, anf the auth dialog don't show up, firefox insist in
using the cached user/password, then you are lost.

this is preventing the use of firefox/mozilla in my organization, we must use IE.

Comment 9

15 years ago
Hi Sergio, does the same problem happen if you try Mozilla-1.7rc3?
Priority: P3 → --
Target Milestone: Future → ---

Comment 10

15 years ago
hi darin, ok downloaded mozilla 1.7rc3 and no, mozilla is not sending cached
data after closing the browser.
I close the browser, open again and mozilla pop-up the passwd dialog again.

(I still prefer the IE behavior that do not need to close the browser if I
failed the login, ie: the httpd send the 401 code and www-authenticate code
again and IE pop-up the dialog again, but mozilla 1.7rc3 is a step ahead)

thanks!

Comment 11

15 years ago
> (I still prefer the IE behavior that do not need to close the browser if I
> failed the login, ie: the httpd send the 401 code and www-authenticate code
> again and IE pop-up the dialog again, but mozilla 1.7rc3 is a step ahead)

Are you sure Mozilla does not do this?  Can you provide a simple testcase or at
least provide a HTTP log file generated using instructions here:

  http://www.mozilla.org/projects/netlib/http/http-debugging.html

The log file should not include any passwords or usernames or even any base64
encoded usernames and passwords.  We try to keep the log file clean of that
stuff so folks like yourself will not feel hesistant to upload a log file. 
There's much I can learn about Mozilla's behavior from reading the log file.

Thanks!

Comment 12

15 years ago
yup, pretty sure...
test case: http://www.kessler.com.ar/http_basic_auth/

Comment 13

15 years ago
hmmm, after a while mozilla also start to send cached data...  :/

two different examples:

http://www.kessler.com.ar/http_basic_auth/index.php
http://www.kessler.com.ar/http_basic_auth/index2.php

use username 'foobar' on the second example and see the difference with IE.

Comment 14

15 years ago
thanks for the testcases... i hope to have time to investigate and fix this for
1.8a2.
Target Milestone: --- → mozilla1.8alpha2
(Reporter)

Comment 15

15 years ago
This bug still exists in my local Mozilla (Debian 1.6-5).  I think what Sergio
is describing is a different bug.  I've reduced the test case to something more
useful, but I still don't have a place to post it.

Here is the PHP code:

----- 8< ----- 8< -----
<?php
$realm = $HTTP_COOKIE_VARS["realm"];

if( $_GET["logout"] == $realm || !$PHP_AUTH_USER )
{       Header( "HTTP/1.0 401 Unauthorized" );
        $realm = "License Admin - " . time();
        $HTTP_COOKIE_VARS["realm"] = $realm;
        SetCookie( "realm", $realm, time() + 3600 );
        Header( "WWW-authenticate: Basic realm=\"$realm\"" );
}

?>

<p>Welcome to realm <b><?= $realm ?></b>, <?= $PHP_AUTH_USER ?></p>
<a href="?logout=<?= $realm ?>">Retry</a>
----- 8< ----- 8< -----

Here is the scenario:

Load the given page, enter 'user1' as the username.  Output:

Welcome to realm License Admin - 1087577080, user1

Click the 'Retry' link, enter 'user2' as the username.  Output:

Welcome to realm License Admin - 1087577301, user2

Click 'Reload' on your browser.  Output:

Welcome to realm License Admin - 1087577301, user1

I hope this makes this original bug clearer.  user2 just logged in, but the
authentication token is now for user1.  I find it surprising this hasn't caused
numerous problems at public terminals, though maybe they all just run IE for
reasons like this.  This seemed a pretty important bug when I submitted it over
2 years ago, but I could be the only person in the world doing stupid things
with basic authentication.

Comment 16

15 years ago
created
http://www.kessler.com.ar/http_basic_auth/index3.php
with the code posted from Christopher...

and yes, my bug is better described at
http://bugzilla.mozilla.org/show_bug.cgi?id=201620
(which seems resolved in mozilla but not firefox)
(Reporter)

Comment 17

15 years ago
Hi Sergio,

Thanks for posting that code.  Unfortunately, PHP doesn't seem to be installed
on that server, so it just shows up as plain text.  :(

Comment 18

15 years ago
oops, sorry...
can you try again ?
(Reporter)

Comment 19

15 years ago
Looks like I posted broken code.  Will try to fix, may take a couple weeks.  :(

Updated

15 years ago
Target Milestone: mozilla1.8alpha2 → mozilla1.8beta

Comment 20

14 years ago
I'd love it if Mozilla sent the Basic Auth header when given in the URL
_without_ round tripping to the server first.  The initial request should have
the basic authorization, also, the password should be opttional (assumed to be
the empty string).  

I use 2-3 differnet authentication mechanisms.  If the user uses username@server,
I use digest over https, otherwise I use a completely different mechanism.  This
would give me a nice way to 'check' if regular http authentication shoudl be
used.  When my server gets a 'basic' authorization, it would then respond with
the digest message; lacking the basic authorizaiotn, it'd redirect to our
central-login-pain-in-the-**** thingy.

Comment 21

14 years ago
I don't expect to have time to get to this for Gecko 1.8 (Firefox 1.1).  Help
wanted.
Keywords: helpwanted
Priority: -- → P5
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2

Updated

13 years ago
Target Milestone: mozilla1.8beta2 → mozilla1.9alpha

Comment 22

13 years ago
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: tever → networking
Target Milestone: mozilla1.9alpha → ---
(Reporter)

Comment 23

5 years ago
Created attachment 8428336 [details]
Test code (in PHP)

PHP has changed a bit in the past 12 years, updated example code to reflect these changes. Problem persists into FireFox 29.
(Reporter)

Updated

5 years ago
Summary: Basic HTTP AUTH b0rked (ignores Realm, sends stale data) → Basic HTTP AUTH using WWW-authenticate and 401 Unauthorized b0rked (ignores Realm, sends stale data)
(Assignee)

Updated

4 years ago
Assignee: nobody → andreaio.it
(Assignee)

Comment 24

4 years ago
Created attachment 8475262 [details] [diff] [review]
Bug 137852 - The identity is now inserted at the beginning of the list and not appended so the last change is the first of the list
Attachment #8475262 - Flags: review?(michal.novotny)

Comment 25

4 years ago
Still persists in 31.0.
(Assignee)

Updated

4 years ago
Attachment #8475262 - Flags: review?(michal.novotny) → review?(jduell.mcbugs)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 515651
Comment on attachment 8475262 [details] [diff] [review]
Bug 137852 - The identity is now inserted at the beginning of the list and not appended so the last change is the first of the list

Review of attachment 8475262 [details] [diff] [review]:
-----------------------------------------------------------------

Honza do you know this code?  It's a one-line patch.
Attachment #8475262 - Flags: review?(jduell.mcbugs) → review?(honzab.moz)
Andrea, can you please provide few words on why you've decided that this is the fix?  Is there a test?  Automated, or at least for now a public test case?  We cannot take just a line of change without any words of explanation, test, or at least a comment in the patch.

Thanks!
Flags: needinfo?(andreaio.it)
Comment on attachment 8475262 [details] [diff] [review]
Bug 137852 - The identity is now inserted at the beginning of the list and not appended so the last change is the first of the list

Dropping r? until more info on the patch provided.
Attachment #8475262 - Flags: review?(honzab.moz)
(Assignee)

Comment 30

4 years ago
I changed the line of code that adds the entry to the list of valid entries (mlist). When the user refreshes the page all the entries from the list are tried (starting from the first) and the first correct is used. The old code appended the new right entry and so the old one was tried first. You can test this using the code in the attachment 8428336 [details] (http://bookmod.altervista.org/firefox/bug137852.php).
Flags: needinfo?(andreaio.it)
comment 30
Flags: needinfo?(honzab.moz)

Comment 32

3 years ago
This problem seems to be worse if the two realms are parent and child. In fact, since I changed my website so the two folders with the two different realms were siblings it hasn't occurred to me again...

FWIW, it always worked OK with IE, not that that's a solution I would recommend of course :-)
So, first I'm really sorry this has been lost from my radar!  I was somehow hoping you will ask for r again on the patch after the info is provided.

I think the fix makes sense.  Something in my guts tells me tho there could be some security problem, but I cannot identify it.  Maybe it's just me being too cautious.

I'll update/submit/check in the patch.
Flags: needinfo?(honzab.moz)
Created attachment 8710607 [details] [diff] [review]
[by Andrea Bartolucci] v1.1

I've added a comment why we do this.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=66791aad5ff7
Attachment #8475262 - Attachment is obsolete: true
Attachment #8710607 - Flags: review+
Status: NEW → ASSIGNED
Whiteboard: [necko-active]
Duplicate of this bug: 319812
Keywords: checkin-needed

Comment 37

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6801dfbc6119
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Duplicate of this bug: 201620

Updated

2 years ago
Duplicate of this bug: 1259411
You need to log in before you can comment on or make changes to this bug.