Closed
Bug 155155
Opened 22 years ago
Closed 21 years ago
digest authentication fails when switching between POST&GET requests
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.4beta
People
(Reporter: imitko, Assigned: skasinathan)
References
Details
(Whiteboard: [digest-auth])
Attachments
(1 file)
1.14 KB,
patch
|
dougt
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
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•22 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•22 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•22 years ago
|
Whiteboard: [digest-auth]
Updated•22 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 3•22 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•22 years ago
|
||
*** Bug 165136 has been marked as a duplicate of this bug. ***
Comment 5•22 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•22 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•22 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•22 years ago
|
Target Milestone: --- → mozilla1.4alpha
Comment 8•21 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•21 years ago
|
||
-> suresh
Assignee: darin → suresh
Status: ASSIGNED → NEW
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Comment 10•21 years ago
|
||
this might be causing bug 198652
Assignee | ||
Comment 11•21 years ago
|
||
Attachment #119725 -
Flags: superreview?(darin)
Comment 12•21 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+
Attachment #119725 -
Flags: review?(dougt)
Comment 13•21 years ago
|
||
Comment on attachment 119725 [details] [diff] [review] patch what darin said.
Attachment #119725 -
Flags: review?(dougt) → review+
Assignee | ||
Comment 14•21 years ago
|
||
fixed in trunk.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•