On 9/24/09 9:56 PM, Ian Lewis wrote:
> On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven<smileych...@gmail.com>  wrote:
>    
>> +1 on the concept of a signing module.
>>
>> On Sep 25, 7:48 am, Marty Alchin<gulop...@gmail.com>  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.
>    
Use a decorator or something that marks the cookies that should be in 
SIGNED_COOKIES.

I'm not a huge fan of request.SIGNED_COOKIES. I'd rather see them all in 
request.COOKIES, but the same idea could still apply:

@expects_signed_cookies('username')
def user_home(request):
      ...

Alternatively, is it stupid to think that the number of signed cookies 
used by an application is probably small enough that keeping a list of 
them in settings.py is too much book keeping? Then, when 
setting/retrieving a cookie, a lookup is done in settings, and if the 
key is marked as SIGNED, it does it without human intervention. Less 
things to go wrong that way I'd think, and any third-party app's cookies 
can be secured without hardly any code changes.

SIGNED_COOKIES = ['username']

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to