Django полностью поддерживает сессии для анонимных пользователей, позволяет сохранять и получать данные для каждой посетителя сайта. Механизм сессии сохраняет данные на сервере и самостоятельно управляет сессионными куками. Куки содержат ID сессии,а не сами данные (если только вы не используете бэкенд на основе кук).
Сессии реализованы через промежуточный слой.
Чтобы активировать сессии, выполните следующие действия:
Убедитесь что MIDDLEWARE_CLASSES содержит 'django.contrib.sessions.middleware.SessionMiddleware'. settings.py по умолчанию, созданный django-admin startproject, уже содержит SessionMiddleware.
Есди вы не собираетесь использовать сессии, вы можете удалить SessionMiddleware из MIDDLEWARE_CLASSES и 'django.contrib.sessions' из INSTALLED_APPS. Это немного повысит производительность.
По умолчанию Django хранит сессии в базе данных (используя модель django.contrib.sessions.models.Session). В некоторых случаях лучше хранить данные сессии в других хранилищах, по этому Django позволяет использовать файловую систему или кэш.
Если вы хотите использовать базу данных для хранения сесиии, укажите 'django.contrib.sessions' в настройке INSTALLED_APPS.
После настройки выполните manage.py migrate, чтобы добавить таблицу в базу данных.
Для улучшения производительности вы можете использовать кэш для хранения сессии.
Для этого вы должны настроить кэш, смотрите раздел о кэше.
Предупреждение
Вам следует использовать кэш только при использовании Memcached. Кэш в памяти не хранит данные достаточно долго, и лучше использовать файлы или базу данных для сессии, чем каждый раз обращаться к кэшу в файловой системе или базе данных. Также кэш в памяти использует различные экземпляры кэша для разных процессов.
Если вы указали несколько кэшей в CACHES, Django будет использовать кэш по умолчанию. Чтобы использовать другой кэш, укажите его название в SESSION_CACHE_ALIAS.
После настройки кэша у вас есть две опции, как хранить данные в кэше:
Указать "django.contrib.sessions.backends.cache" в SESSION_ENGINE. Данные сессии будут храниться непосредственно в кэше. Однако, данные могут быть удалены при переполнении кэша или перезагрузке сервера кэша.
Для постоянно хранения закэшированных данных укажите "django.contrib.sessions.backends.cached_db" в SESSION_ENGINE. Все записи в кэш будут продублированы в базу данных. База данных будет использоваться, если данные не найдены в кэше.
Оба варианта работают достаточно быстро, но первый немного быстрее. Для большинства случаев cached_db будет достаточно быстрым, но если производительность для вас важнее, чем надежное хранение сессии, используйте бэкенд cache.
Если вы используете cached_db, вам необходимо настроить и бэкенд базы данных.
Чтобы использовать файловую систему, укажите "django.contrib.sessions.backends.file" в SESSION_ENGINE.
Вы также можете указать SESSION_FILE_PATH (по умолчанию tempfile.gettempdir(), обычно это /tmp), чтобы указать Django, где сохранять сессионные файлы. Убедитесь, что ваш сервер имеет права на чтение и запись указанного каталога.
Чтобы хранить сессию в куках, укажите "django.contrib.sessions.backends.signed_cookies" в SESSION_ENGINE. Данные сессии будут сохранены в куках, используя криптографическую подпись и значение SECRET_KEY.
Примечание
Рекомендуем указать True в SESSION_COOKIE_HTTPONLY, чтобы запретить доступ JavaScript к кукам.
Предупреждение
Если SECRET_KEY не хранить в безопасности при использовании PickleSerializer, можно пострадать от атаки удаленного выполнения кода.
Злоумышленник, узнав SECRET_KEY, может не только подделать данные сессии, но и выполнить удаленный код т.к. данные сессии используют pickle.
Если вы храните сессию в куках, храните ваш секретный ключ максимально надежно для всех систем, которые используются пользователем.
Сессионные данные подписаны, но не закодированы
Клиент может прочитать данные сессии, если вы храните их в куках.
MAC (Message Authentication Code) используется для защиты данных от подделки пользователем. Данные будут недействительными, если пользователь попытается их поменять. Аналогичное происходит, если клиент, который хранит коки (например, браузер пользователя), не может сохранить сессионную куку и удаляет её. Несмотря на то , что Django сжимает данные, вполне возможно превысить принятый лимит 4096 байтов на куку.
Актуальность не гарантируется
Обратите внимание, хотя MAC может гарантировать авторизацию данных (что они были созданы вашим сайтом, а не кем-то другим), и целостность данных (данные не менялись и правильны), он не может гарантировать актуальность, то есть, что полученные данные последние, которые вы отсылали клиенту. Это означает, что при определенном использовании кук для сессии, ваш сайт может быть подвержен replay атакам. В отличии от других бэкендов сессии, которые хранят данные на сервере и очищают их при выходе пользователя(log out), сессия в куках не очищается, когда пользователь выходит. По этому, если атакующий украдет куки пользователя, он может использовать их для входа даже после того, как пользователь вышел с сайта. Куки будут определены как устаревшие, если только они старее чем SESSION_COOKIE_AGE.
Производительность
Наконец, размер кук может повлиять на производительность вашего сайта.
Когда SessionMiddleware активный, каждый объект HttpRequest – первый аргумент представления в Django – будет содержать атрибут session, который является объектом с интерфейсом словаря.
Вы можете читать и менять request.session в любом месте вашего представления множество раз.
Это базовый класс для всех объектов сессии. Он предоставляет набор стандартных методов словаря:
Например: fav_color = request.session['fav_color']
Например: request.session['fav_color'] = 'blue'
Например: del request.session['fav_color']. Вызовет KeyError, если key еще не в сессии.
Например: 'fav_color' in request.session
Например: fav_color = request.session.get('fav_color', 'red')
Example: fav_color = request.session.pop('fav_color', 'blue')
Также содержит следующие методы:
Deletes the current session data from the session and deletes the session cookie. This is used if you want to ensure that the previous session data can’t be accessed again from the user’s browser (for example, the django.contrib.auth.logout() function calls it).
Удаление сессионной куки было добавлено в Django 1.8. Ранее значение сессионной куки менялось и отправлялось пользователю в куках.
Устанавливает тестовую куку, чтобы проверить, что браузер пользователя поддерживает куки. Из-за особенностей работы кук вы не сможете проверить тестовую куку, пока пользователь не запросит следующую страницу. Подробности смотрите ниже(FIXME).
Возвращает True или False, в зависимости от того, принял ли бразуер пользователя тестовую куку. Из-за особенностей работы кук вам необходимо вызывать в предыдущем запросе set_test_cookie(). Подробности смотрите ниже(FIXME).
Удаляет тестовую куку. Используйте, чтобы убрать за собой.
Указывает время жизни сессии. Вы можете передать различные значения:
Если value целое число, сессия истечет после указанного количества секунд не активности пользователя. Например, request.session.set_expiry(300) установит время жизни равное 5 минутам.
Если value это datetime или timedelta, сессия истечет в указанное время. Обратите внимание, datetime и timedelta сериализуются только при использовании PickleSerializer.
Если value равно 0, сессионная кука удалится при закрытии браузера.
Если value равно None, сессия будет использовать глобальное поведение.
Чтение сессии не обновляет время жизни сессии. Время жизни просчитывается с момента последнего изменения.
Returns the number of seconds until this session expires. For sessions with no custom expiration (or those set to expire at browser close), this will equal SESSION_COOKIE_AGE.
This function accepts two optional keyword arguments:
Returns the date this session will expire. For sessions with no custom expiration (or those set to expire at browser close), this will equal the date SESSION_COOKIE_AGE seconds from now.
This function accepts the same keyword arguments as get_expiry_age().
Returns either True or False, depending on whether the user’s session cookie will expire when the user’s Web browser is closed.
Removes expired sessions from the session store. This class method is called by clearsessions.
Creates a new session key while retaining the current session data. django.contrib.auth.login() calls this method to mitigate against session fixation.
By default, Django serializes session data using JSON. You can use the SESSION_SERIALIZER setting to customize the session serialization format. Even with the caveats described in Write Your Own Serializer, we highly recommend sticking with JSON serialization especially if you are using the cookie backend.
For example, here’s an attack scenario if you use pickle to serialize session data. If you’re using the signed cookie session backend and SECRET_KEY is known by an attacker (there isn’t an inherent vulnerability in Django that would cause it to leak), the attacker could insert a string into their session which, when unpickled, executes arbitrary code on the server. The technique for doing so is simple and easily available on the internet. Although the cookie session storage signs the cookie-stored data to prevent tampering, a SECRET_KEY leak immediately escalates to a remote code execution vulnerability.
A wrapper around the JSON serializer from django.core.signing. Can only serialize basic data types.
In addition, as JSON supports only string keys, note that using non-string keys in request.session won’t work as expected:
>>> # initial assignment
>>> request.session[0] = 'bar'
>>> # subsequent requests following serialization & deserialization
>>> # of session data
>>> request.session[0] # KeyError
>>> request.session['0']
'bar'
See the Write Your Own Serializer section for more details on limitations of JSON serialization.
Supports arbitrary Python objects, but, as described above, can lead to a remote code execution vulnerability if SECRET_KEY becomes known by an attacker.
Note that unlike PickleSerializer, the JSONSerializer cannot handle arbitrary Python data types. As is often the case, there is a trade-off between convenience and security. If you wish to store more advanced data types including datetime and Decimal in JSON backed sessions, you will need to write a custom serializer (or convert such values to a JSON serializable object before storing them in request.session). While serializing these values is fairly straightforward (django.core.serializers.json.DateTimeAwareJSONEncoder may be helpful), writing a decoder that can reliably get back the same thing that you put in is more fragile. For example, you run the risk of returning a datetime that was actually a string that just happened to be in the same format chosen for datetimes).
Your serializer class must implement two methods, dumps(self, obj) and loads(self, data), to serialize and deserialize the dictionary of session data, respectively.
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 in a “member” of the site:
def login(request):
m = Member.objects.get(username=request.POST['username'])
if m.password == request.POST['password']:
request.session['member_id'] = m.id
return HttpResponse("You're logged in.")
else:
return HttpResponse("Your username and password didn't match.")
...And this one logs a member out, according to login() above:
def logout(request):
try:
del request.session['member_id']
except KeyError:
pass
return HttpResponse("You're logged out.")
The standard django.contrib.auth.logout() function actually does a bit more than this to prevent inadvertent data leakage. It calls the flush() method of request.session. We are using this example as a demonstration of how to work with session objects, not as a full logout() implementation.
As a convenience, Django provides an easy way to test whether the user’s browser accepts cookies. Just call the set_test_cookie() method of request.session in a view, and call 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.method == '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.html')
Примечание
The examples in this section import the SessionStore object directly from the django.contrib.sessions.backends.db backend. In your own code, you should consider importing SessionStore from the session engine designated by SESSION_ENGINE, as below:
>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
An API is available to manipulate session data outside of a view:
>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore()
>>> # stored as seconds since epoch since datetimes are not serializable in JSON.
>>> s['last_login'] = 1376587691
>>> s.save()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
>>> s['last_login']
1376587691
In order to mitigate session fixation attacks, sessions keys that don’t exist are regenerated:
>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore(session_key='no-such-session-here')
>>> s.save()
>>> s.session_key
'ff882814010ccbc3c870523934fee5a2'
If you’re using the django.contrib.sessions.backends.db backend, each session is just a normal Django model. The Session model is defined in django/contrib/sessions/models.py. Because it’s a normal model, you can access sessions using the normal Django database API:
>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get(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}
By default, Django only saves to the session database when the session has been modified – that is if any of its dictionary values have been assigned or deleted:
# Session is modified.
request.session['foo'] = 'bar'
# Session is modified.
del request.session['foo']
# Session is modified.
request.session['foo'] = {}
# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session['foo']['bar'] = 'baz'
In the last case of the above example, we can tell the session object explicitly that it has been modified by setting the modified attribute on the session object:
request.session.modified = True
To change this default behavior, set the SESSION_SAVE_EVERY_REQUEST setting to True. When set to True, Django will save the session to the database on every single request.
Note that the session cookie is only sent when a session has been created or modified. If SESSION_SAVE_EVERY_REQUEST is True, the session cookie will be sent on every request.
Similarly, the expires part of a session cookie is updated each time the session cookie is sent.
The session is not saved if the response’s status code is 500.
You can control whether the session framework uses browser-length sessions vs. persistent sessions with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
By default, SESSION_EXPIRE_AT_BROWSER_CLOSE is set to False, which means session cookies will be stored in users’ browsers for as long as SESSION_COOKIE_AGE. Use this if you don’t want people to have to log in every time they open a browser.
If SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True, Django will use browser-length cookies – cookies that expire as soon as the user closes their browser. Use this if you want people to have to log in every time they open a browser.
This setting is a global default and can be overwritten at a per-session level by explicitly calling the set_expiry() method of request.session as described above in `using sessions in views`_.
Примечание
Some browsers (Chrome, for example) provide settings that allow users to continue browsing sessions after closing and re-opening the browser. In some cases, this can interfere with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting and prevent sessions from expiring on browser close. Please be aware of this while testing Django applications which have the SESSION_EXPIRE_AT_BROWSER_CLOSE setting enabled.
As users create new sessions on your website, session data can accumulate in your session store. If you’re using the database backend, the django_session database table will grow. If you’re using the file backend, your temporary directory will contain an increasing number of files.
To understand this problem, consider what happens with the database backend. When a user logs in, Django adds a row to the django_session database table. Django updates this row each time the session data changes. If the user logs out manually, Django deletes the row. But if the user does not log out, the row never gets deleted. A similar process happens with the file backend.
Django does not provide automatic purging of expired sessions. Therefore, it’s your job to purge expired sessions on a regular basis. Django provides a clean-up management command for this purpose: clearsessions. It’s recommended to call this command on a regular basis, for example as a daily cron job.
Note that the cache backend isn’t vulnerable to this problem, because caches automatically delete stale data. Neither is the cookie backend, because the session data is stored by the users’ browsers.
A few Django settings give you control over session behavior:
Subdomains within a site are able to set cookies on the client for the whole domain. This makes session fixation possible if cookies are permitted from subdomains not controlled by trusted users.
For example, an attacker could log into good.example.com and get a valid session for their account. If the attacker has control over bad.example.com, they can use it to send their session key to you since a subdomain is permitted to set cookies on *.example.com. When you visit good.example.com, you’ll be logged in as the attacker and might inadvertently enter your sensitive personal data (e.g. credit card info) into the attackers account.
Another possible attack would be if good.example.com sets its SESSION_COOKIE_DOMAIN to ".example.com" which would cause session cookies from that site to be sent to bad.example.com.
When working with sessions internally, Django uses a session store object from the corresponding session engine. By convention, the session store object class is named SessionStore and is located in the module designated by SESSION_ENGINE.
All SessionStore classes available in Django inherit from SessionBase and implement data manipulation methods, namely:
In order to build a custom session engine or to customize an existing one, you may create a new class inheriting from SessionBase or any other existing SessionStore class.
Extending most of the session engines is quite straightforward, but doing so with database-backed session engines generally requires some extra effort (see the next section for details).
Creating a custom database-backed session engine built upon those included in Django (namely db and cached_db) may be done by inheriting AbstractBaseSession and either SessionStore class.
AbstractBaseSession and BaseSessionManager are importable from django.contrib.sessions.base_session so that they can be imported without including django.contrib.sessions in INSTALLED_APPS.
The abstract base session model.
Primary key. The field itself may contain up to 40 characters. The current implementation generates a 32-character string (a random sequence of digits and lowercase ASCII letters).
A string containing an encoded and serialized session dictionary.
A datetime designating when the session expires.
Expired sessions are not available to a user, however, they may still be stored in the database until the clearsessions management command is run.
Returns a session store class to be used with this session model.
Returns decoded session data.
Decoding is performed by the session store class.
You can also customize the model manager by subclassing BaseSessionManager:
Returns the given session dictionary serialized and encoded as a string.
Encoding is performed by the session store class tied to a model class.
Saves session data for a provided session key, or deletes the session in case the data is empty.
Customization of SessionStore classes is achieved by overriding methods and properties described below:
Implements database-backed session store.
Override this method to return a custom session model if you need one.
Returns a new instance of the session model object, which represents the current session state.
Overriding this method provides the ability to modify session model data before it’s saved to database.
Implements cached database-backed session store.
A prefix added to a session key to build a cache key string.
The example below shows a custom database-backed session engine that includes an additional database column to store an account ID (thus providing an option to query the database for all active sessions for an account):
from django.contrib.sessions.backends.db import SessionStore as DBStore
from django.contrib.sessions.base_session import AbstractBaseSession
from django.db import models
class CustomSession(AbstractBaseSession):
account_id = models.IntegerField(null=True, db_index=True)
class Meta:
app_label = 'mysessions'
@classmethod
def get_session_store_class(cls):
return SessionStore
class SessionStore(DBStore):
@classmethod
def get_model_class(cls):
return CustomSession
def create_model_instance(self, data):
obj = super(SessionStore, self).create_model_instance(data)
try:
account_id = int(data.get('_auth_user_id'))
except (ValueError, TypeError):
account_id = None
obj.account_id = account_id
return obj
If you are migrating from the Django’s built-in cached_db session store to a custom one based on cached_db, you should override the cache key prefix in order to prevent a namespace clash:
class SessionStore(CachedDBStore):
cache_key_prefix = 'mysessions.custom_cached_db_backend'
# ...
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.
Mar 31, 2016