User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12 Opening a page protected by Basic authentication requires authorization for each XMLHttpRequest issued back to the server Reproducible: Always Steps to Reproduce: 1. Setup an application that requires Basic authentication. 2. Create a page in that application that makes Ajax calls back to the same application 3. Load the page. It will ask you to enter your credentials. Do not save them when the browser asks you to. Click "Never for that site". 4. Trigger the Ajax call (e.g. click a button which will make an Ajax call) Actual Results: The dialog to enter you credentials appear for each Ajax call. Expected Results: The dialog for authentication appears only for the first page load and the credentials are used for all further calls to the application until the browser is restarted. The problem happens only with Firefox4 (Minefield). Firefox 3.6 behaves as expected. All other browsers I tried also ask for the credentials just once (Google Chrome 8.x, Opera 10.60, IE8).
Do you have a public test URL ?
No, sorry. I'll create simple application and attach it here with instructions how to setup it. Unfortunately I have no access to public visible machine to setup it.
Created attachment 489794 [details] The application that makes Ajax calls Here is a demo application. The package contains: - ff4.json - the Ajax response - ff4.html - this is the application. It has a clickable span which makes Ajax call to ff4.json - .htaccess - Apache configuration file that allows only user 'martin' with password 'martin' to use the application. Edit it so it points to the actual location of .passwds file - .passwds - the file with the users 1) put these files in a folder served by Apache (Apache config should have : AllowOverride AuthConfig). 2) Make a request to http://<your-server>/.../ff4.html 3) It will require authentication. Enter 'martin/martin' as credentials. Note: do not save the credentials when the browser ask you. 4) Click on "Click me" 5) On FF4 (minefield) it will show again the authentication dialog. On FF3.6.x the credentials are re-used from the first page load. Let me know if you need more details.
I can confirm that this is happening for me as well using Firefox 4 Beta 7. We have an internal site that uses Basic HTTP Authentication on Apache. Lots of XMLHttpRequest stuff. For each request, it pops up a login dialog requesting for login information, even though the user is already logged in. Works fine in Firefox 3. In firebug, you can see the following (in red - failed): POST http://undefined:firstname.lastname@example.org/dir/xhr.php 401 Authorization Required This keeps happening for every subsequent request, even if you login properly multiple times.
Martin, thanks. It looks like you're using dojo, and there's a known incompatibility between dojo's xhrGet implementation and the current XHR2 spec draft (which we implement) that causes dojo to override the username/password we would otherwise use with "undefined" and "undefined". See bug 605296. Marat, I assume you're using dojo too?
Hey Boris! I'm on Mootools 1.3, but it's entirely possible that's the issue. I'll take a look at the XHR2 spec and the Mootools source code. If that's the issue I'll cobble together a fix, post it here, and forward it to the Mootools guys. Thanks!
I can confirm that for me this is an issue with Mootools. Thank you for directing me on the right path. I wrote a patch for Mootools, it can be found on this ticket: https://mootools.lighthouseapp.com/projects/2706/tickets/1086-mootools-13-requestjs-basic-http-authentication-firefox-4-beta-7 I'm sure the Mootools guys will fix this for the next release. Thank you!
Excellent, thanks. Note that we're working on getting the spec changed here to be compatible with the current mootools/dojo behavior; there's no _strong_ reason for it to say what it says, other than theoretical purity, and there's no way we can ship the current behavior in Fx4, clearly.
This should have been fixed long ago by the patch in bug 605296. Please reopen is this is still an issue.