Middleware for using HttpOnly session cookie (including monkey patching for support for Python <2.6)
A middleware to set the httponly flag on the session cookie. Including monkey patching for support for Python <2.6.
- middleware
- sessions
- httponly
A middleware to set the httponly flag on the session cookie. Including monkey patching for support for Python <2.6.
I wasn't sure if my setup supported sessions properly. This view helped me make sure. Usage: fill the inputs with text and make sure that these values traverse a couple of requests. If it doesn't work then maybe the session backend you've set is broken?
This solves the problem of losing sessions data when you restart memcached. So you use a different memcached instance for sessions which you rarely restart. Use the above code and add the following to you settings.py SESSION_ENGINE = "kwippyproject.session_backend" SESSION_CACHE = 'memcached://127.0.0.1:11200/' (Above assumes that your session's memcached is running on port 11200) Feel free to contact me in case you need help. By [Dipankar sarkar](http://dipankar.name) [email protected]
This dead-simple piece of middleware adds a terrific security feature to django authentication. Currently, users who's accounts are de-activated still may have a cookie and a login session. This middleware destroys that session on their next request. Simply add this class into a middleware.py and add it to your settings.
This script is an adaptation from http://www.djangosnippets.org/snippets/678/ . Here, it doesnt use the cache middleware but relies on sessions. The script set a session cookie to identify the upload and track it to make it available for a progress bar like this one : http://www.djangosnippets.org/snippets/679/ . Note the progress bar cannot work with development server as it is single-threaded. Tested with apache/mod_python and mod_wsgi. any comments appreciated ;)
This middleware refreshes the session before it expires to avoid dropping the session of an active (but read-only) user. By default it refreshes the session after half the expiry time has elapsed. (This middleware does nothing for browser-length sessions.)
This was born as a result of the fact that session data is shared across logins on a single browser. If you login as user1 and session data is stored, then login as user2 the same session data will be available to your application. Please see the ticket who's validity is at this point in question. Some feel that this is normal behavior. http://code.djangoproject.com/ticket/6941 I use this code in conjunction with http://code.google.com/p/django-registration/ Place this code in registration.__init__ and change registration.urls to have login and logout route to the new alternate versions alt_login, alt_logout. I have only been using Python and Django for a couple months now so I hope that this implementation is not too terrible. It works for me. Enjoy.
7 snippets posted so far.