On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven <[email protected]> wrote: > > +1 on the concept of a signing module. > > On Sep 25, 7:48 am, Marty Alchin <[email protected]> wrote: > >> The one downside to using get() directly, as opposed to an altogether >> new method, is that get() doesn't raise a KeyError when a value >> doesn't exist. That means if anyone's wrapping request.COOKIES[key] in >> a try block and catching KeyError, changing to the new code is more >> than just a one-liner. > > Adding my coat of paint to the shed... > > Rather than a "request.unsign_cookie" method, provide a > "request.SIGNED_COOKIES" property (or perhaps alteratively, > request.COOKIES.signed if the interface was useful enough to use > across request.GET/POST too) containing a lazy dict-like object which > only retrieves (correctly) signed cookies. > This way you are using a similar interface, but it's obvious in code > that you're only interested in signed ones. > > For example: > > # raises KeyError > value = request.SIGNED_COOKIES['bad-cookie'] > > # value == None > value = request.SIGNED_COOKIES.get('bad-cookie') > > Personally, I don't see much point in specifically reporting on > incorrectly signed cookies - imo they should just be treated as if > they never existed. If someone really cared, they can look in > request.COOKIES to see if the cookie was in there but not in > SIGNED_COOKIES.
The problem is that you don't know which cookies are signed and which aren't for the reasons posted earlier. So you don't know which cookies to put in SIGNED_COOKIES and which to put in COOKIES unless accessing COOKIES gives you raw values of ALL cookies and SIGNED_COOKIES attempts to unsign ALL cookies. That seems really clunky. You have to sign and unsign the cookies yourself in code which makes the sign_cookie/unsign_cookie API make sense. Ian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
