On Sep 25, 3:10 pm, Marty Alchin <[email protected]> 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) > >>> s = signed.sign('key', 'value', expire_after=24 * 60 * 60) > >>> v = signed.unsign('key', s)
Baking an expiration time in to a signed value and checking for it when we unsign is definitely possible, but I'm a bit torn between the two options. I prefer setting the expiry time when I read the cookie rather than when I set it, but I can't say exactly why. I think it's based on bad experiences with memcached - I've frequently found a need to set things in the cache for ever and decide whether or not to treat them as stale on retrieval (for implementing things like serve-stale- on-error) which has made my instinct be to bake the time-of-creation in to the thing and leave the is-this-stale decision until as late as possible. 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. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
