Re: Basic auth and realms

Hi Bjoern

thanks for your reply, there are a few things I still don't understand 
though

Bjoern Hoehrmann wrote:
> * Adrien de Croy wrote:
>   
>> The description of this realm parameter is confusing.  Especially when 
>> considering a proxy.  Commonly a proxy will want a realm that means 
>> "everywhere".  How should one specify this?  would it be
>>
>> realm="/"
>> realm="*"
>>
>> or what?
>>     
>
> Section 2 for Basic notes "The realm value should be considered an
> opaque string which can only be compared for equality with other
> realms on that server." Meaning it does not matter which string you
> use as far as the protocol is concerned.
>   
How does that fit with appending the realm to a base URI to get a 
"protection space".  to me it seems that indicates that the realm should 
be like a folder on a webserver.  The credentials may be automatically 
re-presented for any URL that maps to a resource in that folder (or any 
sub-folders).

since the client doesn't present the realm back to the server, its 
status as opaque string seems rather pointless.  The server can't refer 
back to it.

so the only thing that can use the realm is the client - and for 
comparison to other realms only? 

How then can the client decide whether to try the credentials or not if 
it cannot apriori calculate whether the next URI request will be in the 
same realm as some previous realm?

Adrien

>   
>> "The realm directive (case-insensitive) is required for all 
>> authentication schemes that issue a challenge. The realm value 
>> (case-sensitive), in combination with the canonical root URL (the 
>> absoluteURI for the server whose abs_path is empty; see section 5.1.2 of 
>> [2]) of the server being accessed, defines the protection space. "
>>     
>
> This is talking about tuples
>
>   { 'http://example.com', 'Realm 1' }, # Protection space 1
>   { 'http://example.com', 'Realm 2' }, # Protection space 2
>   { 'http://example.com', 'Realm 3' }, # Protection space 3
>   ...
>
>   
>> Browsers seem to behave differently in regards to when they will 
>> automatically re present the same proxy credentials.
>>     
>
> The specification just says
>
>   Similarly, when a client sends a request to a proxy, it may reuse a
>   userid and password in the Proxy-Authorization header field without
>   receiving another challenge from the proxy server.
>
> So they are indeed free to differ in this regard.
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Monday, 16 June 2008 23:10:26 UTC