3 ms·
Yes, if you change the defaults and don't read the docs it is possible to get in trouble.
by jonknee 14y ago
Yes, if you change the defaults and don't read the docs it is possible to get in trouble.
- lifeisstillgood 14y agoThat seems disingenuous - a read of the docs indicates to me that the default is to store a lot of app specific info on an encrypted cookie - what is stored on that cookie? Admin rights? Total credit in dollars? Discount codes? That's app specific but if the implication is its trustable then a lot of attack vectors just opened up. who chooses the encryption? Is a new key generated per user / session? If so how is that stored and looked up? Any lookup drops the secure vs speedy trade off and so you need not store anything in the session cookie Yes it is possible to make a app insecure - we do it all the time. My question is how to generically and sensibly reduce the attack surface - you know, best practises. I just do not see the trade off of "encrypt everything onto a cookie and use that instead of cache lookups" as one I am willing to take - but I would like to know if I am in a minority, if there is evidence backing either side etc Edit: this appears to have been typed out of my bottom - the parents has pointed out the clearly marked defaults for django that meet seemingly most or all of my concerns above - but I cannot reply just yet (not sure why it might be a enforced Cooling off period) so this is the best way to say mea culpa
- jonknee 14y agohttps://docs.djangoproject.com/en/1.5/topics/http/sessions/ https://docs.djangoproject.com/en/1.5/topics/http/sessions/ > "By default, Django stores sessions in your database"
- lifeisstillgood 14y agoPlease see above edit - and thanks for pointing out the same thing three times till I actually processed it