Объект ModelForm

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

Простейший способ построения форм в Django основан на использовании класса ModelForm, который автоматически строит форму на основании моделей, определенных в главе 18. Ваша первая форма будет создана в файле forms.py, который должен находиться в одном каталоге с models.py:

forms.py

from django import forms

from .models import Topic

(1) class TopicForm(forms.ModelForm):

. .class Meta:

(2) . . . .model = Topic

(3) . . . .fields = ['text']

(4) . . . .labels = {'text': ''}

Сначала импортируется модуль forms и модель, с которой мы будем работать: Topic. В точке (1) определяется класс с именем TopicForm, наследующий от forms.ModelForm. Простейшая версия ModelForm состоит из вложенного класса Meta, который сообщает Django, на какой модели должна базироваться форма и какие поля на ней должны находиться. В точке (2) форма создается на базе модели Topic, а на ней размещается только поле text (3). Код (4) приказывает Django не генерировать ­подпись для текстового поля.

 

URL-адрес для new_topic

URL-адрес новой страницы должен быть простым и содержательным, поэтому после того, как пользователь выбрал команду создания новой темы, он направляется по адресу http://localhost:8000/new_topic/. Ниже приведена схема URL для страницы new_topic, которая добавляется в learning_logs/urls.py:

urls.py

...

urlpatterns = [

...

. .# Страница для добавления новой темы

. .url(r'^new_topic/$', views.new_topic, name='new_topic'),

]

Эта схема URL будет отправлять запросы функции представления new_topic(), которую мы сейчас напишем.

 

Запросы GET и POST

При построении веб-приложений используются два основных типа запросов — GET и POST. Запросы GET используются для страниц, которые только читают данные с сервера, а запросы POST обычно используются в тех случаях, когда пользователь должен отправить информацию через форму. Для обработки всех наших форм будет использоваться метод POST (существуют и другие разновидности запросов, но в нашем проекте они не используются).

Функция new_topic() получает в параметре объект запроса. Когда пользователь впервые запрашивает эту страницу, его браузер отправляет запрос GET. Когда пользователь уже заполнил и отправил форму, его браузер отправляет запрос POST. В зависимости от типа запроса мы определяем, запросил ли пользователь пустую форму (запрос GET) или предлагает обработать заполненную форму (запрос POST).

Метод запроса — GET или POST — проверяется в точке (1) . Если метод запроса отличен от POST, вероятно, используется запрос GET, поэтому необходимо вернуть пустую форму (даже если это запрос другого типа, это все равно безопасно). Мы создаем экземпляр TopicForm (2), сохраняем его в переменной form и отправляем форму шаблону в словаре context ?. Так как при создании TopicForm аргументы не передавались, Django создает пустую форму, которая заполняется пользователем.

Если используется метод запроса POST, выполняется блок else, который ­обрабатывает данные, отправленные в форме. Мы создаем экземпляр TopicForm (3) и передаем ему данные, введенные пользователем, хранящиеся в request.POST. Возвращаемый объект form содержит информацию, отправленную пользователем.

Отправленную информацию нельзя сохранять в базе данных до тех пор, пока она не будет проверена (4). Функция is_valid() проверяет, что все обязательные поля были заполнены (все поля формы по умолчанию являются обязательными), а введенные данные соответствуют типам полей — например, что длина текста меньше 200 символов, как было указано в файле models.py в главе 18. Автоматическая проверка избавляет нас от большого объема работы. Если все данные действительны, можно вызвать метод save() (5), который записывает данные из формы в базу данных. После того как данные будут сохранены, страницу можно покинуть. Мы используем вызов reverse() для получения URL-адреса страницы topics и передаем его функции HttpResponseRedirect() ?, перенаправляющей браузер пользователя на страницу topics. На этой странице пользователь видит только что введенную им тему в общем списке тем.

 

Шаблон new_topic

Теперь создадим новый шаблон с именем new_topic.html для отображения только что созданной формы:

new_topic.html

{% extends "learning_logs/base.html" %}

{% block content %}

Add a new topic:

(1)

(2) . .{% csrf_token %}

(3) . .{{ form.as_p }}

(4) . .add topic

. .

{% endblock content %}

Этот шаблон расширяет base.html, поэтому он имеет такую же базовую структуру, как и остальные страницы Learning Log. В точке (1) определяется форма HTML. Аргумент action сообщает серверу, куда передавать данные, отправленные формой; в данном случае данные возвращаются функции представления new_topic(). Аргумент method приказывает браузеру отправить данные в запросе типа POST.

Django использует шаблонный тег {% csrf_token %} (2) для предотвращения попыток получения несанкционированного доступа к серверу (атаки такого рода называются межсайтовой подделкой запросов). В точке (3) отображается форма; это наглядный пример того, насколько легко в Django выполняются такие стандартные операции, как отображение формы. Чтобы автоматически создать все поля, необходимые для отображения формы, достаточно включить шаблонную переменную {{ form.as_p }}. Модификатор as_p приказывает Django отобразить все элементы формы в формате абзацев — это простой способ аккуратного ­отображения формы.

Django не создает кнопку отправки данных для форм, поэтому мы определяем ее в точке (4).

 

Создание ссылки на страницу new_topic

Далее ссылка на страницу new_topic создается на странице topics:

topics.html

{% extends "learning_logs/base.html" %}

{% block content %}

Topics

...

Add a new topic:

{% endblock content %}

Разместите ссылку после списка существующих тем. Полученная форма изображена на рис. 19.1. Воспользуйтесь ею и добавьте несколько своих тем.

Рис. 19.1. Страница для добавления новой темы

 

Класс EntryForm

Мы должны создать форму, связанную с моделью Entry, но более специализированную по сравнению с TopicForm:

forms.py

from django import forms

from .models import Topic, Entry

class TopicForm(forms.ModelForm):

...

class EntryForm(forms.ModelForm):

. .class Meta:

. . . .model = Entry

. . . .fields = ['text']

(1) . . . .labels = {'text': ''}

(2) . . . .widgets = {'text': forms.Textarea(attrs={'cols': 80})}

Сначала в команду import к Topic добавляется Entry. Новый класс EntryForm наследует от forms.ModelForm и содержит вложенный класс Meta с указанием модели, на которой он базируется, и поле, включаемое в форму. Полю 'text' снова назначается пустая надпись (1) .

В точке (2) включается атрибут widgets. Виджет (widget) представляет собой элемент формы HTML: однострочное или многострочное текстовое поле, раскрывающийся список и т.д. Включая атрибут widgets, вы можете переопределить виджеты, выбранные Django по умолчанию. Приказывая Django использовать элемент forms.Textarea, мы настраиваем виджет ввода для поля 'text', чтобы ширина текстовой области составляла 80 столбцов вместо значения по умолчанию 40. У пользователя будет достаточно места для создания содержательных записей.

 

URL-адрес для new_entry

Необходимо включить аргумент topic_id в URL-адрес для создания новой записи, потому что запись должна ассоциироваться с конкретной темой. Вот как выглядит URL, который мы добавляем в learning_logs/urls.py:

urls.py

...

urlpatterns = [

...

. .# Страница для добавления новой записи

. .url(r'^new_entry/(?P\d+)/$', views.new_entry, name='new_entry'),

]

Эта схема URL соответствует любому URL-адресу в форме http://localhost:8000/new_entry/id/, где id — число, равное идентификатору темы. Выражение (?P\d+) захватывает числовое значение и сохраняет его в переменной topic_id. При запросе URL-адреса, соответствующего этой схеме, Django передает запрос и идентификатор темы функции представления new_entry().

 

Функция представления new_entry()

Функция представления new_entry очень похожа на функцию добавления новой темы:

views.py

from django.shortcuts import render

...

from .models import Topic

from .forms import TopicForm, EntryForm

...

def new_entry(request, topic_id):

. ."""Добавляет новую запись по конкретной теме."""

(1) . .topic = Topic.objects.get(id=topic_id)

. .

(2) . .if request.method != 'POST':

. . . .# Данные не отправлялись; создается пустая форма.

(3) . . . .form = EntryForm() . . . .

. .else:

. . . .# Отправлены данные POST; обработать данные.

(4) . . . .form = EntryForm(data=request.POST)

. . . .if form.is_valid():

(5) . . . . . .new_entry = form.save(commit=False)

? . . . . . .new_entry.topic = topic

. . . . . .new_entry.save()

? . . . . . .return HttpResponseRedirect(reverse('learning_logs:topic',

. . . . . . . . . . . . . . . . . . . .args=[topic_id]))

. .

. .context = {'topic': topic, 'form': form}

. .return render(request, 'learning_logs/new_entry.html', context)

Мы обновляем команду import и включаем в нее только что созданный класс EntryForm. Определение new_entry() содержит параметр topic_id для сохранения полученного значения из URL. Идентификатор темы понадобится для отображения страницы и обработки данных формы, поэтому мы используем topic_id для получения правильного объекта темы (1) .

В точке (2) проверяется метод запроса: POST или GET. Блок if выполняется для запроса GET, и мы создаем пустой экземпляр EntryForm (3). Для метода запроса POST мы обрабатываем данные, создавая экземпляр EntryForm, заполненный данными POST из объекта запроса (4). Затем проверяется корректность данных формы. Если данные корректны, необходимо задать атрибут topic объекта записи перед сохранением его в базе данных.

При вызове save() мы включаем аргумент commit=False (5) для того, чтобы создать новый объект записи и сохранить его в new_entry, не сохраняя пока в базе данных. Мы присваиваем атрибуту topic объекта new_entry тему, прочитанную из базы данных в начале функции ?, после чего вызываем save() без аргументов. В результате запись сохраняется в базе данных с правильной ассоциированной темой.

В точке ? пользователь перенаправляется на страницу темы. При вызове reverse() должны передаваться два аргумента: имя схемы URL, для которой генерируется URL-адрес, и список аргументов со всеми аргументами, которые должны быть включены в URL. Список аргументов содержит всего один элемент topic_id. Вызов HttpResponseRedirect() перенаправляет пользователя на страницу темы, для которой была создана запись, и пользователь видит новую запись в списке записей.

 

Шаблон new_entry

Как видно из следующего кода, шаблон new_entry похож на шаблон new_topic:

new_entry.html

{% extends "learning_logs/base.html" %}

{% block content %}

(1)

{{ topic }}

. .

Add a new entry:

(2)

. .{% csrf_token %}

. .{{ form.as_p }}

. .add entry

. .

{% endblock content %}

В начале страницы выводится тема (1) , чтобы пользователь мог видеть, в какую тему добавляется новая запись. Тема также служат ссылкой для возврата к основной странице этой темы.

Аргумент action формы включает значение topic_id из URL, чтобы функция ­представления могла связать новую запись с правильной темой (2). В остальном этот шаблон почти не отличается от new_topic.html.

 

Создание ссылки на страницу new_entry

Затем необходимо создать ссылку на страницу new_entry на каждой странице темы:

topic.html

{% extends "learning_logs/base.html" %}

{% block content %}

Topic: {{ topic }}

Entries:

. .add new entry

...

{% endblock content %}

Ссылка добавляется перед выводом записей, потому что добавление новой записи является самым частым действием на этой странице. На рис. 19.2 изображена страница new_entry. Теперь пользователь может добавить сколько угодно новых тем и новых записей по каждой теме. Опробуйте страницу new_entry, добавив несколько записей для каждой из созданных вами тем.

Рис. 19.2. Страница new_entry

 

URL-адрес для edit_entry

В URL-адресе страницы должен передаваться идентификатор редактируемой ­записи. В файл learning_logs/urls.py для этого вносятся следующие изменения:

urls.py

...

urlpatterns = [

...

. .# Страница для редактирования записи

. .url(r'^edit_entry/(?P\d+)/$', views.edit_entry,

. . . .name='edit_entry'),

]

Идентификатор, переданный в URL (например, http://localhost:8000/edit_entry/1/), сохраняется в параметре entry_id. Схема The URL отправляет запросы, соответствующие этому формату, функции представления edit_entry().

 

Функция представления edit_entry()

Когда страница edit_entry получает запрос GET, edit_entry() возвращает форму для редактирования записи. При получении запроса POST с отредактированной записью страница сохраняет измененный текст в базе данных:

views.py

from django.shortcuts import render

...

from .models import Topic, Entry

from .forms import TopicForm, EntryForm

...

def edit_entry(request, entry_id):

. ."""Редактирует существующую запись."""

(1) . .entry = Entry.objects.get(id=entry_id)

. .topic = entry.topic

. .

. .if request.method != 'POST':

. . . .# Исходный запрос; форма заполняется данными текущей записи.

(2) . . . .form = EntryForm(instance=entry)

. .else:

. . . .# Отправка данных POST; обработать данные.

(3) . . . .form = EntryForm(instance=entry, data=request.POST)

. . . .if form.is_valid():

(4) . . . . . .form.save()

(5) . . . . . .return HttpResponseRedirect(reverse('learning_logs:topic',

. . . . . . . . . . . . . . . . . . . .args=[topic.id]))

. .

. .context = {'entry': entry, 'topic': topic, 'form': form}

. .return render(request, 'learning_logs/edit_entry.html', context)

Сначала необходимо импортировать модель Entry. В точке (1) мы получаем объект записи, который пользователь хочет изменить, и тему, связанную с этой записью. В блоке if, который выполняется для запроса GET, создается экземпляр EntryForm с аргументом instance=entry (2). Этот аргумент приказывает Django создать форму, заранее заполненную информацией из существующего объекта записи. Пользователь видит свои существующие данные и может отредактировать их.

При обработке запроса POST передаются аргументы instance=entry и data=request.POST (3), чтобы приказать Django создать экземпляр формы на основании информации существующего объекта записи, обновленный данными из request.POST. Затем проверяется корректность данных формы. Если данные корректны, следует вызов save() без аргументов (4). Далее происходит перенаправление на страницу темы (5), и пользователь видит обновленную версию отредактированной им записи.

 

Шаблон edit_entry

Шаблон edit_entry.html очень похож на new_entry.html:

edit_entry.html

{% extends "learning_logs/base.html" %}

{% block content %}

{{ topic }}

. .

Edit entry:

. .

(1)

. .{% csrf_token %}

. .{{ form.as_p }}

(2) . .save changes

{% endblock content %}

В точке (1) аргумент action отправляет форму функции edit_entry() для обработки. Идентификатор записи включается как аргумент в тег {% url %} , чтобы функция представления могла изменить правильный объект записи. Кнопка отправки данных создается с текстом, который напоминает пользователю, что он сохраняет изменения, а не создает новую запись (2).

 

Создание ссылки на страницу edit_entry

Теперь необходимо включить ссылку на страницу edit_entry в каждую тему на странице со списком тем:

topic.html

...

{% for entry in entries %}

{{ entry.date_added|date:'M d, Y H:i' }}

{{ entry.text|linebreaks }}

. .

. . . .edit entry

. .

...

После даты и текста каждой записи включается ссылка редактирования. Мы используем шаблонный тег {% url %} для определения схемы URL из именованной схемы edit_entry и идентификатора текущей записи в цикле (entry.id). Текст ссылки "edit entry" выводится после каждой записи на странице. На рис. 19.3 показано, как выглядит страница со списком тем с этими ссылками.

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

Рис. 19.3. Каждая запись снабжается ссылкой для редактирования этой записи

­регистрации пользователей, чтобы любой желающий мог создать свою учетную запись в Learning Log и ввести собственный набор тем и записей.

Упражнения

19-1. Блог: создайте новый проект Django с именем Blog. Создайте в проекте приложение с именем blogs и моделью BlogPost. Модель должна содержать такие поля, как title, text и date_added. Создайте суперпользователя для проекта и воспользуйтесь административным сайтом для создания пары коротких сообщений. Создайте домашнюю страницу, на ­которой выводятся все сообщения в хронологическом порядке.

Создайте одну форму для создания новых сообщений и другую форму для редактирования существующих сообщений. Заполните формы и убедитесь в том, что они работают.

 

Добавление пользователей в settings.py

Новое приложение необходимо добавить в settings.py:

settings.py

...

INSTALLED_APPS = (

...

# My apps

'learning_logs',

. .'users',

)

...

Django включает приложение users в общий проект.

 

Включение URL-адресов из users

Затем необходимо изменить корневой файл urls.py, чтобы он включал URL-адреса, написанные для приложения users:

urls.py

from django.conf.urls import include, url

from django.contrib import admin

urlpatterns = [

url(r'^admin/', include(admin.site.urls)),

. .url(r'^users/', include('users.urls', namespace='users')),

url(r'', include('learning_logs.urls', namespace='learning_logs')),

]

Добавим строку для включения файла urls.py из users. Эта строка будет соответствовать любому URL-адресу, начинающемуся со слова users, — например, http://localhost:8000/users/login/. Также будет создано пространство имен 'users', чтобы мы могли отличать URL-адреса, принадлежащие приложению learning_logs, от URL, принадлежащих приложению users.

 

Шаблон login

Когда пользователь запрашивает страницу входа, Django использует свое представление login по умолчанию, но мы все равно должны предоставить шаблон для этой страницы. В каталоге learning_log/users/ создайте каталог с именем templates, а внутри него — еще один каталог с именем users. Вот как выглядит шаблон login.html, который должен находиться в learning_log/users/templates/users/:

login.html

{% extends "learning_logs/base.html" %}

{% block content %}

(1) {% if form.errors %}

Your username and password didn't match. Please try again.

{% endif %}

. .

(2)

{% csrf_token %}

(3) {{ form.as_p }}

. .

(4) log in

(5)

. .

{% endblock content %}

Шаблон расширяет base.html, чтобы страница входа по оформлению и поведению была похожа на другие страницы сайта. Обратите внимание: шаблон в одном приложении может расширять шаблон из другого приложения.

Если у формы установлен атрибут errors, выводится сообщение об ошибке (1) . В нем говорится, что комбинация имени пользователя и пароля не соответствует информации, хранящейся в базе данных.

Мы хотим, чтобы представление обработало форму, поэтому аргументу action присваивается URL страницы входа (2). Представление отправляет форму шаблону, мы должны вывести форму (3) и добавить кнопку отправки данных (4). В точке (5) включается скрытый элемент формы 'next'; аргумент value сообщает Django, куда перенаправить пользователя после успешно выполненного входа. В нашем случае пользователь возвращается обратно на домашнюю страницу.

 

Создание ссылки на страницу входа

Добавим ссылку на страницу входа в base.html, чтобы она присутствовала на каждой странице. Ссылка не должна отображаться, если пользователь уже прошел процедуру входа, поэтому она вкладывается в тег {% if %}:

base.html

Learning Log -

Topics -

(1) {% if user.is_authenticated %}

(2) . .Hello, {{ user.username }}.

{% else %}

(3) . .log in

{% endif %}

{% block content %}{% endblock content %}

В системе аутентификации Django в каждом шаблоне доступна переменная user, в которой всегда присутствует атрибут is_authenticated: атрибут равен True, если пользователь прошел проверку, и False в противном случае. Это позволяет вам выводить разные сообщения для проверенных и непроверенных пользователей.

В данном случае мы выводим приветствие для пользователей, выполнивших вход. У проверенных пользователей устанавливается дополнительный атрибут username, который обеспечит личную настройку приветствия и напомнит пользователю о том, что вход был выполнен. В точке (3) выводится ссылка на страницу входа для пользователей, которые еще не прошли проверку.

 

Использование страницы входа

Учетная запись пользователя уже создана; попробуем ввести данные и посмотрим, работает ли страница. Откройте страницу http://localhost:8000/admin/. Если вы все еще работаете с правами администратора, найдите ссылку выхода в заголовке и щелкните на ней.

После выхода перейдите по адресу http://localhost:8000/users/login/. На экране должна появиться страница входа, похожая на рис. 19.4. Введите имя пользователя и пароль, заданные ранее, и вы снова должны оказаться на странице со списком.

Рис. 19.4. Страница входа

В заголовке страницы должно выводиться сообщение с указанием имени пользователя.

 

Выход

Теперь необходимо предоставить пользователям возможность выхода из приложения. Мы не будем строить отдельную страницу для выхода; пользователь просто щелкает на ссылке и возвращается к домашней странице. Мы определяем схему URL для ссылки выхода, пишем функцию представления и предоставляем ссылку выхода в base.html.

 

URL-адрес выхода

Следующий код определяет схему URL для выхода, соответствующую URL http://localhost:8000/users/logout/. Файл users/urls.py выглядит так:

urls.py

...

urlpatterns = [

# Страница входа

...

. .# Страница выхода

. .url(r'^logout/$', views.logout_view, name='logout'),

]

Схема URL отправляет запрос функции logout_view(), имя которой выбрано так, чтобы оно отличалось от имени функции logout(), вызываемой из представления. (Проследите за тем, чтобы изменения вносились в файл users/urls.py, а не в файл learning_log/urls.py.)

 

Функция представления logout_view()

Функция logout_view() тривиальна: мы просто импортируем функцию Django logout(), вызываем ее, а затем возвращаем пользователя на домашнюю страницу. Откройте файл users/views.py и введите следующий код:

views.py

from django.http import HttpResponseRedirect

from django.core.urlresolvers import reverse

(1) from django.contrib.auth import logout

def logout_view(request):

. ."""Завершает сеанс работы с приложением."""

(2) . .logout(request)

(3) . .return HttpResponseRedirect(reverse('learning_logs:index'))

Мы импортируем функцию logout() из django.contrib.auth (1) . В функции вызывается функция logout() (2), в аргументе которой должен передаваться объект запроса. Затем происходит возврат к домашней странице (3).

 

Ссылка на представление выхода

Теперь нужно создать ссылку для выхода. Мы включим ее в base.html, чтобы она была доступна на каждой странице, и включим в секцию {% if user.is_authenticated %}, чтобы ссылка была видна только пользователям, уже выполнившим вход:

base.html

...

{% if user.is_authenticated %}

Hello, {{ user.username }}.

. .log out

{% else %}

log in

{% endif %}

...

На рис. 19.5 изображена текущая домашняя страница так, как ее видит пользователь, выполнивший вход. Оформление страницы минимально, потому что сейчас нас в первую очередь интересует работа сайта. Когда необходимые функции заработают, можно переходить к стилевому оформлению сайта и приданию ему более профессионального вида.

Рис. 19.5. Домашняя страница с персональным приветствием и ссылкой для выхода

 

URL-адрес регистрации

Следующий код предоставляет шаблон URL для страницы регистрации — также в файле users/urls.py:

urls.py

...

urlpatterns = [

# Страница входа

...

. .# Страница регистрации

. .url(r'^register/$', views.register, name='register'),

]

Шаблон соответствует URL http://localhost:8000/users/register/ и отправляет запросы функции register(), которую мы сейчас напишем.

 

Функция представления register()

Функция представления register() должна вывести пустую форму регистрации при первом запросе страницы регистрации, а затем обрабатывает заполненную форму регистрации при отправке данных. Если регистрация прошла успешно, функция также должна выполнить вход для нового пользователя. Включите следующий код в users/views.py:

views.py

from django.shortcuts import render

from django.http import HttpResponseRedirect

from django.core.urlresolvers import reverse

from django.contrib.auth import login, logout, authenticate

from django.contrib.auth.forms import UserCreationForm

def logout_view(request):

...

def register(request):

. ."""Регистрирует нового пользователя."""

. .if request.method != 'POST':

. . . .# Display blank registration form.

(1) . . . .form = UserCreationForm()

. .else:

. . . .# Обработка заполненной формы.

(2) . . . .form = UserCreationForm(data=request.POST)

. . . .

(3) . . . .if form.is_valid():

(4) . . . . . .new_user = form.save()

. . . . . .# Выполнение входа и перенаправление на домашнюю страницу.

(5) . . . . . .authenticated_user = authenticate(username=new_user.username,

. . . . . . . .password=request.POST['password1'])

? . . . . . .login(request, authenticated_user)

? . . . . . .return HttpResponseRedirect(reverse('learning_logs:index'))

. .context = {'form': form}

. .return render(request, 'users/register.html', context)

Сначала импортируется функция render(), после чего импортируются функции login() и authenticate() для выполнения входа пользователя, если регистрационная информация верна. Также импортируется класс UserCreationForm по умол­чанию. В функции register() мы проверяем, отвечает ли функция на запрос POST. Если нет, создается экземпляр UserCreationForm, не содержащий исходных данных (1) . В случае ответа на запрос POST создается экземпляр UserCreationForm, основанный на отправленных данных (2). Мы проверяем, что данные верны (3); в данном случае что имя пользователя содержит правильные символы, пароли совпадают, а пользователь не пытается вставить вредоносные конструкции в отправленные данные.

Если отправленные данные верны, мы вызываем метод save() формы для сохранения имени пользователя и хеша пароля в базе данных (4). Метод save() возвращает только что созданный объект пользователя, который сохраняется в new_user.

После того как информация пользователя будет сохранена, мы выполняем вход; этот процесс состоит из двух шагов: сначала вызывается функция authenticate() с аргументом new_user.username и паролем (5). При регистрации пользователю предлагается ввести два совпадающих пароля; поскольку данные формы верны, мы знаем, что пароли совпадают, и можем использовать любой из них. В данном случае используется значение, связанное с ключом 'password1' в данных POST формы. Если имя пользователя и пароль верны, метод возвращает проверенный объект пользователя, который сохраняется в authenticated_user. Затем вызывается функция login() с объектами request и authenticated_user ?, которая создает действительный сеанс для нового пользователя.

Наконец, пользователь перенаправляется на домашнюю страницу ?, где приветствие в заголовке сообщает о том, что регистрация прошла успешно.

 

Шаблон регистрации

Шаблон страницы регистрации похож на шаблон страницы входа. Проследите за тем, чтобы он был сохранен в одном каталоге с login.html:

register.html

{% extends "learning_logs/base.html" %}

{% block content %}

. .{% csrf_token %}

. .{{ form.as_p }}

. . . .

. .register

. .

. .

{% endblock content %}

Мы снова используем метод as_p, чтобы инфраструктура Django могла правильно отобразить все поля формы, включая все сообщения об ошибках, если форма была заполнена неправильно.

 

Создание ссылки на страницу регистрации

Следующий шаг — добавление кода для вывода ссылки на страницу регистрации для любого пользователя, еще не выполнившего вход:

base.html

...

{% if user.is_authenticated %}

Hello, {{ user.username }}.

log out

{% else %}

. .register -

log in

{% endif %}

...

Теперь пользователи, выполнившие вход, получат персональное приветствие и ссылку для выхода. Другие пользователи видят ссылку на страницу регистрации и ссылку для входа. Проверьте страницу регистрации, создав несколько учетных записей с разными именами пользователей.

В следующем разделе доступ к некоторым страницам будет ограничен, чтобы страницы были доступны только для зарегистрированных пользователей. Также необходимо позаботиться о том, чтобы каждая тема принадлежала конкретному пользователю.

Примечание

Такая система регистрации позволяет любому пользователю создать сколько угодно учетных записей Learning Log. Однако некоторые системы требуют, чтобы пользователь подтвердил свою заявку, отправляя сообщение электронной почты, на которое пользователь должен ответить. При ­таком подходе в системе будет создано меньше спамерских учетных записей, чем в простейшей системе из нашего примера. Но пока вы только учитесь строить приложения, вполне нормально тренироваться на упрощенной системе регистрации вроде используемой нами.

Упражнения

19-2. Учетные записи в блоге: добавьте систему аутентификации и регистрации в проект Blog, работа над которым началась в упражнении 19-1 (с. 419). Проследите за тем, чтобы пользователь, выполнивший вход, видел свое имя где-то на экране, а незарегистрированные пользователи видели ссылку на страницу регистрации.

 

Ограничение доступа к страницам тем

Каждая тема будет принадлежать пользователю, поэтому только зарегистрированные пользователи смогут запрашивать страницы тем. Добавьте следующий код в learning_logs/views.py:

views.py

...

from django.core.urlresolvers import reverse

from django.contrib.auth.decorators import login_required

from .models import Topic, Entry

...

@login_required

def topics(request):

"""Выводит все темы."""

...

Сначала импортируется функция login_required(). Мы применяем login_required() как декоратор для функции представления topics(), для чего перед именем login_required() ставится знак @; он сообщает Python, что этот код должен выполняться перед кодом topics().

Код login_required() проверяет, выполнил ли пользователь вход, и Django выполняет код topics() только при выполнении этого условия. Если же пользователь не выполнил вход, он перенаправляется на страницу входа.

Чтобы перенаправление работало, необходимо внести изменения settings.py и сообщить Django, где искать страницу входа. Добавьте следующий фрагмент в самый конец settings.py:

settings.py

"""

Django settings for learning_log project

...

# Мои настройки

LOGIN_URL = '/users/login/'

Когда пользователь, не прошедший проверку, запрашивает страницу, защищенную декоратором @login_required, Django отправляет пользователя на URL-адрес, определяемый LOGIN_URL в settings.py.

Чтобы протестировать эту возможность, завершите сеанс в любой из своих учетных записей и вернитесь на домашнюю страницу. Щелкните на ссылке Topics, которая должна направить вас на страницу входа. Выполните вход с любой из своих учетных записей, на домашней странице снова щелкните на ссылке Topics. На этот раз вы получите доступ к странице со списком тем.

 

Ограничение доступа в Learning Log

Django упрощает ограничение доступа к страницам, но вы должны решить, какие страницы следует защищать. Лучше сначала подумать, к каким страницам можно разрешить неограниченный доступ, а затем ограничить его для всех остальных страниц. Снять излишние ограничения несложно, причем это куда менее рискованно, чем оставлять действительно важные страницы без ограничения доступа.

В приложении Learning Log мы оставим неограниченный доступ к домашней странице, странице регистрации и выхода. Доступ ко всем остальным страницам будет ограничен.

Вот как выглядит файл learning_logs/views.py с декораторами @login_required, примененными к каждому представлению, кроме index():

views.py

...

@login_required

def topics(request):

. ....

@login_required

def topic(request, topic_id):

. ....

@login_required

def new_topic(request):

. ....

. .

@login_required

def new_entry(request, topic_id):

. ....

@login_required

def edit_entry(request, entry_id):

. ....

Попробуйте обратиться к любой из этих страниц без выполнения входа: вы будете перенаправлены обратно на страницу входа. Кроме того, вы не сможете щелкать на ссылках на такие страницы, как new_topic. Но если ввести URL http://localhost:8000/new_topic/, вы будете перенаправлены на страницу входа. Ограничьте доступ ко всем ­URL-адресам, связанным с личными данными пользователей.

 

Изменение модели Topic

В файле models.py изменяются всего две строки:

models.py

from django.db import models

from django.contrib.auth.models import User

class Topic(models.Model):

"""Тема, которую изучает пользователь"""

text = models.CharField(max_length=200)

date_added = models.DateTimeField(auto_now_add=True)

. .owner = models.ForeignKey(User)

def __str__(self):

"""Возвращает строковое представление модели."""

return self.text

class Entry(models.Model):

...

Сначала модель User импортируется из django.contrib.auth. Затем в Topic добавляется поле owner, используемое в отношении внешнего ключа с моделью User.

 

Идентификация существующих пользователей

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

Просмотрим идентификаторы всех пользователей, созданных до настоящего момента. Запустите сеанс оболочки Django и введите следующие команды:

(venv)learning_log$ python manage.py shell

(1) >>> from django.contrib.auth.models import User

(2)>>> User.objects.all()

[, , ]

(3)>>> for user in User.objects.all():

... . . print(user.username, user.id)

...

ll_admin 1

eric 2

willie 3

>>>

В точке (1) в сеанс оболочки импортируется модель User. После этого просматриваются все пользователи, созданные до настоящего момента (2). В выходных данных перечислены три пользователя: ll_admin, eric и willie.

В точке (3) перебирается список пользователей, и для каждого пользователя выводится его имя и идентификатор. Когда Django спросит, с каким пользователем связать существующие темы, мы используем один из этих идентификаторов.

 

Миграция базы данных

Зная значение идентификатора, можно провести миграцию базы данных.

(1) (venv)learning_log$ python manage.py makemigrations learning_logs

(2)You are trying to add a non-nullable field 'owner' to topic without a default;

we can't do that (the database needs something to populate existing rows).

(3)Please select a fix:

1) Provide a one-off default now (will be set on all existing rows)

2) Quit, and let me add a default in models.py

(4)Select an option: 1

(5)Please enter the default value now, as valid Python

The datetime and django.utils.timezone modules are available, so you can do

e.g. timezone.now()

? >>> 1

Migrations for 'learning_logs':

0003_topic_owner.py:

. .- Add field owner to topic

Сначала выдается команда makemigrations (1) . В ее выходных данных (2) Django сообщает, что мы пытаемся добавить обязательное поле (значения которого отличны от null) в существующую модель (topic) без указания значения по умолчанию. Django предоставляет два варианта (3): мы можем либо указать значение по умолчанию прямо сейчас, либо завершить выполнение программы и добавить значение по умолчанию в models.py. В точке (4) выбирается первый вариант. Тогда Django запрашивает значение по умолчанию (5).

Чтобы связать все существующие темы с исходным административным пользователем ll_admin, я ввел в точке ? идентификатор пользователя 1. Вы можете использовать идентификатор любого из созданных пользователей; он не обязан быть суперпользователем. Django проводит миграцию базы данных, используя это значение, и создает файл миграции 0003_topic_owner.py, добавляющий поле owner в модель Topic.

Теперь можно провести миграцию. Введите следующую команду в активной виртуальной среде:

(venv)learning_log$ python manage.py migrate

Operations to perform:

Synchronize unmigrated apps: messages, staticfiles

Apply all migrations: learning_logs, contenttypes, sessions, admin, auth

...

Running migrations:

Rendering model states... DONE

(1) Applying learning_logs.0003_topic_owner... OK

(venv)learning_log$

Django применяет новую миграцию с результатом OK (1) . Чтобы убедиться в том, что миграция сработала так, как и ожидалось, можно воспользоваться интерактивной оболочкой:

(1) >>> from learning_logs.models import Topic

(2)>>> for topic in Topic.objects.all():

... . . print(topic, topic.owner)

...

Chess ll_admin

Rock Climbing ll_admin

>>>

После импортирования Topic из learning_logs.models (1) мы перебираем все существующие темы, выводим каждую тему и имя пользователя, которому она принадлежит (2). Как видите, сейчас каждая тема принадлежит пользователю ll_admin.

Примечание

Вместо миграции можно просто сбросить содержимое базы данных, но это приведет к потере всех существующих данных. Полезно научиться выполнять миграцию базы данных без нарушения целостности данных пользователей. Если вы хотите начать с новой базы данных, используйте команду python manage.py flush для повторного построения структуры базы данных. Вам придется создать нового суперпользователя, а все данные будут потеряны.