Firefox 3 / XHR with authentication fails
;Op
I have a javascript script that does a XmlHTTPRequest GET to a
resource protected by a username/password (basic authentication
method, ie browser popup). I do no send any username and password in
my XHR, as I want the user to be poped-up and enter his login. The
server responds with a 401 status (Unauthorized), and this is the
response which is sent to my script, without any browser popup.
In all other browsers I tested (including previous Firefox versions),
the browser captures the 401, pop-up a username/password window, and
resends the request to the server, then returns to the script the
response to this 2nd request. This is the behavior when the GET is
trigerred by a click on a HTML link, and browsers should implement
this same behavior for XHR. FF3 does not.
This problem is demonstrated with the following page:
http://cigale.test.free.fr/tauth/
Does anyone know if this a known bug of FF3, and if it will be fixed
in future releases ?
rvandam
I'm running into the same problem with an extension. I initially
thought it had to do with the new mozBackgroundRequest (http://
starkravingfinkle.org/blog/2008/03/extension-developers-better-
background-xmlhttprequests/ and http://developer.mozilla.org/en/docs/XMLHttpRequest#mozBackgroundRequest)
boolean but setting that to false doesn't do anything. I can't find
anything that even indicates this is a new problem in Firefox 3.
Jonas Sicking
> thought it had to do with the new mozBackgroundRequest (http://
> starkravingfinkle.org/blog/2008/03/extension-developers-better-
> background-xmlhttprequests/ and http://developer.mozilla.org/en/docs/XMLHttpRequest#mozBackgroundRequest)
> boolean but setting that to false doesn't do anything. I can't find
> anything that even indicates this is a new problem in Firefox 3.
We had a bug where the auth dialog wouldn't be shown for XHR requests
done from extensions (or other chrome code). This has been fixed in the
recent nightlies, not sure if it was fixed in beta 5 or not.
However this does not affect web pages, so it's likely different from
the original post in this thread.
/ Jonas
Jonas Sicking
This is working fine for me in beta 5. Have you tested if it's fixed
there for you?
/ Jonas
Rob
I'm running the 3.0b5 distributed with Ubuntu Hardy Heron and it is
currently not working. Perhaps Ubuntu hasn't passed along the fix?
Sergei Zhirikov
> > > the browser captures the 401, pop-up a username/password window, and
> > > resends the request to the server, then returns to the script the
> > > response to this 2nd request. This is the behavior when the GET is
> > > trigerred by a click on a HTML link, and browsers should implement
> > > this same behavior for XHR. FF3 does not.
> >
> > > This problem is demonstrated with the following page:
> > > http://cigale.test.free.fr/tauth/
> >
> > > Does anyone know if this a known bug of FF3, and if it will be fixed
> > > in future releases ?
> >
> > This is working fine for me in beta 5. Have you tested if it's fixed
> > there for you?
> >
> > / Jonas
>
> I'm running the 3.0b5 distributed with Ubuntu Hardy Heron and it is
> currently not working. Perhaps Ubuntu hasn't passed along the fix?
Are you saying there may be different "versions" of 3.0b5 out there?
I'm running 3.0b5 Win32 binary downloaded from mozilla.com
and there it doesn't work either.
Rob
Well, Sicking says it works for him in 3.0b5 but Ubuntu's version does
not work for me.
However, I just tested a nightly (non-ubunutu) build and that worked
without a single modification.
So at the moment I'm inclined to point the finger at ubuntu. I've
filed a bug and we'll see what someone who isn't just speculating has
to say about it.
Jonas Sicking
There should not be different versions of beta 5 out there. There are
such things as platform specific bugs, but I doubt that's what's
happening here.
Please file a bug if this still isn't working for you in recent
nightlies on any platform.
/ Jonas
Rob
Hmm, after a little more testing I realized there's more to this than
I initially realized. It looks like the problem I'm seeing in
Ubuntu's 3.0b5 may ALSO be due to rejecting a self-signed SSL
certificate without asking the user.
I decided to try to test all of the possible combinations. Where
indicated I used basic http authentication (via a .htaccess file).
"ss ssl" is shorthand for self-signed certificate while "full ssl" is
a regular, signed certificiate.
no auth, no ssl - YES
no auth, ss ssl - NO (unless a security exception already exists for
this certificate)
no auth, full ssl - YES
auth, no ssl - NO*
auth, ss ssl - NO* (even if a security exception already exists for
this certificate)
auth, full ssl - NO*
* if I visit the requested site in the browser (which then asks me to
authenticate and possibly create a security exception) and then open a
new window (which creates a new instance of my particular extension),
my extension starts working normally (since the basic http
authentication stays valid for all new windows under the same profile)
This is all in Ubuntu's version of 3.0b5 because the official nightly
build works "out of the box" in all six cases.
Jonas Sicking
Hmm.. I'm a bit confused. You are always making requests to the same
"origin" right? I.e. to the same domain, protocol and port. So you are
always hosting the HTML page making the request on the same origin as
the file you are trying to load, which means that you have already
loaded the HTML page using the same ss/full certificate, right?
So at the point when the XHR request is made you must have already added
the exception for the ss certificate?
/ Jonas
Rob
I set up files in several locations on different servers so that I
could test each one independently (close and restarting the browser
for each test). My * note was just to indicate that I can load a page
in the browser as a workaround to get the XHR to work. Since the
workaround does NOT work in the second case (no auth, self-signed
cert), that was what clued me into the secondary problem of the self-
signed cert causing the XHR to fail, even once I've used the browser
to authenticate outside of the chrome context.
Jonas Sicking
>>> no auth, no ssl - YES
>>> no auth, ss ssl - NO (unless a security exception already exists for
>>> this certificate)
>>> no auth, full ssl - YES
>>> auth, no ssl - NO*
>>> auth, ss ssl - NO* (even if a security exception already exists for
>>> this certificate)
>>> auth, full ssl - NO*
>>> * if I visit the requested site in the browser (which then asks me to
>>> authenticate and possibly create a security exception) and then open a
>>> new window (which creates a new instance of my particular extension),
>>> my extension starts working normally (since the basic http
>>> authentication stays valid for all new windows under the same profile)
>> Hmm.. I'm a bit confused. You are always making requests to the same
>> "origin" right? I.e. to the same domain, protocol and port. So you are
>> always hosting the HTML page making the request on the same origin as
>> the file you are trying to load, which means that you have already
>> loaded the HTML page using the same ss/full certificate, right?
>>
>> So at the point when the XHR request is made you must have already added
>> the exception for the ss certificate?
>
> I set up files in several locations on different servers so that I
> could test each one independently (close and restarting the browser
> for each test). My * note was just to indicate that I can load a page
> in the browser as a workaround to get the XHR to work. Since the
> workaround does NOT work in the second case (no auth, self-signed
> cert), that was what clued me into the secondary problem of the self-
> signed cert causing the XHR to fail, even once I've used the browser
> to authenticate outside of the chrome context.
You're saying
no auth, ss ssl - NO (unless a security exception already exists for
this certificate)
But how can you even test this without adding an exception for the
certificate? You would have to load the HTML page first, which you can't
do without adding an exception for the certificate, no?
/ Jonas