W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: [#177] Realm required on challenges

From: Jim Luther <luther.j@apple.com>
Date: Tue, 7 Jul 2009 10:20:33 -0700
Message-Id: <4E439500-0DA8-4051-9F61-F34BB3F5B60F@apple.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
On Jul 7, 2009, at 1:28 AM, Adrien de Croy wrote:

> I've never seen a browser use the realm for anything other than a  
> label in a dialog box either.

Apple's network framework code won't use a user's stored credentials  
in a response unless the protection space for the authentication  
challenge and the protection space for the stored credential match.  
Our code considers protection spaces to match if the host, port  
number, server type (http, https, http proxy, https proxy, ftp, etc),  
and authentication scheme (Basic, Digest, etc) all match. If the  
challenge includes a realm, then the stored credential's protection  
space must have a realm and it must match the challenge's realm; if  
there is no realm in the challenge, then the stored credential's  
protection space must not have a realm. So yes, our code checks the  
realm if it is included in a challenge and it require a realm for  
Basic and Digest Access authentication.

On Jul 7, 2009, at 2:00 AM, Thomas Broyer wrote:

> See http://ltgt.net/tests/http-auth-realm/
>
> I tested it in IE8, Firefox 3.5, Opera 9.64, Safari 4 and Chrome
> 3.0.191.3 (Dev channel), all on Windows.

And you'll see that Safari 3 and 4 on Mac OS X, and Safari 3 on  
Windows, also behave correctly.

I've had complaints that our matching is too strict, but I don't think  
so. For example, I've been told that other browsers will hand out  
credentials stored for port 80 to a challenge from the same host on  
port 443 if the rest of the challenge is the same -- I consider doing  
that a security hole. Anyone want to write a test to check that?

- Jim
Received on Tuesday, 7 July 2009 17:21:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:07 GMT