I've taken the liberty of writing up a contrib middleware to transparently implement signed cookies in a Django app. It autmatically signs and validates all cookies on its own, without any other code needing to know a thing about it. That is, it cleans up after itself, so that views and other middlewares receive the original cookie value, without the signature. It is able to just be dropped into MIDDLEWARE_CLASSES prior to any other middlewares that use cookies, in order for those middlewares (and views) to have validated data.
There are a few notes worth mentioning. The signed cookies are 33 characters longer than they were intended to be when written (due to the signature written out by this middleware). This technically does impose a slight increase in bandwidth on each subsequent user request, and can also become a more serious problem if the cookie is exceptionally long (since the signature might push it over a browser's cookie length limit). This can be avoided for middlewares that use cookies, by placing those middlewares ahead of this one in MIDDLEWARE_CLASSES. Of course, this means that those middlewares will not receive signature validation, and must therefore remain suspicious of the cookies' values. Another side-effect of the above action is that any cookies generated outside this middleware's control (e.g., prior to it in MIDDLEWARE_CLASSES) will be removed from request.COOKIES once this middleware is processed (note that this will not remove it from the client's browser, just from the HttpRequest instance). Therefore, any cookie-using middlewares processed before this one must store their cookies' values elsewhere if they are to be used by views. Thankfully, SessionMiddleware can safely be placed prior to SignedCookiesMiddleware in MIDDLEWARE_CLASSES, since it: - only stores an ID, which is already presumed safe enough, without signing - adds a separate session object to the request, so views don't need the session ID anyway - adds the session ID to the session object anyway, just in case a view wants to use it My recommendation, therefore (and yeah, this is probably all unnecessary anyway), is that SignedCookiesMiddleware be placed after SessionMiddleware, but before any others that use cookies. This will allow session cookies to avoid the 33-character overhead, while still protecting the rest of the cookie operations. I appreciate any feedback that can be offered, and I'd like to thank you all for giving me such a great framework to work with! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
