The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: Simon Willison <si...@simonwillison.net>
Date: Thu, 24 Sep 2009 11:54:28 -0700 (PDT)
Local: Thurs, Sep 24 2009 2:54 pm
Subject: Re: Adding signing (and signed cookies) to Django core
On Sep 24, 7:37 pm, Marty Alchin <gulop...@gmail.com> wrote:
> Another option would be to have request.COOKIES be a custom
Hmm... I hadn't considered that. I was thinking that the unsigning
> dictionary, with an extra .get_unsigned(key) method that would work > like .get(), but validates the signature along the way. That behavior > can't be added straight to __getitem__() though, because that has no > way of knowing whether the cookie was signed to begin with. 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)
But that's pretty ugly. Not sure what to do about this one -
> eyes. Yeah, I suppose we could perhaps make that a subclass of
That's a great argument against subclassing ValueError - I hadn't
> ValueError or TypeError, but I would worry about people wrapping it up > into something else that might cause problems. > try:
considered the unicode case. You're right, if anything it should subclass SuspiciousOperation instead. Cheers,
Simon
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||