Учебники

Джанго — Сессии

Как обсуждалось ранее, мы можем использовать файлы cookie на стороне клиента для хранения большого количества полезных данных для веб-приложения. Ранее мы видели, что мы можем использовать файлы cookie на стороне клиента для хранения различных данных, полезных для нашего веб-приложения. Это приводит к множеству дыр в безопасности в зависимости от важности данных, которые вы хотите сохранить.

По соображениям безопасности в Django есть структура сеанса для обработки файлов cookie. Сеансы используются для абстрагирования приема и отправки файлов cookie, данные сохраняются на стороне сервера (как в базе данных), а файл cookie на стороне клиента просто имеет идентификатор сеанса для идентификации. Сессии также полезны, чтобы избежать случаев, когда браузер пользователя настроен на «не принимать» куки.

Настройка сессий

В Django включение сеанса выполняется в вашем проекте settings.py путем добавления нескольких строк в опции MIDDLEWARE_CLASSES и INSTALLED_APPS . Это должно быть сделано при создании проекта, но это всегда полезно знать, поэтому MIDDLEWARE_CLASSES должно иметь:

'django.contrib.sessions.middleware.SessionMiddleware'

И INSTALLED_APPS должен иметь —

'django.contrib.sessions'

По умолчанию Django сохраняет информацию о сеансе в базе данных (таблица или коллекция django_session), но вы можете настроить механизм для хранения информации, используя другие способы, такие как: в файле или в кэше .

Когда сеанс включен, каждый запрос (первый аргумент любого представления в Django) имеет атрибут сеанса (dict).

Давайте создадим простой пример, чтобы увидеть, как создавать и сохранять сеансы. Ранее мы создали простую систему входа в систему (см. Главу «Обработка форм в Django» и главу «Обработка cookie-файлов Django»). Давайте сохраним имя пользователя в файле cookie, чтобы при выходе из нашей страницы входа в систему вы не увидели форму входа. По сути, давайте сделаем нашу систему входа в систему, используемую в Django Cookies, более безопасной за счет сохранения куки-файлов на стороне сервера.

Для этого сначала давайте изменим наше представление входа в систему, чтобы сохранить нашу серверную часть имени пользователя cookie —

def login(request):
   username = 'not logged in'
   
   if request.method == 'POST':
      MyLoginForm = LoginForm(request.POST)
      
      if MyLoginForm.is_valid():
         username = MyLoginForm.cleaned_data['username']
         request.session['username'] = username
      else:
         MyLoginForm = LoginForm()
			
   return render(request, 'loggedin.html', {"username" : username}

Затем давайте создадим представление formView для формы входа в систему, где мы не будем отображать форму, если установлен cookie —

def formView(request):
   if request.session.has_key('username'):
      username = request.session['username']
      return render(request, 'loggedin.html', {"username" : username})
   else:
      return render(request, 'login.html', {})

Теперь давайте изменим файл url.py, чтобы изменить URL, чтобы он соответствовал нашему новому представлению —

from django.conf.urls import patterns, url
from django.views.generic import TemplateView

urlpatterns = patterns('myapp.views',
   url(r'^connection/','formView', name = 'loginform'),
   url(r'^login/', 'login', name = 'login'))

При доступе к / myapp / connection вы увидите следующую страницу —

Настройка сессий

И вы будете перенаправлены на следующую страницу —

Сессия перенаправленная страница

Теперь, если вы попытаетесь снова получить доступ к / myapp / connection, вы будете перенаправлены на второй экран напрямую.

Давайте создадим простое представление выхода из системы, которое стирает наши куки.

def logout(request):
   try:
      del request.session['username']
   except:
      pass
   return HttpResponse("<strong>You are logged out.</strong>")

И соедините его с URL для выхода из системы в myapp / url.py

url(r'^logout/', 'logout', name = 'logout'),

Теперь, если вы получите доступ к / myapp / logout, вы получите следующую страницу —

Страница выхода из системы

Если вы снова войдете в / myapp / connection, вы получите форму входа (экран 1).

Еще несколько возможных действий с использованием сессий

Мы видели, как хранить и получать доступ к сеансу, но хорошо знать, что атрибут сеанса запроса имеет некоторые другие полезные действия, такие как —

set_expiry ( значение ) — устанавливает время истечения сеанса.

get_expiry_age () — возвращает количество секунд до истечения этого сеанса.

get_expiry_date () — Возвращает дату окончания этой сессии.

clear_expired () — удаляет просроченные сеансы из хранилища сеансов.

get_expire_at_browser_close () — Возвращает либо True, либо False, в зависимости от того, истек ли срок действия файлов cookie сеанса пользователя при закрытии веб-браузера пользователя.