In light of the upcoming feature completion deadline for Django 1.1, I'd like to take a few minutes to mention where the signed cookies application stands right now and some of my thoughts about its inclusion in django.contrib. The code itself is done. I made a few minor updates to it last week to encourage people to use it as a decorator if they don't need the full middleware, rather than providing a separate utils package that would be too easy to accidentally get things wrong. I think it's in as polished a state it can be short of adding some major new feature I'm currently unaware of.
That said, there's still one major concern: security. The whole point is to try to guarantee that users can't tamper with their cookies and use them on the site, so security's of primary concern. Unfortunately, I'm not a security expert. The app was born from a comment Simon Willison made on djangobook.com during the initial review phase, mentioning that he uses an MD5 hash to sign cookies for OpenID authentication without hitting the database. I basically just took that description and made a middleware to do the job transparently. However, Simon's been active on Twitter recently, questioning the security of various hash digest algorithms, specifically with regard to signing cookies. Again, I'm no security expert, but from what I've read, MD5 is pretty much at the bottom of the barrel in terms of sheer security, so I have definite concerns here. Simon, if you're listening, what have you found out with regard to recommendations on hashing algorithms? The app can very easily be altered to use a different algorithm, but with greater security comes greater hash lengths. And since cookies are already limited in length by browsers, longer hashes present a serious threat to the real-world usefulness of the app. If being completely secure means only short values can be stored in cookies, I'm not sure anybody would call it a worthwhile endeavor. Perhaps most importantly, I just read over Jacob's recent post about what it takes to be a contrib app, and I feel the signed cookies app fails on two out of three points. It's certainly optional, which is the only one it gets right. But even though I believe mine to be the only Django-based signed cookies application, there are WSGI middleware projects available as well that do the same job without relying on Django at all, so I think it fails the "de facto standard" test. The approach taken by the app is (I believe) a best practice, but the app itself hasn't proven itself as the preferred way to do it. But it's the other failure that concerns me most: it's hardly a common pattern. Perhaps it would be more common if included in Django proper, but it seems like nearly every time I mention the app, I get little more response than a flurry of questions along the lines of, "but when would you actually want to sign your cookies?" If the majority of people can't even find reasons to sign their cookies at all, there's little hope of it becoming a common pattern anytime soon. So, I'm all for improving the app as much as I possibly can, and I'll definitely continue to make it available, but unless it gets a major boost in both security and popularity in the next few days, I don't think it's prudent to include it in django.contrib. If others disagree, I'll be glad to make the minor changes necessary to make it a proper contrib app and submit it for review, but I personally don't think it's the best idea at the moment. I'd much rather revisit it in a future release once it's proven itself a bit better. -Gul --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
