| Остальное: права, группы, сообщения и профайлы | ||
|---|---|---|
| Пред. | Глава 12. Сессии, пользователи и регистрация | След. |
Кое-что о системе аутентификации и авторизации мы ещё не рассказали. Это время пришло.
Права являются простым способом наделения полномочиями пользователей и группы, разрешая им выполнять определённые действия. Права используются на сайте администратора Django, но вы легко сможете применять их и в своём коде.
Сайт администратора Django использует права так:
Доступ к форме для добавления пользователя. Эта операция разрешена пользователям, которые обладают правом добавления для этого типа объектов.
Доступ к списку изменений и к соответствующей форме. Операция внесения изменения разрешена пользователям, которые обладают правом изменения для этого типа объектов.
Операция удаления объекта разрешена пользователям, которые обладают правом удаления для этого типа объектов.
Права на тип объекта устанавливаются глобально, а не на каждый экземпляр класса. Например, можно сказать «Маша может изменять новости», но нельзя сказать «Маша может изменять новости, но только те, которые создала сама» или «Маша может изменять только те новости, которые имеют определённый статус, дату публикации и идентификатор».
Такие три основных права — добавление, изменение и удаления — автоматически создаются для каждой модели
Django, которая обладает классом
Admin. Эти права добавляются в таблицу
auth_permission в момент, когда вы запускаете
manage.py syncdb.
Формат определения прав —
<app>.<action>_<object_name>. Таким
образом, если у вас есть приложение polls с
моделью Choice, то вы будете
использовать права так: polls.add_choice,
polls.change_choice и
polls.delete_choice.
Следует отметить, что если ваша модель не имеет класса
Admin во время запуска
manage.py syncdb, эти права не будут
созданы. Если вы добавили класс Admin к
модели после создания базы данных, вам потребуется запустить
syncdb для обновления базы данных.
Вы также можете создать собственные права для определённой модели, используя атрибут permissions для Meta. Нижеприведённый пример модели создаёт три собственных права:
class USCitizen(models.Model):
# ...
class Meta:
permissions = (
# Идентификатор права Описание права
("can_drive", "Может водить"),
("can_vote", "Может голосовать на выборах"),
("can_drink", "Может пить алкоголь"),
)
Эти дополнительные права будут созданы только после выполнения команды syncdb, после этого можно проверить их работу в ваших представлениях.
Аналогично пользователям, права реализованы в виде модели, которая находится в django.contrib.auth.models. Это означает, что вы можете использовать API для работы с базой данных для прямого взаимодействия с необходимыми вам правами.
Группы являются базовым способом категоризации пользователей и могут быть использованы для назначения прав для этих групп. Пользователь может принадлежать любому количеству групп.
Пользователь, входящий в группу, автоматически получает права назначенные этой группе. Например, если группа «Редакторы сайта» обладает правом can_edit_home_page, любой пользователь входящий в эту группу, получает это право.
Группы также являются удобным способом для назначения пользователя некоторой расширенной функциональности. Например, вы можете создать группу «Особые пользователи» и затем написать код, который может давать доступ этим пользователям к закрытой части сайта, или отправлять им электронное сообщение.
Аналогично пользователям, простейшим способом управления группами является интерфейс администратора. Однако, группы также являются моделью Django, которая находится в django.contrib.auth.models, следовательно вы всегда можете использовать API для работы с базой данных для взаимодействия с группами на низком уровне.
Система сообщений — это простой способ организации
очереди сообщений для определённых пользователей. Сообщение
ассоциировано с классом User. Нет
никаких ограничение на время жизни сообщения.
Сообщения используются интерфейсом администратора Django после успешного выполнения действий. Например, при создании объекта вы получите сообщение «Объект успешно создан — The object was created successfully» на верху страницы.
Вы можете использовать этот API для организации очереди и вывода сообщений в вашем приложении. API прост:
Для создания нового сообщения используйте
user.message_set.create(message='message_text')Для получения и удаления сообщения используйте user.get_and_delete_messages(), которая возвращает список объектов
Messageиз пользовательской очереди (если такая есть) и удаляет сообщения из очереди.
В представлении, приведённом ниже, система сохраняет сообщение для пользователя после создания списка проигрывания:
def create_playlist(request, songs):
# Создаём список проигрывания с определёнными треками.
# ...
request.user.message_set.create(
message="Ваш список проигрывания был успешно добавлен."
)
return render_to_response("playlists/create.html",
context_instance=RequestContext(request))
При использовании RequestContext информация об авторизованном пользователе и его сообщениях становятся доступны для контекста шаблона в виде переменной {{ messages }}. Ниже показа пример кода шаблона, который отображает сообщения:
{% if messages %}
<ul>
{% for message in messages %}
<li>{{ message }}</li>
{% endfor %}
</ul>
{% endif %}
Следует отметить, что RequestContext вызывает
get_and_delete_messages(), таким образом
любое сообщение будет удалено, даже если вы не отобразили его.
Наконец, надо помнить, что среда обработки сообщений работает только с пользователями из пользовательской базы данных. Для того, чтобы отправить сообщения анонимным пользователям, следует напрямую использовать среду управления сессиями.
Последним элементом головоломки является система профайлов. Для того, чтобы понять, что такое профайл, следует рассмотреть такую задачу.
Множество сайтов нуждаются в хранении большего количество
информации, чем позволяет стандартный объект
User. Для решения этой задачи такие
сайты имеют разные «дополнительные» поля. Таким
образом, Django предоставляет простой способ определения
объекта «профайл», который подключен к
пользователю. Этот объект может меняться от проекта к проекту
и даже может управлять различными профайлами для разных
сайтов, работающих с использованием одной базы данных.
Первым шагом для создания профайла будет определение модели, которая будет хранить информацию профайла. Единственное требование Django к такой модели — она должна иметь
уникальный ForeignKey к модели
User. Это поле должно иметь имя
user. Кроме данного поля вы можете добавлять
любые необходимые вам поля. Ниже представлена крайне
произвольная модель профайла:
from django.db import models
from django.contrib.auth.models import User
class MySiteProfile(models.Model):
# This is the only required field
user = models.ForeignKey(User, unique=True)
# The rest is completely up to you...
favorite_band = models.CharField(max_length=100, blank=True)
favorite_cheese = models.CharField(max_length=100, blank=True)
lucky_number = models.IntegerField()
Затем потребуется, чтобы вы указали Django где искать этот объект. Это делается с помощью параметра AUTH_PROFILE_MODULE, надо вписать в него идентификатор вашей модели. Таким образом, если ваша модель определена в приложении myapp, то вам потребуется сделать следующее:
AUTH_PROFILE_MODULE = "myapp.mysiteprofile"
После этого вы можете получить доступ к профайлу пользователя с помощью user.get_profile(). Эта функция может вызвать исключение SiteProfileNotAvailable, если параметр AUTH_PROFILE_MODULE не определён; или исключение DoesNotExist, если пользователь ещё не имеет профайла (обычно такие исключения перехватывают и на лету создают новый профайл).
| Пред. | Уровень выше | След. |
| Аутентификация пользователей | Начало | Глава 13. Кэширование |
0 комментариев | Оставьте комментарий