Cookie Sessions for Django v0.1 documentation
Install it from the Python Package Index
easy_install cookiesession
Comment out, or delete django.contrib.sessions.middleware.SessionMiddleware from settings.py’s MIDDLEWARE_CLASSES setting.
Add cookiesession’s middleware to your settings.py MIDDLEWARE_CLASSES
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
#'django.contrib.sessions.middleware.SessionMiddleware',
'cookiesessions.middleware.CookieSessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
)
Optional. In order to use the management commands you need to add cookiesession to settings.py’s INSTALLED_APPS
In settings.py (or local_settings.py) set SESSION_COOKIE_DOMAIN, SESSION_COOKIE_NAME, or SESSION_COOKIE_PATH as necessary (see the Django session docs for more info).
Developers will want to override the SESSION_COOKIE_DOMAIN with 127.0.0.1 and access their local development server as http://127.0.0.1:8000/
Cookies are inherently insecure and can’t be trusted. Users have access to the values and can do what ever they want with them. So how could you ever put important data in a cookie?
There’s a difference between “important” and “secret”. Django only stores two pieces of data about the user in the session cookie: the user’s id and the authentication backend used for authentication. Neither of these bits of information are “secret” in that knowing them can lead to security breaches. They are “important” in that we need them to retrieve the user’s information.
However with cookies, a user could easily modify the user id stored in the cookie and suddenly be a different user. That means we need a way to detect a modification to the cookie.
The process is pretty straight forward:
When the user has logged in and makes a new request, we reverse the steps to verify the cookie hasn’t been tampered with: