Re: Basic Authentication behavior

Scott Lawrence <lawrence@agranat.com> wrote:
>  It has been our observation that most browsers handle multiple
>  realms in the same server poorly; once they have established a set
>  of credentials for a given server, they will always send that set
>  until it fails.  If the failure presents a new realm, most browsers
>  forget the credentials for the first realm.  To check your favorite
>  browsers, see:
>
>    http://digest-test.agranat.com/test_list.html
>
>  and follow the link to "Authentication in multiple realms".
>
>  Look forward to this in the interoperability events...

	I'm a bit concerned that the logic you (and John, and Jim)
are bringing to this issue, and reflected in your "event" test, may
be on the verge of creating a post hoc logic versus current practice
pickle, homologous to that for redirection.

	It is classic libwww behavior to guess a template for a Basic
realm, and that is current practice for software which has it as a
heritage.  The libwwws also supported a WWW-Protection-Template header
which could be used to avoid need for guessing by the UA, e.g.:

WWW-Authenticate: Basic realm="WallyWorld"
WWW-Protection-Template: /sym1/sym2/*

If the hiearchy of symbolic elements for the path of the request were
/sym1/sym2/sym3/foo.blah   and there were no template indicated (and
it never is, because that header never got into any IETF RFCs :) the
UA guesses   /sym1/sym2/sym3/*   and depending on subsequent requests
might eventually infer that   /sym1/sym2/*   is the "correct" template.
The hierarchy of symbolic elements is related to file system paths
via map/pass rules, so there need not be a one-to-one correspondence of
elements, and the file system paths may not have any slashes, depending
on the platform.  You can have different scripts in the same file system
directory and in different realms, but you do it by associated them with
different symbolic elements in the URL path hierarchy. 

	The Digest Access Authentication RFC states that it is
"conceptually similar" to Basis Access Authentication, and discusses
differences, but not this one based on implied/inferred templates.

	It might be better if Ari and Henrick could be induced to add
an implementation note to the -08 HTTP/1.1 draft concerning the current
practice of implied/inferred templates for Basic realms, than to apply
post hoc reasoning that it's a bug.   I doubt that Basic will fade
away, i.e., it most likely will still be used in conjunction with SSL,
so it's worth making this template issue clear.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Sunday, 7 September 1997 12:47:31 UTC