3 ms·
I'm not sure what this has to do with the focus of the book, Django has session support so I doubt a book about Django would fully cover re-writing one of its c
by jonknee 14y ago
I'm not sure what this has to do with the focus of the book, Django has session support so I doubt a book about Django would fully cover re-writing one of its components. Django used to only be able to store nothing in the session cookie other than the ID so that part can definitely happen (new in Django 1.4 are Cookie Based Sessions that used signed cookies to store data in cookies, but it's something you have to turn on).
This is all fully documented, if you're curious you should read it.
https://docs.djangoproject.com/en/1.5/topics/http/sessions/ https://docs.djangoproject.com/en/1.5/topics/http/sessions/
As for tying into OpenId or other similar systems, it's a piece of cake. There are numerous Django apps out there to accomplish it. I have used django-social-auth for a project and had no problems getting things running:
https://github.com/omab/django-social-auth https://github.com/omab/django-social-auth
- lifeisstillgood 14y agoA brief read of the sessions docs throws up three concerns 1. Stuffing a lot into a session cookie (the term can easily exceed he 4096 bytes limit suggests that this is not designed just to store session ids) 2. There is implication of one site secret key - a flaw in Flask which it's dangerous was supposed to fix - but even so there is the implication the MAC check guarantees No one has played with the cookie. This is flat eke bread and butter breaking those 3. It still is making the base assumption that the developer can willingly stick whatever he likes in a python duct and have that magically comeback from the client untouched - of that seems to be so. Just I prefer having caching problems on my server than never knowing if the information from the cookie can be trusted
- jonknee 14y agoYes, 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