If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

digest authentication fails when switching between POST&GET requests

RESOLVED FIXED in mozilla1.4beta

Status

()

Core
Networking: HTTP
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: Mitko Iliev, Assigned: Suresh)

Tracking

Trunk
mozilla1.4beta
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [digest-auth])

Attachments

(1 attachment)

1.14 KB, patch
dougt
: review+
Darin Fisher
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
Reproducable: Always
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

When a digest authentication performed , and sequential request HTTP method is
changed i.e. from GET to POST , the computed 'responce' value is based on method
where authentication is started instead of current HTTP method. 

for example 
1) GET /a HTTP/1.1 -> OK
2) GET /a HTTP/1.1 -> OK
3) POST /a HTTP/1.1 -> Bad 'responce' , calculated w/ method GET (instead of
POST) , server rejects the request, new chalange issued
4) POST /a HTTP/1.1 (with new chalange) -> OK
5) GET /a HTTP/1.1 -> Bad 'response' , calculated w/ method POST (instead of
GET) ....

Comment 1

15 years ago
I've also encountered this bug, in testing my own RFC 2617 digest implementation
for PHP. It's easily triggered in form situations - submitting a form via POST
which was retrieved with the GET method does it every time.

It's not much more than an annoyance right now, but there may be a danger of
people "working around" the behavior in a nonstandard way, only to break
authentication in other browsers.

Comment 2

15 years ago
I'm having the problem that _every_ POST request to a form that I previously
retrieved with a digest authenticated GET causes Mozilla to prompt for the
credentials again.

I first thought this might be an Apache problem because mod_auth_digest is
pretty new, so I submitted a bug report to their tracking system. It includes
the auth headers from the dialog, so maybe someone can make some sense of it:

http://bugs.apache.org/index.cgi/full/9977

I'm currently using Mozilla build 2002052918 and Apache 1.3.26.

Updated

15 years ago
Whiteboard: [digest-auth]

Updated

15 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 3

15 years ago
Every time I submit a form via POST in a digest auth protected directory, it
requires me to reauthorize. Attempting to remember username and password does
not help. I just wanted to note that it also affects the Mac platform in both OS
X and OS 9. Most annoying, particularly because digest auth is a relatively
secure way to password protect an internal user area (at least to the extent it
doesn't post the password in the clear).

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826
RedHat Apache 1.3.22/Darwin Apache 1.3.26

------------------------
.htaccess file contents:
AuthName "admin tools"
AuthType Digest
AuthDigestFile /home/admin/.htdigestauth
AuthGroupFile /dev/null

require valid-user
---------------------- 

Comment 4

15 years ago
*** Bug 165136 has been marked as a duplicate of this bug. ***

Comment 5

15 years ago
Publishing a page from composer also asks for credentials again.  Possibly the
same issue and calculating based on GET rather than PUT?

Comment 6

15 years ago
I was hit by this bug also with nightly build (id 2003011605)

This is definetly a bug in mozilla.

Mozilla does not use correct request method just like original bug submission
(over half a year old) says.

How can we get this fixed?

Comment 7

15 years ago
Using a nightly build from 2003-01-16 (for Linux) the following happens:

First request using POST-method is calculated correctly. Every other requests
are always calculated using GET-method regardless, which one is actually used to
make the request.

Mozilla 1.3b behaves exactly the same for me.

I made a testcase for this bug:
http://suihkari.baana.suomi.net/mozilladigesttest/

It tells what method was used and which one is correct etc.

I dig into this few days ago. I think problem happens something like this:
In mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp there's 
nsresult
nsHttpChannel::Init(nsIURI *uri, 
                    PRUint8 caps,
                    nsIProxyInfo *proxyInfo)
{
 ..
    // Set default request method 
    mRequestHead.SetMethod(nsHttp::Get);
 ..
    // check to see if authorization headers should be included
    AddAuthorizationHeaders();
    
    return NS_OK;
}

but I can't find where Authorization headers are updated if the method is
changed after that.

I think the first POST works because 401 is returned at the first request and
authorization headers are calculated using 'this' in GetCredentials() which then
has the correct request method set. After that, username and passwords get
filled out from AuthCache and are always calculated by using the default GET-method.

Updated

15 years ago
Target Milestone: --- → mozilla1.4alpha

Comment 8

15 years ago
I think I've seen a slightly different version of this, on 1.2.1 for both 
Windows and Mac OS X:

Suppose I create and send an HTML message that contains a form, 
which will do a POST to a PHP page.  When I submit the form from Mozilla 
Mail, my Apache logs show that the POST request is immediately 
followed by a GET request of the same page (which, of course, screws 
everything up).

Excuse my newbie status on Bugzilla; I think I'm doing this roughly right.  I 
can give you more details on this if you like.

Jim Miller

Comment 9

15 years ago
-> suresh
Assignee: darin → suresh
Status: ASSIGNED → NEW
Target Milestone: mozilla1.4alpha → mozilla1.4beta

Comment 10

15 years ago
this might be causing bug 198652
(Assignee)

Comment 11

15 years ago
Created attachment 119725 [details] [diff] [review]
patch
(Assignee)

Updated

15 years ago
Attachment #119725 - Flags: superreview?(darin)
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED

Comment 12

15 years ago
Comment on attachment 119725 [details] [diff] [review]
patch

seems right on to me.  thanks suresh!  sr=darin
Attachment #119725 - Flags: superreview?(darin) → superreview+
(Assignee)

Updated

15 years ago
Attachment #119725 - Flags: review?(dougt)

Comment 13

15 years ago
Comment on attachment 119725 [details] [diff] [review]
patch

what darin said.
Attachment #119725 - Flags: review?(dougt) → review+
(Assignee)

Comment 14

15 years ago
fixed in trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 203813
You need to log in before you can comment on or make changes to this bug.