Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was archived. Please ask a new question if you need help.

XMLHttpRequest caches credentials incorrectly.

  • No replies
  • 16 have this problem
  • 7 views
David Russo
David Russo
more options

I've found what I believe to be a bug in FireFox 4 on Windows. I've not tested on any other operating systems.

I have developed a Web application that uses HTTP Basic authentication. To allow for a customizable log on screen, I'm using XMLHttpRequest to send log on credentials to the server from an HTML form.

Briefly, it works like this:

1. My JavaScript function is called "onsubmit" of a form. The function returns false to cancel the actual form submit.

2. The JavaScript function collects the user/password entered on the form and passes them on the open() method of XMLHttpRequest.

3. On successful response from the server (200 OK), the script redirects into the application, as you are now logged on and FireFox caches the credentials to the HTTP Basic realm used by the application.

4. On unsuccessful response from the server (403 Not Authorized, in my case), a message is displayed on the page to indicate invalid user/password.

This code relies on a server-side CGI script to intelligently send the 401 response and WWW-Authenticate header as needed. Briefly, it works like this:

1. Apache is configured to NOT require authentication for this script, although all other URLs in the application are configured for HTTP Basic authentication.

2. The CGI script looks at the "Authorization" header.

3. If the "Authorization" header is not present, the CGI script sends the "WWW-Authenticate" header and the "401 Authorization Required" status.

4. If the "Authorization" header is present, the CGI script decodes the user/password from it and validates them. If valid, a 200 OK is sent. If not valid, a 403 Not Authorized is sent.

This is a common technique for using both HTTP Basic authentication and a custom log on form. The technique is very similar to that described in technical detail here:

http://www.peej.co.uk/articles/http-auth-with-html-forms.html

It works beautifully to allow the JavaScript to handle the invalid user/password without FireFox popping up its own log on box.

The trouble (and where I think I've found a bug) is this:

Once FireFox 4 has sent credentials and gotten either the 200 or 403 response, it caches those credentials permanently in the FireFox session!

For example:

1. The user comes to the log on form and enters the credentials incorrectly the first time.

2. The user then corrects the credentials and submits again.

3. FireFox 4 sends the Authorization header with the bad credentials from step 1! Even though the XMLHttpRequest.open() call specifies different credentials.

I'm very sure this is a bug because:

1. In FireFox 3 this does not happen. FireFox 3 sends the actual credentials that are passed to XMLHttpRequest.open() every time.

2. FireFox 4's own log on box does not suffer from this problem. It should be no different with XMLHttpRequest.

3. No other browser suffers from this problem.

If this actually appears to be a bug, how to I go about submitting a bug report?

I've found what I believe to be a bug in FireFox 4 on Windows. I've not tested on any other operating systems. I have developed a Web application that uses HTTP Basic authentication. To allow for a customizable log on screen, I'm using XMLHttpRequest to send log on credentials to the server from an HTML form. Briefly, it works like this: 1. My JavaScript function is called "onsubmit" of a form. The function returns false to cancel the actual form submit. 2. The JavaScript function collects the user/password entered on the form and passes them on the open() method of XMLHttpRequest. 3. On successful response from the server (200 OK), the script redirects into the application, as you are now logged on and FireFox caches the credentials to the HTTP Basic realm used by the application. 4. On unsuccessful response from the server (403 Not Authorized, in my case), a message is displayed on the page to indicate invalid user/password. This code relies on a server-side CGI script to intelligently send the 401 response and WWW-Authenticate header as needed. Briefly, it works like this: 1. Apache is configured to NOT require authentication for this script, although all other URLs in the application are configured for HTTP Basic authentication. 2. The CGI script looks at the "Authorization" header. 3. If the "Authorization" header is not present, the CGI script sends the "WWW-Authenticate" header and the "401 Authorization Required" status. 4. If the "Authorization" header is present, the CGI script decodes the user/password from it and validates them. If valid, a 200 OK is sent. If not valid, a 403 Not Authorized is sent. This is a common technique for using both HTTP Basic authentication and a custom log on form. The technique is very similar to that described in technical detail here: http://www.peej.co.uk/articles/http-auth-with-html-forms.html It works beautifully to allow the JavaScript to handle the invalid user/password without FireFox popping up its own log on box. The trouble (and where I think I've found a bug) is this: Once FireFox 4 has sent credentials and gotten either the 200 or 403 response, it caches those credentials permanently in the FireFox session! For example: 1. The user comes to the log on form and enters the credentials incorrectly the first time. 2. The user then corrects the credentials and submits again. 3. FireFox 4 sends the Authorization header with the bad credentials from step 1! Even though the XMLHttpRequest.open() call specifies different credentials. I'm very sure this is a bug because: 1. In FireFox 3 this does not happen. FireFox 3 sends the actual credentials that are passed to XMLHttpRequest.open() every time. 2. FireFox 4's own log on box does not suffer from this problem. It should be no different with XMLHttpRequest. 3. No other browser suffers from this problem. If this actually appears to be a bug, how to I go about submitting a bug report?