[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 Particip atio

• To: Rich Salz <rsalz@d...>
• Subject: RE: Re: Cookies at XML Europe 2004 -- Call for Particip ation
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Mon, 5 Jan 2004 21:31:54 -0500
• Cc: XML-DEV <xml-dev@l...>
• In-reply-to: <Pine.LNX.4.44L0.0401051922020.4127-100000@s...>
• References: <Pine.LNX.4.44L0.0401051922020.4127-100000@s...>

At 7:41 PM -0500 1/5/04, Rich Salz wrote:

>Since you seem to have given this more than just casual thought, have
>you got ideas about a solution?  To be explicit, the goals are:
>         Authenticate clients
>         Allow URL's to be cut/pasted amonng participants
>         Limited exposure if packets are snooped


The solutions vary depending on the exact purpose. Restricting access 
to password protected data is different from a shopping cart is 
different from tracking users across sites. Except perhaps for the 
latter, all can be solved without cookies. In all three cases (and 
others) the user experience is improved without cookies.

In a truly individualized situation all that's needed are URLs of the 
form http://www.example.com/page.html?username=elharo

The username can also be stored in the path or authority component if 
that's easier. e.g.

http://elharo@w.../page.html
http://www.example.com/page.html/elharo

Note that the password is *not* transmitted in the URL. The server 
requests the password using standard HTTP authentication mechanisms 
and the client provides it in the standard way. Similarly other 
information that is often stored in cookies--shopping cart contents, 
path through a site, time of login, etc.--also need not be stored in 
the URL. The server maintains this information as it does even with 
cookies, at least in a secure system) and displays it to the user in 
the content of the page. However, it need not show up in referrer 
logs, browser location bars, and other such insecure places.

Not all use cases need this. For instance, if the site is merely 
password protected but not customized per user (e.g. the W3C members 
only pages) then the user name does not need to be part of the URI 
because the page is not different for different users. But for each 
different resource, there should be at least one URI. Cookie based 
sites fail this test.
-- 

   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

• Follow-Ups:
  • RE: Re: Cookies at XML Europe 2004 -- Call for Particip ation
    • From: Rich Salz <rsalz@d...>
  • Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
    • From: Robert Koberg <rob@k...>

• References:
  • RE: Re: Cookies at XML Europe 2004 -- Call for Particip ation
    • From: Rich Salz <rsalz@d...>

• Prev by Date: Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
• Next by Date: Re: SAX and ignorableWhitespace
• Previous by thread: RE: Re: Cookies at XML Europe 2004 -- Call for Particip ation
• Next by thread: Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
• Index(es):
  • Date
  • Thread