durusmail: quixote-users: cookies
cookies
2002-05-28
2002-05-28
2002-05-28
2002-05-28
2002-05-29
2002-05-29
2002-05-29
2002-05-29
2002-05-29
cookies
Greg Ward
2002-05-29
On 29 May 2002, Patrick K. O'Brien said:
> This is excellent. I was hoping you would address this. Could you also give
> an example to round out this case? Should the path be:
>
>   COOKIE_PATH = "/q"
>
> or
>
>   COOKIE_PATH = "/q/"
>
> or does it not matter? (I suspect the latter is correct.)

Actually, the examples in RFC 2109 use the "/q" form, without discussing
the security hole that cookies destined for "/q" would also be sent to
"/qux", which might not be under your control.  RFC 2965 doesn't appear
to be much better.

Cookie experts (hello Andrew), want to help me out here?  Putting
Path="/q" in a cookie looks like asking for trouble, even though that's
exactly what the examples in RFCs 2109 and 2965 illustrate.  Am I
missing some vital paragraph that says a URI of "/qux" does not match a
cookie path of "/q"?  (I don't think so: RFC 2965 even defines
"path-match", and it looks to me like "/qux" path-matches "/q", which
means Path="/q" in a Set-Cookie header is a security hole.)

I'm going to take the cautious approach and recommend "/q/" in the
Quixote docs, unless someone says why I shouldn't...

> A couple of URLs to these RFCs would be icing on the cake.

Done.

> My final question/suggestion is to document how the settings in the config
> interact with the parameters specified in the specific call to set_cookie().

I've just added this paragraph:

  Finally, note that the COOKIE_* configuration variables *only* affect
  Quixote's session cookie; if you set your own cookies using the
  HTTPResponse.set_cookie() method, then the cookie sent to the client is
  completely determined by that set_cookie() call.

Clear 'nuff?

Hmmm... those config variables probably should be called
SESSION_COOKIE_*.  So many other things have changed in 0.5 that one
more won't hurt.  Any dissenters?

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org


reply