The lack of parallelism in terms of the interface is my biggest hangup here.
I do think that this should find it's way into trunk, as signed cookies are important in the use cases you mention and are really easy to get wrong... and getting it wrong can be dangerous. I'm not going to get into the dumps/loads bit right now because there's enough to tackle on signed cookies. On Thu, Sep 24, 2009 at 2:54 PM, Simon Willison <[email protected]> wrote: > Hmm... I hadn't considered that. I was thinking that the unsigning > could be transparent, so by the time you access request.COOKIES['key'] > the value had already been unsigned (and if the signature failed the > cookie key just wouldn't be set at all, as if the cookie never > existed). But as you point out, this doesn't work because you can't > tell if the cookie was signed or not in the first place. > > We could fix this with a naming convention of some sort: > > response.set_cookie('key', 'value', sign=True) > - results in a Set-Cookie: key__Xsigned=value header Unfortunately, this approach won't work. A malicious client can just send "key" rather than "key__Xsigned" and you'll never know that the cookie hasn't gone through validation. This also means that you can't look for cookie values that match a specific format (ex: body.signature) because a malicious client could just drop the signature portion. As always, we can't trust the client. :-( This means that unsigning can *never* be fully transparent. We need a symmetric specification of the fact that a given cookie should, indeed, be signed. > But that's pretty ugly. Not sure what to do about this one - > request.unsign_cookie('key') might be an option, as at least that > reflects the set_cookie / sign / unsign API a bit. Not ideal by a long > shot though. I'm not sure what the best solution is, but here are some of the options I've considered: 1) request.unsign_cookie('foo') -- This breaks the parallelism with existing cookies. Sometimes we'll be doing request.COOKIES['foo'] and sometimes we'll be doing request.unsign_cookie('foo'). 2) A decorator for views -- @unsign_cookies("foo", "bar") -- This doesn't allow any sort of fall-back (you can't customize what to do if a given cookie is improperly signed) 3) COOKIES as an intelligent object -- We can overload .get so we're doing something like request.COOKIES.get('foo', signed=True) -- I think this has the best chance at an interface that keeps a consistent feel. It's completely backward compatible, though it breaks the traditional expectation of what you can do via the `get` method on a dictionary. Best, - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
