Re: [Django] Cookie-based session storage session invalidation issue

[Paul McMillan <paul () mcmillan ws>]

The technical properties of the feature (entirely client-side
sessions) require this behavior. As you rightly pointed out, this
brings with it some limitations, including the inability to
prematurely expire a session. This, and other properties of this
session backend are why it is not the default backend, and why there
are explicit warnings about it. Nevertheless, it is useful in some
deployment scenarios. I agree that the current even more explicit
warning is better.

You might want to include a recommendation for shorter session
timeouts in your blog post, since that works relatively well to combat
this problem in deployments which require client-side sessions.

On Thu, Oct 3, 2013 at 8:34 PM, G. S. McNamara <main () gsmcnamara com> wrote:
> Not sure why all the hostility.

You write a blog post, and post to FD, waving around a "newly
discovered vulnerability" that was a carefully and deliberately chosen
design decision made during the implementation of the feature.
Furthermore, you didn't have the decency to email the project security
alias to inquire about this until the day after posting about it
publicly. This is FD, so I'm not going to comment further on that
behavior, but perhaps you can imagine why your praises are not being
sung particularly loudly.

-Paul

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/