[
Lists Home |
Date Index |
Thread Index
]
At 10:06 AM -0500 1/6/04, Michael Champion wrote:
>I'm having a hard time seeing any deep architectural distinction
>between using a cookie to remember a (presumably encrypted)
>name/password and using a proprietary mechanism in a browser to
>remember a name/password. Why is the former bad and contrary to the
>web architecture, and the latter is a good thing, even though "it is
>very little used on the web today?" (Why not?)
Good question. First of all, cookies aren't always encrypted. More
commonly, they're just obscured. Even if they are encrypted, they're
normally fed back to servers automatically, whether the right user is
sitting in front of them or not. I can login to my wife's amazon
account just by using her computer without knowing her password. When
the browser stores the passwords it uses a master password before it
will feed anything to a web site. (Older browser don't always get
this right, but it's getting better.) It's a question about who's in
control of the information. I'm not sure that's an architectural
distinction though.
I think the main architectural distinction is not about caching of
user names and passwords. It's about making sure that the same URLs
identify the same resource. My shopping cart is not the same thing as
your shopping cart yet they may well have the same URL which is only
distinguished by a cookie. Instead they should be distinguished by
different, persistent URLs.
But assume you avoid this trap. You use cookies to cache the user
name and password, but for nothing more. My shopping cart has a
different, persistent URL than your shopping cart. There's still a
problem. Cookies cache the user name and information on a per-site
basis rather than a per-URI basis. I suppose you could fix this by
storing the URI in the cookie and using many extra cookies, but it's
hard and messy and most sites don't do it. Using HTTP authentication
you can assign different user names and passwords to different pages,
and it's all sorted out easily. When might this be useful? Anytime
you want to use multiple user names and passwords on the same site.
For instance, a father might want to have the user info for both his
Yahoo account and his childrens' accounts, and choose between them
dynamically without overwriting any of them. Indeed he might want to
have both accounts open at the same time in separate windows. Is this
even possible with cookies? It's definitely possible when different
accounts have different URLs and HTTP authentication is used to
provide the password.
Or perhaps I have both a personal amazon account and a business
amazon account, both of which I access from the same computer, maybe
even at the same time. If each account has a separate URL and a
separate user name and password, no problem. If each account has the
same URL, I'm in trouble.
The key idea is this: independent URLs for independent resources. If
all the information I need to locate the resource (not necessarily to
access, but to locate) is in the URL, we're in business. If some of
the location information is hidden in the cookie, you've got problems.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
