> You may be right about users screwing things up once in a while but > that's entirely unrelated to the fact that the sessions app expects > every backend to handle any (read: pickle-able) data you hand it. At > least that's the status quo on how every session backend I've seen > works.
Yeah. Dropping pickle would be a pretty major departure from the way the other session backends work. This backend already has several other properties that make it uniquely different: - ~4k character limit - limited enforcement of session destruction - transparency of session contents I wasn't sure if changing the "pickleable" feature might be an acceptable tradeoff. > So, long story short, I don't think you made a convincing argument > to me in proposing to ship a non-conforming session backend. Hence > I propose to instead promote the section about SECRET_KEY in the > session docs to a "big fat warning" and let the users decide how and > when they use it. That would be a good option. I need to apologize (particularly to Jannis who worked really hard to get this feature into core) that my original message sounded like nobody thought about this before they implemented it. It was discussed (and documented as part of the signing code). My primary concern here is the expanded reliance on SECRET_KEY for security. As a general principle, the less we rely on it directly for our security, the better. We currently use SECRET_KEY on a limited basis internally: - salt for random token generation - signing messages and sessions stored on disk - signing intermediate data in formtools - the signing framework (not used much internally yet) and salted_hmac - these cookies (which use the signing framework) As I said in the first message, to the best of my knowledge, there's nothing insecure about the implementation now. The usage of signing to validate pickles received directly by end users expands our reliance on SECRET_KEY pretty heavily. This concerns me, which is why I brought it up here. -Paul -- 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.
