Description

Hello everyone

Firstly, there is an old ticket #1180 which was reopened by me today. The problem with current sessions is that there is a chance to get session duplicate 'by design' because there is a time between generating a new session id and checking it to be clean and actually save new session with this id to db. So, any django-powered project with high traffic.

newsessions is a fork of old sessions but it has completely different approach to the way of generating new sessions: it actually creates a new empty session with unique id in database and returns it so there is 100% guarantee that there will be no duplicates.

Also, there is another problem in sessions module: if any malicious user scans network traffic, there is a chance for him to get one's session id and successfully use it because django has no mechanisms to check for IP from where a session was created and from where it is actually used. Ofcourse, newsessions has no such problem because of built-in ip checking :)

newsession module uses other table than django_session so everyone who wants to try this module doesn't need to break anything. Everything you need is to change django.contrib.session.* to django.contrib.newsession.* in your settings.py

If the problem with (old)sessions is as you state, then definitely something needs to change.

I'm not quite sure about the session-IP tie, I think it came up a long time ago and the devs weren't sold on it. Either way, this is worth bringing up in the developer group for discussion. Here is a ​post to get things rolling.

SmileyChris, the reason why I called my stuff 'newsessions' is - they have different table structure which is not compatible with current session model. Use them or not - it's up to you guys, but as I said, your current model of sessions is vulnerable by default (it was designed to be vulnerable).