Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&reporter=PaulM&order=priority
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=!closed&reporter=PaulM&order=priority
Trac 1.0.7https://code.djangoproject.com/ticket/16859
https://code.djangoproject.com/ticket/16859#16859: CSRF ImprovementsThu, 15 Sep 2011 22:40:20 GMTPaulM<p>
This is a ticket to keep track of general CSRF improvements we want to add to Django.
</p>
<p>
This includes:
</p>
<ul><li><a class="assigned ticket" href="https://code.djangoproject.com/ticket/16010" title="New feature: Support Origin header checking in the CSRF middleware (assigned)">#16010</a> - add Origin checking
</li><li>Optionally tie CSRF to sessions
</li><li>Use signing to improve CSRF (maybe with sessions)
</li><li>Improve domain/host checking - deal with the subdomain to subdomain problem
</li></ul>Resultshttps://code.djangoproject.com/ticket/16859#changeloghttps://code.djangoproject.com/ticket/17975
https://code.djangoproject.com/ticket/17975#17975: Make sessions more robustSun, 25 Mar 2012 01:15:18 GMTPaulM<p>
In <a class="closed ticket" href="https://code.djangoproject.com/ticket/17810" title="Bug: Switching from cookie-based sessions to memcached-based sessions ... (closed: fixed)">#17810</a>, we fixed a specific problem where an invalid session cookie could result in a server error. Since this has the effect of locking a user out of an application permanently (the site just appears broken) until they clear their cookies, this is pretty undesirable.
</p>
<p>
This ticket is to improve and expand that protection. We should change the contract around sessions to be more robust. I suggest something along the lines of "if there is any kind of error during any operation related to a session, we log the problem and push a brand new session to the user."
</p>
<p>
This will mean that cases where an invalid session can exist (as in the previous ticket by an overly long session key, or one could imagine situations with broken pickled session data) don't wedge the user experience. We should (carefully) extend the protection added there to cover sessions more generally, including session creation, deletion, and access, across all backends. This will, of course, need to be balanced with providing useful error messages to developers.
</p>
Resultshttps://code.djangoproject.com/ticket/17975#changelog