mirror of
https://github.com/django/django.git
synced 2024-12-24 18:16:19 +00:00
27efe14c54
git-svn-id: http://code.djangoproject.com/svn/django/trunk@1044 bcc190cf-cafb-0310-a4f2-bffc1f526a37
215 lines
7.3 KiB
Plaintext
215 lines
7.3 KiB
Plaintext
===================
|
|
How to use sessions
|
|
===================
|
|
|
|
Django provides full support for anonymous sessions. The session framework lets
|
|
you store and retrieve arbitrary data on a per-site-visitor basis. It stores
|
|
data on the server side and abstracts the sending and receiving of cookies.
|
|
Cookies contain a session ID -- not the data itself.
|
|
|
|
Enabling sessions
|
|
=================
|
|
|
|
Session functionality is enabled by default.
|
|
|
|
You can turn session functionality on and off by editing the
|
|
``MIDDLEWARE_CLASSES`` setting. To activate sessions, make sure
|
|
``MIDDLEWARE_CLASSES`` contains ``"django.middleware.sessions.SessionMiddleware"``.
|
|
|
|
If you're dealing with an admin site, make sure the ``SessionMiddleware`` line
|
|
appears before the ``AdminUserRequired`` line. (The middleware classes are
|
|
applied in order, and the admin middleware requires that the session middleware
|
|
come first.)
|
|
|
|
If you don't want to use sessions, you might as well remove the
|
|
``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES``. It'll save you a small
|
|
bit of overhead.
|
|
|
|
Using sessions in views
|
|
=======================
|
|
|
|
Each ``HttpRequest`` object -- the first argument to any Django view function --
|
|
has a ``session`` attribute, which is a dictionary-like object. You can read
|
|
it and write to it.
|
|
|
|
It implements the following standard dictionary methods:
|
|
|
|
* ``__getitem__(key)``
|
|
Example: ``fav_color = request.session['fav_color']``
|
|
|
|
* ``__setitem__(key, value)``
|
|
Example: ``request.session['fav_color'] = 'blue'``
|
|
|
|
* ``__delitem__(key)``
|
|
Example: ``del request.session['fav_color']``
|
|
|
|
* ``get(key, default=None)``
|
|
Example: ``fav_color = request.session.get('fav_color', 'red')``
|
|
|
|
It also has these three methods:
|
|
|
|
* ``set_test_cookie()``
|
|
Sets a test cookie to determine whether the user's browser supports
|
|
cookies. Due to the way cookies work, you won't be able to test this
|
|
until the user's next page request. See "Setting test cookies" below for
|
|
more information.
|
|
|
|
* ``test_cookie_worked()``
|
|
Returns either ``True`` or ``False``, depending on whether the user's
|
|
browser accepted the test cookie. Due to the way cookies work, you'll
|
|
have to call ``set_test_cookie()`` on a previous, separate page request.
|
|
See "Setting test cookies" below for more information.
|
|
|
|
* ``delete_test_cookie()``
|
|
Deletes the test cookie. Use this to clean up after yourself.
|
|
|
|
You can edit ``request.session`` at any point in your view. You can edit it
|
|
multiple times.
|
|
|
|
Session object guidelines
|
|
-------------------------
|
|
|
|
* Use normal Python strings as dictionary keys on ``request.session``. This
|
|
is more of a convention than a hard-and-fast rule.
|
|
|
|
* Session dictionary keys that begin with an underscore are reserved for
|
|
internal use by Django.
|
|
|
|
* Don't override ``request.session`` with a new object, and don't access or
|
|
set its attributes. Use it like a Python dictionary.
|
|
|
|
Examples
|
|
--------
|
|
|
|
This simplistic view sets a ``has_commented`` variable to ``True`` after a user
|
|
posts a comment. It doesn't let a user post a comment more than once::
|
|
|
|
def post_comment(request, new_comment):
|
|
if request.session.get('has_commented', False):
|
|
return HttpResponse("You've already commented.")
|
|
c = comments.Comment(comment=new_comment)
|
|
c.save()
|
|
request.session['has_commented'] = True
|
|
return HttpResponse('Thanks for your comment!')
|
|
|
|
This simplistic view logs a user in::
|
|
|
|
def login(request):
|
|
u = users.get_object(username__exact=request.POST['username'])
|
|
if u.check_password(request.POST['password']):
|
|
request.session['user_id'] = u.id
|
|
return HttpResponse("You're logged in.")
|
|
else:
|
|
return HttpResponse("Your username and password didn't match.")
|
|
|
|
...And this one logs a user out, according to ``login()`` above::
|
|
|
|
def logout(request):
|
|
try:
|
|
del request.session['user_id']
|
|
except KeyError:
|
|
pass
|
|
return HttpResponse("You're logged out.")
|
|
|
|
Setting test cookies
|
|
====================
|
|
|
|
As a convenience, Django provides an easy way to test whether the user's
|
|
browser accepts cookies. Just call ``request.session.set_test_cookie()`` in a
|
|
view, and call ``request.session.test_cookie_worked()`` in a subsequent view --
|
|
not in the same view call.
|
|
|
|
This awkward split between ``set_test_cookie()`` and ``test_cookie_worked()``
|
|
is necessary due to the way cookies work. When you set a cookie, you can't
|
|
actually tell whether a browser accepted it until the browser's next request.
|
|
|
|
It's good practice to use ``delete_test_cookie()`` to clean up after yourself.
|
|
Do this after you've verified that the test cookie worked.
|
|
|
|
Here's a typical usage example::
|
|
|
|
def login(request):
|
|
if request.POST:
|
|
if request.session.test_cookie_worked():
|
|
request.session.delete_test_cookie()
|
|
return HttpResponse("You're logged in.")
|
|
else:
|
|
return HttpResponse("Please enable cookies and try again.")
|
|
request.session.set_test_cookie()
|
|
return render_to_response('foo/login_form')
|
|
|
|
Using sessions out of views
|
|
===========================
|
|
|
|
Internally, each session is just a normal Django model. The ``Session`` model
|
|
is defined in ``django/models/core.py``. Because it's a normal model, you can
|
|
access sessions using the normal Django database API::
|
|
|
|
>>> from django.models.core import sessions
|
|
>>> s = sessions.get_object(pk='2b1189a188b44ad18c35e113ac6ceead')
|
|
>>> s.expire_date
|
|
datetime.datetime(2005, 8, 20, 13, 35, 12)
|
|
|
|
Note that you'll need to call ``get_decoded()`` to get the session dictionary.
|
|
This is necessary because the dictionary is stored in an encoded format::
|
|
|
|
>>> s.session_data
|
|
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
|
|
>>> s.get_decoded()
|
|
{'user_id': 42}
|
|
|
|
Session cookies
|
|
===============
|
|
|
|
A few `Django settings`_ give you control over the session cookie:
|
|
|
|
SESSION_COOKIE_AGE
|
|
------------------
|
|
|
|
Default: ``1209600`` (2 weeks, in seconds)
|
|
|
|
The age of session cookies, in seconds.
|
|
|
|
SESSION_COOKIE_DOMAIN
|
|
---------------------
|
|
|
|
Default: ``None``
|
|
|
|
The domain to use for session cookies. Set this to a string such as
|
|
``".lawrence.com"`` for cross-domain cookies, or use ``None`` for a standard
|
|
domain cookie.
|
|
|
|
SESSION_COOKIE_NAME
|
|
-------------------
|
|
|
|
Default: ``'hotclub'``
|
|
|
|
The name of the cookie to use for sessions. This can be whatever you want.
|
|
|
|
``'hotclub'`` is a reference to the Hot Club of France, the band Django
|
|
Reinhardt played in.
|
|
|
|
.. _Django settings: http://www.djangoproject.com/documentation/settings/
|
|
|
|
Technical details
|
|
=================
|
|
|
|
* The session dictionary should accept any pickleable Python object. See
|
|
`the pickle module`_ for more information.
|
|
|
|
* Session data is stored in a database table named ``core_sessions`` .
|
|
|
|
* Django only sends a cookie if it needs to. If you don't set any session
|
|
data, it won't send a session cookie.
|
|
|
|
.. _`the pickle module`: http://www.python.org/doc/current/lib/module-pickle.html
|
|
|
|
Session IDs in URLs
|
|
===================
|
|
|
|
The Django sessions framework is entirely, and solely, cookie-based. It does
|
|
not fall back to putting session IDs in URLs as a last resort, as PHP does.
|
|
This is an intentional design decision. Not only does that behavior make URLs
|
|
ugly, it makes your site vulnerable to session-ID theft via the "Referer"
|
|
header.
|