|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call for Participation
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@m... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








