On Fri, Sep 25, 2009 at 10:42 AM, Simon Willison <[email protected]> wrote: > On Sep 25, 3:39 pm, Simon Willison <[email protected]> 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 with the creation-timestamp > rather than the expiration-timestamp - it leaves the door open for a > mechanism whereby historic SECRET_KEYs are stored. When we see a > signed string, we can use its timestamp to decide which of our > historic keys should be used to validate it.
But that only works for signatures that do in fact use a timestamp. If the API makes timestamps optional, then there's still the question of what to do for signatures that aren't stamped anyawy. In those cases, I assumed the protocol would be to simply try to most recent SECRET_KEY and work backward if the signature failed. Once all current and deprecated keys have been tried (which should only be a total of two, I would think), it would raise BadSignature at that point. If we already have that behavior for non-timestamped cookies (and correct me if I'm wrong on that point), I don't know that it's much of an argument in favor of which timestamp to use. As long as there's not a huge list of valid SECRET_KEYs to choose from, the overhead of trying them each individually should be negligible, so I'm not sure how much of an issue it would be. I do agree though that you do have a point about there being possible reasons for expiring the key at a different point after the fact, but I'd argue that in those cases, you'd want to set an explicit expiration time. In your example, you provided expire_after=24 * 60 * 60, but that wouldn't let you expire a cookie because of an event that happened 2 hours ago. I would think you'd want to pass in a specific time that cookies should be considered expired instead. Of course, that then goes back to stamping cookies with their creation time anyway, because otherwise you couldn't really do it right. If I say "expire as of time X" I want to expire all cookies issued prior to that point in time, while leaving any issued after that point intact. The only way to make that decision is to know the time it was issued, rather than when it was originally expected to expire. I think we're getting a bit ahead of ourselves, though. There's nothing stopping an application timestamping its own signatures and validating them however they like, so we're really just discussing a reasonable default here. Heck, since the timestamp behavior is driven entirely within an already-signed value, we don't need to provide any behavior at all if it's not a common requirement. I think it's a good idea, but I'd like to hear from other people before I really stand behind including it. -Gul --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
