[Twisted-web] web2 response.setCookie and request.getCookie shortcuts?

[James Y Knight]

On Nov 17, 2005, at 6:57 AM, glyph at divmod.com wrote:
> "content-length" and "connection" are just headers too: but the  
> code has to support them because they're in the RFC.  Technically  
> speaking cookies aren't in the *same* RFC, but they do have a  
> standard of their own, rfc2109.
>
> If there were multiple possible implementations of cookies, I'd say  
> there should be an adapter or something to keep it separate.  Since  
> there is just the one way to do them, though, I think that it's  
> reasonable to treat the standards as merged, and just put the  
> methods on request to handle it.  Pragmatically speaking cookies  
> are not an "optional" extension to HTTP/1.1.
>

Agreed, cookies are important. But, there's not just one possible  
implementation. To start with, you've got three specs: netscape,  
RFC2109, and RFC2965. I believe RFC2109 is essentially dead, and  
shouldn't be cared about.

The code is there to parse and unparse all the cookie headers in both  
Netscape and RFC2965 format, in the same way the code is there to  
parse and unparse content-length. As cce indicated, you can directly  
manipulate the parsed header representation. However, a higher-level  
interface to cookies should be implemented.

However, this higher level implementation is not entirely trivial,  
which is why I haven't done it yet. As an example of some of the non- 
trivialities:

The Netscape cookie spec is insecure, often allowing random other  
hosts on the internet to set cookies for your host(*). Uptake of the  
RFC2965 spec is slow but gaining somewhat, and supporting it would be  
a good move. It adds the ability to determine what host/path the  
cookie was set for, so your application can verify that it isn't  
getting cookies from an unexpected source. So, the high level  
interface has to be more than a simple dictionary, it has to be  
filterable by acceptable source host/port/path. But only when you  
know you're talking to a client that supports RFC2965, which you can  
tell because of various attributes. And when setting a cookie,  
probably both Set-Cookie and Set-Cookie2 should be sent.

And stuff like that. All doable, and should be done, but to say  
there's only one obvious way to do things is not exactly true. :)


(*): Most common example: User follows a link to http:// 
attacker.co.uk/. Said webpage makes a request in the background to  
http://myserver.co.uk/ and I setup a new session and send back a  
cookie with the session id: SID=1234. Attacker then sends back to  
user a cookie: SID=1234, domain=.co.uk and redirects user to http:// 
myserver.co.uk/. Myserver gets the SID cookie, and uses that session.  
Attacker now has access to all data available through user's session.  
D'oh!

This was originally supposed to be prevented by the rule implemented  
in browsers that you cannot set a prefix cookie for domains without a  
dot, but that only protects domains which sell the second level  
(e.g. .com, .org, .net).

James