XHR shouldn't prompt for login/pwd when these are provided to open()




8 years ago
6 months ago


(Reporter: benjamin.jaton, Unassigned)


Other Branch

Firefox Tracking Flags

(Not tracked)




(1 attachment)

697 bytes, text/html


8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100723 Ubuntu/9.10 (karmic) Firefox/3.6.8
Build Identifier: 3.6.8

Using mootools to set the HTTP basic authentication header (mootools.core.js), I create a header like "Authorization: Basic YmphdG9uOnRlc3Qy"
But firefox still prompts for a login/password but it shouldn't :


"If authentication fails, Authorization is not in the list of author request headers, request username is non-null, and request password is non-null, user agents must not prompt the end user for their username and password. [RFC2617]"

Reproducible: Always

Steps to Reproduce:
1. setup a /protected url protected by HTTP basic auth
2. launch the script against it
Actual Results:  
Dialog box open for credentials

Expected Results:  
JS alert popup "FAILED"

see attached html test case.

Comment 1

8 years ago
Created attachment 485889 [details]
Is the test available live somewhere?

Note that all this code was revamped to follow the spec you cite (which postdates Firefox 3.6) for Firefox 4, so it's worth testing what the behavior there is.

Comment 3

8 years ago
Test is available there :

I have the same behavior under Firefox 4.0b6.
Indeed.  Thanks for the testcase!
Component: Networking → DOM: Other
Ever confirmed: true
QA Contact: networking → general
Jonas, can we just hand back an authprompt impl in this case that cancels the auth request from necko, perhaps?
Summary: [RFC2617] HTTP BASIC : shouldn't prompt for login/pwd when provided in headers → XHR shouldn't prompt for login/pwd when these are provided to open()
OS: Linux → All
Hardware: x86 → All
I don't know off the top of my head how necko handles authentication prompts, but that does sound like a possible strategy.

Would be even nicer if we can simply hand back null of course.
(In reply to Benjamin Jaton from comment #3)
> Test is available there :
> http://demo.moroblog.info/FF_RFC2617/

The test case is currently broken, as a 500 (Internal Server Error) HTTP status code is being returned by the server, which is obfuscating this issue.

@Benjamin: could you take a look? Thanks!

Bumped at this issue a few months ago and worked around using some sort of trick. Now revisiting in the light of Firefox 4+ changes (which, unfortunately, broke the existing workaround). The use case is an HTTP-based authentication application which, for logout, uses an XMLHttpRequest with invalid credentials which was supposed to clear existing credential cache. Due to this issue, the authentication prompt is always displayed (i.e., cannot be prevented through scripting), which is confusing for users - who will likely try to authenticate themselves again, instead of pressing "Cancel" to keep in the unprotected area.
Component: DOM: Other → DOM: Mozilla Extensions
Version: unspecified → Other Branch

Comment 8

7 years ago
Hi Helder, the test case should be fixed :)
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.