A big +1 on signed cookies, and I like the direction the discussion is
going.
Also, I hope this doesn't derail this discussion, but I hope after
signed cookies are added, auth can be made to optionally use signed
cookies instead of sessions.
Thanks,
Eric Florenzano
--~--~-~--~~--
On Fri, Sep 25, 2009 at 1:18 AM, Simon Willison wrote:
>
> As mentioned in the thread about cookie-based notifications, at the
> DjangoCon Sprints I raised the subject of adding signing (and signed
> cookies) to Django core.
>
> I've found myself using signing more and more over time, and I think
On Fri, Sep 25, 2009 at 10:40 AM, Jay wrote:
>
> Hi there,
>
> I have a question on customize the db field. For this field, I want to
> save integers in db, but want them to be my custom class when they are
> used in Python code. In Django docs, it's said that I should set the
> __metaclass__ to
Hi there,
I have a question on customize the db field. For this field, I want to
save integers in db, but want them to be my custom class when they are
used in Python code. In Django docs, it's said that I should set the
__metaclass__ to be models.SubfieldBase to make to_python() work. I
tried it
On Sep 25, 1:56 pm, Ian Lewis wrote:
> [...] unless accessing
> COOKIES gives you raw values of ALL cookies and SIGNED_COOKIES
> attempts to unsign ALL cookies. That seems really clunky.
Yes, all cookies would stay in COOKIES.
SIGNED_COOKIES would be a lazy dict-like object, not a plain
dictiona
On Fri, Sep 25, 2009 at 4:46 AM, Simon Willison wrote:
> This isn't so bad, since we already have a precedent for this in
> request.POST.get_list('foo'). request.COOKIES.get_signed(key) might be
> OK.
request.COOKIES.get_signed(key) makes the most sense to me since it's
clear you are dealing wit
On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven wrote:
>
> +1 on the concept of a signing module.
>
> On Sep 25, 7:48 am, Marty Alchin 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 exi
+1 on the concept of a signing module.
On Sep 25, 7:48 am, Marty Alchin 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 t
How about Signer class?
signer = Signer(key=...)
assert signer.unsign(signer.sign(value)) == value
This way you wouldn't have to pass around key, extra_key, and
potential further arguments but a single Signer instance. Plus, you
could easyly overwrite hashing, concatenation,
On Thu, Sep 24, 2009 at 3:22 PM, Benjamin Slavin
wrote:
>> 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 k
On Sep 24, 8:22 pm, Benjamin Slavin wrote:
> 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
> Also, does the name of a cookie factor into the cookie length limits?
> My reading of RFC 2109 says yes, but it'd be worth verifying, since it
> would cut down on the usable value space. With your compressed base64
> stuff, that's not as big of a problem, but still something to look
> into.
Als
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
On Thu, Sep 24, 2009 at 2:54 PM, Simon Willison 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
On Sep 24, 7:37 pm, Marty Alchin wrote:
> Another option would be to have request.COOKIES be a custom
> 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, be
I'm obviously going to weigh in here, having authored the signed
cookies app you mentioned below, but be aware I'm not a cryptographer,
nor do I have any personal use for signed cookies at all. I can
appreciate their value, but I'm not even using my own app in anything,
so if there are problems wi
+1 for signed cookies. Your API looks reasonable and I'd agree that
set_cookie(..., signed=True) fits better with the rest of the API as well.
What about some sanity checking to make sure that, if SECRET_KEY is used, it
is, at the very least, a non-empty string?
On Thu, Sep 24, 2009 at 1:18 PM, S
As mentioned in the thread about cookie-based notifications, at the
DjangoCon Sprints I raised the subject of adding signing (and signed
cookies) to Django core.
I've found myself using signing more and more over time, and I think
it's a concept which is common enough to deserve inclusion in Djan
18 matches
Mail list logo
