Am 25.09.2009 um 22:04 schrieb Simon Willison:
>
> On Sep 25, 4:44 pm, Johannes Dollinger
> wrote:
>> Regarding parity, let me advertise a Signer object again:
>>
>> signer = signed.Signer(
>> key=settings.SECRET_KEY,
>> expire_after=3600
>> )
>>
> Signed cookies are useful
> for all sorts of things - most importantly, they can be used in place
> of sessions in many places, which improves performance (and overall
> scalability) by removing the need to access a persistent session
> backend on every hit. Set the user's username in a signed c
On Oct 5, 1:44 pm, Simon Willison wrote:
> Other than dates being a bit more annoying to pass around, I really
> don't think that telling people they can only dumps/loads JSON-
> encodable data would be a huge burden.
You could use YAML instead if you want date support... although JSON
does seem
On Oct 5, 6:33 pm, Matt Brubeck wrote:
> On Sep 24, 10:18 am, Simon Willison wrote:
> > This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> > generate and append signatures to bytestrings and confirm that they
> > have not been tampered with. dumps and loads can be used to creat
On Sep 24, 10:18 am, Simon Willison wrote:
> This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> generate and append signatures to bytestrings and confirm that they
> have not been tampered with. dumps and loads can be used to create
> signed pickles of arbitrary Python objects.
I've started a project on GitHub to develop the signing
implementation:
http://github.com/simonw/django-signed
The TODO section in the readme shows the next things I'll be working
on.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
On Sep 25, 4:44 pm, Johannes Dollinger
wrote:
> Regarding parity, let me advertise a Signer object again:
>
> signer = signed.Signer(
> key=settings.SECRET_KEY,
> expire_after=3600
> )
>
> s = signer.sign(v)
> v = signer.unsign(s)
>
On Thu, Sep 24, 2009 at 5:33 PM, Chris Beaven wrote:
>
> 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 i
On Fri, Sep 25, 2009 at 10:42 AM, Simon Willison
wrote:
> On Sep 25, 3:39 pm, Simon Willison wrote:
>> While that makes sense for caching, I couldn't say if it makes sense
>> for signatures or not - when we sign something, will we always know
>> the point at which we want that signature to expir
> Would expire_after on the unsign just automatically imply
> timestamp=True? There's been a lot of concern raised about parity in
> the API, and it reads a little weird with the two different arguments.
> I'm not sure it's a problem, but it's just a little funny.
Regarding parity, let me advert
On Sep 25, 3:39 pm, Simon Willison wrote:
> While that makes sense for caching, I couldn't say if it makes sense
> for signatures or not - when we sign something, will we always know
> the point at which we want that signature to expire? I don't know.
Here's a good argument for signing things wi
On Sep 25, 3:10 pm, Marty Alchin wrote:
> The timestamp would then be the actual expiration
> time, rather than the time it was signed, so the API can look like
> this instead (with a key added per prior discussion).
>
> >>> s = signed.sign('key', 'value')
> >>> v = signed.unsign('key', s)
> >>>
On Fri, Sep 25, 2009 at 9:26 AM, Simon Willison wrote:
> The API would look something like this:
>
s = signed.sign('value', timestamp=True)
v = signed.unsign(s, expire_after=24 * 60 * 60)
>
> A SignatureExpired exception would be raised if the signature was
> older than the expire_after
On Sep 25, 1:57 pm, Marty Alchin wrote:
> I think this is good for everywhere the raw signing API is accessed,
> perhaps to the point where that API can't even be used without a key
> (a namespace, really - honking great idea!). Helpers on top of that
> API could do without asking for that separa
On Sep 25, 1:57 pm, Marty Alchin wrote:
> I wish there was
> a way to sign the expiration as well, so people couldn't artificially
> extend the life of the cookie, but since that doesn't come back in the
> request, there'd be no way to validate it.
We can do that by baking the timestamp the cook
On Fri, Sep 25, 2009 at 7:02 AM, Luke Plant wrote:
> Suppose one part of an app signs an e-mail address for the purpose of
> an account confirmation link sent in an e-mail. The user won't be
> able to forge the link unless they know HMAC(SECRET_KEY, email).
>
> However, suppose another part of t
On Friday 25 September 2009 12:27:53 Simon Willison wrote:
> Do you have any further information on the WordPress problems?
No, I can't find it. It might not have been WordPress. All I remember
is that it was along the lines of what I outlined in my previous e-
mail -- one part of the applicat
On 9/24/09 9:56 PM, Ian Lewis wrote:
> 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
On Sep 25, 12:02 pm, Luke Plant wrote:
> In other web apps (I think Wordpress?), there have been problems
> associated with use of secret keys when the same key is used for
> different purposes throughout the application.
> ...
> - we add unique prefixes to the SECRET_KEY for every different
>
On Sep 24, 3:46 pm, Simon Willison wrote:
> > 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').
>
> If we were going to do that, it would make s
On Thursday 24 September 2009 18:18:56 Simon Willison wrote:
> SECRET_KEY considerations
> =
Can I add some other things I've been worrying about while we're on
the topic?
In other web apps (I think Wordpress?), there have been problems
associated with use of secret ke
On Sep 25, 4:48 am, Russell Keith-Magee
wrote:
> By way of greasing the wheels towards trunk: if the outcome of this
> mailing list thread was a wiki page that digested all the ideas,
> concerns and issues into a single page, it will make the final
> approval process much easier.
Great idea: htt
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 an
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
18 PM, 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
>
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 in
38 matches
Mail list logo
