Re: authentication cleanups

Brian Behlendorf (
Wed, 9 Nov 1994 17:49:19 -0800 (PST)

This makes great sense. Right now browsers (we're hoping!) resend names
and passwords for every access to the same machine and port. Obviously
for some other situations this is less than ideal. I'd also like to see
the ability to put other machines and ports in the WWW-Realm-Partial line
- for example, it'd be great if we could set up the HotWired system such
that instead of one monolithic server (actually two) doing duty as, we could set up separate servers for separate content
areas or functions, with the user just entering their name and password
*once*. I.e.

WWW-Realm: /,,

I don't see any security problems with declaring another host as a member
of a realm, as long as it's not reversible. I.e., let's say my server

WWW-Realm: /,

A given user comes here, enters a name and password, and follows a link to The client enters the cached name and password there, which
fails. They then enter a name and password that succeeds. If they come
back to my machine, the client should *not* send the cached name and
password from, even if didn't specify a realm -
if it did so, I could get that user's valid name and password to if I wished, which would be bad.

Good call! Let's get it in HTTP 2.0....


On Thu, 10 Nov 1994, Tony Sanders wrote:
> Perhaps servers should return a indication of what area is
> covered by the authentication. For example:
> Client:
> GET /protected/recipies/secret-sauce/ingredients HTML/1.0
> ...
> Server:
> 401 Unauthorized
> WWW-Authenticate: Basic realm="burgers_and_fries"
> WWW-Realm-Partial: /protected/recipies/, /protected/foods/
> ...
> Client:
> GET /protected/recipies/secret-sauce/ingredients HTML/1.0
> Authorization: Basic mickeyd:passwd
> ...
> And now the client knows that it is ok to send the username/password on
> an access to /protected/recipies/fries or /protected/foods/fries but that
> should the user select something in /protected/payroll/* then it would
> *not* send the users password to that area because they would probably
> generate a security warning being issued.
> Does this make sense?

Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3