WWW-Realm: /, kino.hotwired.com, staffweb.hotwired.com:8000/Staff/
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
gives:
WWW-Realm: /, www.nsa.gov
A given user comes here, enters a name and password, and follows a link to
www.nsa.gov. 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 www.nsa.gov, even if www.nsa.gov didn't specify a realm -
if it did so, I could get that user's valid name and password to
www.nsa.gov if I wished, which would be bad.
Good call! Let's get it in HTTP 2.0....
Brian
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
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/