On Dec 21, 2:40 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > * I'm not sure I like this being in django.utils. To me, it feels > like something that should be in django.core - along with caching, > serialization, etc, signing is a core piece of functionality that a > website will need to implement. django.utils is full of necessary, but > largely ancillary code.
I have to admit I don't 100% understand the difference between core and utils - but I'm happy with moving it across to core if that makes more sense. > * get_cookie_signer() strikes me as something that should be a > general utility in the signing module, not something buried in > django/http. I'd love to see this code factored out as per Marty's suggestion in another thread. I wrote a backend just for signed cookies because that's the one part of the implementation that's "baked in" to core Django APIs - but I expect other bits to be baked in to things like session handling / auth / form wizards etc over time, so being able to over-ride the Signer used for those in the future will be important. > * django.http.raise_error should be RAISE_ERROR, so it's obvious it's > a constant Good point, I'll fix that this evening. > * I'm not sure I follow why we need to use base62 (and therefore > provide our own base encoding method) in the Timestamp signer. OK, you caught me. This is part of my evil scheme to sneak baseconv.py in to Django. I'm using it for the signed cookie timestamp to make it as small as possible (same reason I'm using a base64 of the HMAC hash rather than the regular hexdigest) - since cookies add overhead to every single HTTP request I figure anything we can do to make them smaller is a bonus. I considered using a custom timestamp in seconds since (2009, 12, 1) but that felt a little weird. baseconv.py is actually a lot more important for some of the other ways I use signed cookies. A great example is "recover my account / forgotten password" e-mails. I like sending a signed URL for those (no need to store any state) but it needs to be under 72 characters to fit in an e-mail: http://simonwillison.net/recover/b23/kfQJafvGyiofrdGnuthdxImIJw/ Where b23 is the base62 encoded user ID and the bit after it is a signature. URLs like that often make use of timestamped signatures (I like my recover account URLs to expire after 24 hours) so again it's useful to keep them short. baseconv.py is also useful for things like URL shorteners e.g. http://swtiny.eu/EZj > * In the original mailing list thread, there was discussion about > prefixing the use of SECRET_KEY with some extra data, like the module > name. The 'salt' option is one way to achieve this, but I agree with > Luke and Marty that there should be some mandatory salting. I'll look at that this evening. > * The original mailing list thread (and the wiki) also contained > discussion about how to deprecate/cycle SECRET_KEY values in the case > a value was compromised. Having a working solution for this problem > probably isn't necessary, but it would be good to know that I've got a plan for that as far as signed cookies go - an optional piece of middleware which looks for invalid signed cookies in the request, checks them against an OLD_SECRET_KEYS list and upgrades them if they can be decrypted that way. This can be implemented completely separately from the current code, though the ideal implementation would involve adding a few related methods to the Signer class. 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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
