Documentation
contrib packages¶
admin ¶
Requires the auth and contenttypes contrib packages to be installed.
Django’s authentication framework.
contenttypes ¶
A light framework for hooking into “types” of content, where each installed Django model is a separate content type.
flatpages ¶
A framework for managing “flat” HTML content in a database.
Requires the sites contrib package to be installed as well.
A world-class geospatial framework built on top of Django, that enables storage, manipulation and display of spatial data.
See the GeoDjango documentation for more.
humanize ¶
A set of Django template filters useful for adding a “human touch” to data.
messages ¶
A framework for storing and retrieving temporary cookie- or session-based messages
postgres ¶
A collection of PostgreSQL specific features.
redirects ¶
A framework for managing redirects.
sessions ¶
A framework for storing data in anonymous sessions.
sites ¶
A light framework that lets you operate multiple websites off of the same database and Django installation. It gives you hooks for associating objects to one or more sites.
sitemaps ¶
A framework for generating Google sitemap XML files.
syndication ¶
A framework for generating syndication feeds, in RSS and Atom, quite easily.
Other add-ons¶
Additional Information
Support Django!
Contents
Browse
You are here:
Getting help
Download:
Offline (Django 3.2): HTML | PDF | ePub
Provided by Read the Docs.
django.contrib.auth ¶
User модель¶
Объекты User имеют следующие поля:
Необязательно ( blank=True ). Не более 150 символов.
Размер max_length увеличился с 30 до 150 символов.
Необязательно ( blank=True ). Не более 150 символов.
Необязательно ( blank=True ). Адрес электронной почты.
Отношения «многие-ко-многим» к Group
Отношения «многие-ко-многим» к Permission
Булево. Определяет, может ли этот пользователь получить доступ к сайту администратора.
Булево. Указывает, следует ли считать эту учетную запись пользователя активной. Мы рекомендуем установить этот флаг в False вместо удаления учетных записей; таким образом, если в ваших приложениях есть внешние ключи к пользователям, внешние ключи не сломаются.
Булево. Обозначает, что данный пользователь имеет все разрешения без их явного назначения.
Время последнего входа пользователя в систему.
Время, обозначающее дату создания учетной записи. По умолчанию устанавливается в текущую дату/время при создании счета.
Атрибуты¶
Методы¶
Возвращает имя пользователя для данного пользователя. Поскольку модель User может быть заменена, следует использовать этот метод вместо прямого обращения к атрибуту username.
Это может понадобиться, если аутентификация для вашего приложения происходит по существующему внешнему источнику, такому как каталог LDAP.
get_user_permissions ( obj = None )¶
Возвращает набор строк разрешений, которые есть непосредственно у пользователя.
get_group_permissions ( obj = None )¶
Возвращает набор строк разрешений, которыми обладает пользователь через свои группы.
get_all_permissions ( obj = None )¶
Возвращает набор строк разрешений, которые имеет данный пользователь, как через групповые, так и через пользовательские разрешения.
Методы менеджера¶
Модель User имеет пользовательский менеджер, который имеет следующие вспомогательные методы (в дополнение к методам, предоставляемым BaseUserManager ):
Возвращает пользователей, имеющих данное разрешение perm либо в формате » label>.
Если include_superusers равно True (по умолчанию), результат будет включать суперпользователей.
AnonymousUser объект¶
Permission модель¶
Объекты Permission имеют следующие поля:
class models. Permission name ¶
Методы¶
Group модель¶
Объекты Group имеют следующие поля:
class models. Group name ¶
Поле «многие-ко-многим» к Permission :
Валидаторы¶
class validators. UnicodeUsernameValidator ¶
Сигналы входа и выхода из системы¶
Отправляется при успешном входе пользователя в систему.
Аргументы, передаваемые с этим сигналом:
Отправляется при вызове метода выхода из системы.
Отправляется, когда пользователь не смог успешно войти в систему
Бэкенды аутентификации¶
Доступные бэкенды аутентификации¶
Базовый класс, который предоставляет реализацию по умолчанию для всех необходимых методов. По умолчанию он отвергает любого пользователя и не предоставляет никаких разрешений.
Возвращает пустое множество.
Возвращает пустое множество.
Возвращает всех активных пользователей, имеющих разрешение perm либо в виде » label>.
Если include_superusers равно True (по умолчанию), результат будет включать суперпользователей.
Если вам нужно больше контроля, вы можете создать свой собственный бэкэнд аутентификации, который наследуется от этого класса, и переопределить эти атрибуты или методы:
Выполняет любую очистку username (например, удаление информации LDAP DN) перед использованием его для получения или создания объекта пользователя. Возвращает очищенное имя пользователя.
Настраивает только что созданного пользователя. Этот метод вызывается сразу после создания нового пользователя и может быть использован для выполнения пользовательских действий по настройке, таких как установка групп пользователя на основе атрибутов в каталоге LDAP. Возвращает объект пользователя.
Функции полезности¶
Django book: активация панели управления
Глава 4
Для некоторых веб-сайтов панель администратора является необходимой частью функциональности. Это веб-интерфейс, доступ к которому ограничен только для доверенных лиц – администраторов сайта, который позволяет добавлять, редактировать и удалять содержимое сайта. Самые распространённые примеры – интерфейс, через который добавляются посты в блог, панели управления комментариями, утилиты, которые позволяют посетителям обновлять их сообщения на сайте.
Однако, с подобными панелями связано несколько проблем: их создание очень скучный процесс. Веб-разработка интересна, когда вы создаёте что-то для общего доступа, но создание панели администрирования сайтом – всегда один и тот же процесс. Вам требуется авторизовать пользователей, отобразить и обработать какие-то формы, проверить вводимые данные и так далее. Это скучно, и вам приходится повторять одно и то же каждый раз.
Какой подход у Django к таким задачам? Django всё делает за вас – от вас потребуется лишь написать несколько строк. С Django создание такой панели – уже решённая задача.
В этой главе мы рассмотрим панель управления Djnago. Django считывает данные в ваших моделях, и предоставляет отличный веб-интерфейс для управления, который администраторы могут начинать использовать немедленно. В этой главе мы рассмотрим как его активировать, использовать и настраивать.
Мы рекомендуем вам прочитать эту главу в любом случае, даже если вы не намереваетесь использовать родную панель управления Django, так как тут мы мы рассмотрим несколько новых концепций, которые касаются всего Django-сайта.
Пакеты django.contrib
Панель управления в Django – часть большого набора функциональности, которая называется django.contrib – это часть кода Django, которая включает в себя различные полезные расширения для фреймворка. Вы можете представлять себе django.contrib как аналог стандартной библиотеки Python – общая, хотя и необязательная для использования, реализация некоторых распространённых действий. Она включена в Django по умолчанию, поэтому вы можете не заниматься изобретением велосипеда для ваших приложений.
Активация панели администратора
Панель управления Django совершенно необязательна к использованию, так как не все сайты нуждаются в ней. Поэтому – она отключена по умолчанию, и вам необходимо выполнить несколько действий, что бы включить её.
Для начала – отредактируйте ваш файл settings.py :
В результате у вас должен получиться такой набор настроек:
Фреймворк contenttypes ¶
Django включает contenttypes приложение, которое может отслеживать все модели, установленные в вашем проекте на базе Django, обеспечивая высокоуровневый универсальный интерфейс для работы с вашими моделями.
Обзор ¶
Экземпляры ContentType имеют методы для возврата классов моделей, которые они представляют, и для запроса объектов из этих моделей. ContentType также есть настраиваемый менеджер, который добавляет методы для работы ContentType и получения экземпляров ContentType для конкретной модели.
Отношения между вашими моделями, а ContentType также могут использоваться для включения «общих» отношений между экземпляром одной из ваших моделей и экземплярами любой установленной вами модели.
Установка фреймворка contenttypes ¶
Обычно рекомендуется установить фреймворк contenttypes; это требуется для некоторых других приложений Django:
ContentType Модель ¶
Каждый экземпляр ContentType имеет два поля, которые, вместе взятые, однозначно описывают установленную модель:
Дополнительно доступно следующее свойство:
Удобочитаемое имя типа контента. Это взято из verbose_name атрибута модели.
Давайте посмотрим на пример, чтобы увидеть, как это работает. Если у вас уже установлено contenttypes приложение, а затем добавьте его в настройки и запустите для его установки, модель будет установлена в вашу базу данных. Вместе с этим будет создан новый экземпляр со следующими значениями: the sites application INSTALLED_APPS manage.py migrate django.contrib.sites.models.Site ContentType
Методы на ContentType инстансах ¶
У каждого ContentType экземпляра есть методы, которые позволяют вам перейти от ContentType экземпляра к модели, которую он представляет, или получить объекты из этой модели:
ContentType. get_object_for_this_type ( ** kwargs ) ¶
Принимает набор допустимых аргументов поиска для модели, которую ContentType представляет, и выполняет для этой модели, возвращая соответствующий объект. a get() lookup
Возвращает класс модели, представленный этим ContentType экземпляром.
Например, мы могли бы посмотреть вверх ContentType для User модели:
А затем используйте его для запроса конкретного User или для получения доступа к User классу модели:
Вместе get_object_for_this_type() и model_class() позволяют реализовать два чрезвычайно важных варианта использования:
Некоторые из приложений, входящих в пакет Django, используют последний метод. Например, в платформе аутентификации Django используется модель с внешним ключом для ; это позволяет представить такие понятия, как «можно добавить запись в блог» или «можно удалить новость». the permissions system Permission ContentType Permission
ContentTypeManager ¶
Очищает внутренний кеш, используемый ContentType для отслеживания моделей, для которых были созданы ContentType экземпляры. Вам, вероятно, никогда не понадобится вызывать этот метод самостоятельно; Django будет вызывать его автоматически, когда это необходимо.
Принимает либо класс модели, либо экземпляр модели и возвращает ContentType экземпляр, представляющий эту модель. for_concrete_model=False позволяет ContentType получить прокси-модель.
Принимает переменное количество классов модели и возвращает словарь, сопоставляющий классы модели с ContentType экземплярами, представляющими их. for_concrete_models=False позволяет получать ContentType прокси-модели.
Этот get_for_model() метод особенно полезен, когда вы знаете, что вам нужно работать с a, ContentType но не хотите тратить время на получение метаданных модели для выполнения поиска вручную:
Родовые отношения ¶
Добавление внешнего ключа из одной из ваших собственных моделей, чтобы ContentType позволить вашей модели эффективно привязать себя к другому классу модели, как в примере Permission модели выше. Но можно пойти еще дальше и использовать ContentType для включения действительно общих (иногда называемых «полиморфными») отношений между моделями.
Например, его можно использовать для такой системы тегов:
Обычный ForeignKey может «указывать» только на одну другую модель, что означает, что если бы TaggedItem модель использовала a, ForeignKey ей пришлось бы выбрать одну и только одну модель для хранения тегов. Приложение contenttypes предоставляет специальный тип поля ( GenericForeignKey ), который позволяет обойти это и позволяет устанавливать отношения с любой моделью:
Настройка состоит из трех частей GenericForeignKey :
Совместимость типов первичного ключа
Поле «object_id» не обязательно должно быть того же типа, что и поля первичного ключа в связанных моделях, но их значения первичного ключа должны приводиться к тому же типу, что и поле «object_id» по его get_db_prep_value() методу.
Для максимальной гибкости вы можете использовать, для TextField которого не определена максимальная длина, однако это может привести к значительным потерям производительности в зависимости от вашей базы данных.
Не существует универсального решения для выбора наилучшего типа поля. Вы должны оценить модели, на которые вы предполагаете указывать, и определить, какое решение будет наиболее эффективным для вашего варианта использования.
Сериализация ссылок на ContentType объекты
Это позволит использовать API, аналогичный тому, который используется для обычного ForeignKey ; у каждого TaggedItem будет content_object поле, которое возвращает объект, с которым он связан, и вы также можете назначить это поле или использовать его при создании TaggedItem :
Если соответствующий объект удаляется, то content_type и object_id поля остаются установленными в их исходные значения и GenericForeignKey возвращает None :
Точно так же GenericForeignKey s не появляется в ModelForm s.
Обратные отношения общего положения ¶
Связь связанного объекта с этим объектом по умолчанию не существует. Настройка related_query_name создает отношение от связанного объекта к этому. Это позволяет запрашивать и фильтровать связанный объект.
Если вы знаете, какие модели вы будете использовать чаще всего, вы также можете добавить «обратную» общую связь, чтобы включить дополнительный API. Например:
Bookmark у каждого экземпляра будет tags атрибут, который можно использовать для получения связанных с ними TaggedItems :
remove() Вызов будет навалом удалить указанные объекты модели:
Этот clear() метод можно использовать для массового удаления всех связанных объектов для экземпляра:
Определение GenericRelation с помощью related_query_name set позволяет запрашивать из связанного объекта:
Это позволяет выполнять фильтрацию, упорядочивание и другие операции запросов на Bookmark from TaggedItem :
Родовые отношения и агрегирование ¶
Родовое отношение в формах ¶
absolute_max И can_delete_extra были добавлены аргументы.
Общие отношения в админке ¶
GenericInlineModelAdmin Класс наследует все свойства от InlineModelAdmin класса. Однако он добавляет пару собственных для работы с родовым отношением:
класс GenericTabularInline ¶ класс GenericStackedInline ¶
Подклассы GenericInlineModelAdmin с составными и табличными макетами соответственно.
Использование системы аутентификации Django ¶
Этот документ представляет использование системы аутентификации Django в ее конфигурации по умолчанию. Эта конфигурация была разработана для удовлетворения наиболее распространенных потребностей проектов, она способна обрабатывать широкий спектр задач и имеет тщательную реализацию паролей и разрешений. Для проектов, в которых требуется проверка подлинности, отличная от конфигурации по умолчанию, Django позволяет расширять и настраивать проверку подлинности в деталях.
Аутентификация Django обеспечивает как аутентификацию, так и авторизацию, вместе именуемые системой аутентификации, поскольку эти функции довольно тесно связаны.
Пользовательские объекты ¶
Основные атрибуты пользователя по умолчанию:
Проконсультируйтесь с ним для получения исчерпывающей ссылки; приведенная ниже документация больше ориентирована на задачи. documentation complète de l’API
Создание пользователей ¶
Создание суперпользователей ¶
Суперпользователей можно создать с помощью команды createsuperuser :
Смена паролей ¶
Django не хранит необработанные (чистые) пароли в модели пользователя, только хеш-хэш (подробности см. В документации о том, как обрабатываются пароли ). Вот почему необходимо избегать прямого манипулирования атрибутом password пользователя и чтобы для создания пользователя использовалась служебная функция.
Чтобы изменить пароль пользователя, у вас есть несколько вариантов:
manage.py changepassword *nom d’utilisateur* предоставляет метод изменения пароля пользователя из командной строки. Вам будет предложено изменить пароль для указанного пользователя, введя его дважды. Если две записи совпадают, новый пароль будет установлен немедленно. Если вы не укажете имя пользователя, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя системы.
Также можно изменить пароль программно, используя set_password() :
Django также предоставляет представления и формы, которые позволяют пользователям изменять свои собственные пароли.
Смена пароля пользователя отключает все его сеансы. См. Раздел Аннулирование сеанса при смене пароля для более подробной информации.
Аутентификация пользователя ¶
Разрешения и разрешения ¶
Django содержит встроенную систему разрешений. Он позволяет назначать разрешения конкретным пользователям или группам пользователей.
Эта система используется сайтом администрирования Django, но вы можете использовать ее в своем собственном коде.
Сайт администратора Django использует следующие разрешения:
Разрешения по умолчанию ¶
К модели Permission редко обращаются напрямую.
Группы ¶
Программное создание разрешений ¶
Хотя пользовательские разрешения могут быть определены в классе Meta модели, также возможно напрямую создавать разрешения. Например, вы можете создать разрешение can_publish модели BlogPost в myapp :
Прокси-моделям нужен собственный тип контента
Разрешения на кеширование ¶
Механизм ModelBackend кэширует разрешения объекта пользователя при первом просмотре этих разрешений. Как правило, это хорошо подходит для цикла запрос-ответ, поскольку в принципе разрешения не запрашиваются сразу после добавления (например, в интерфейсе администрирования). Если вы добавляете разрешения и видите их сразу после, например, в тесте или представлении, самым простым решением является повторное извлечение объекта пользователя из базы данных. Например :
Прокси-модели ¶
Прокси-модели работают точно так же, как и конкретные модели. Разрешения создаются с использованием типа контента, специфичного для модели прокси. Прокси-модели не наследуют разрешения от конкретной модели, которую они расширяют.
Аутентификация в веб-запросах ¶
Логин пользователя ¶
Обратите внимание, что любая информация, определенная во время анонимного сеанса пользователя, сохраняется в сеансе после процесса входа в систему.
В этом примере показано, как использовать authenticate() и login() :
Выбор механизма аутентификации ¶
Когда пользователь подключается, его идентификатор и механизм, используемый для его аутентификации, сохраняются в сеансе пользователя. Это позволяет тому же механизму аутентификации извлекать сведения о пользователе по последующему запросу. Механизм аутентификации, который будет сохранен в сеансе, выбирается следующим образом:
В первых двух случаях значение параметра backend или атрибута user.backend должно соответствовать строке пути, разделенной точками (как в синтаксисе AUTHENTICATION_BACKENDS ), а не фактическому классу механизма.
Выход пользователя из системы ¶
Обратите внимание, что logout() не сообщает об ошибке, если пользователь не вошел в систему.
Ограничение доступа для авторизованных пользователей ¶
Сырой способ ¶
… Или отобразить сообщение об ошибке:
Декоратор login_required ¶
В качестве ярлыка вы можете использовать login_required() удобный декоратор :
Декоратор login_required НЕ проверяет флаг is_active пользователя, но движок по AUTHENTICATION_BACKENDS умолчанию отклоняет неактивных пользователей.
Класс миксинов LoginRequired ¶
Вы можете определить любой из параметров AccessMixin для настройки обработки неаутентифицированных пользователей:
Ограничение доступа для авторизованных пользователей, прошедших тест ¶
Чтобы ограничить доступ на основе определенного разрешения или теста, процесс почти идентичен описанному в предыдущем разделе.
Вы можете выполнить тест request.user прямо в представлении. Например, это представление проверяет, есть ли у пользователя адрес электронной почты в предполагаемом домене, и, если нет, перенаправляет на страницу входа:
В качестве ярлыка вы можете использовать декоратор, user_passes_test который выполняет перенаправление при возврате декорированной функции False :
user_passes_test() требуется один параметр: исполняемый файл, который принимает объект User и возвращает, есть True ли у пользователя разрешение на просмотр страницы. Обратите внимание, что user_passes_test() автоматически не проверяется, что объект User не анонимен.
user_passes_test() принимает два необязательных параметра:
Вы должны переопределить метод test_func() класса, чтобы предоставить тест, который будет выполняться. Кроме того, вы можете определить любой из параметров AccessMixin для настройки обработки неаутентифицированных пользователей:
Вы также можете переопределить метод, get_test_func() если хотите, чтобы класс миксина использовал другой метод для этой проверки (вместо test_func() ).
Из-за реализации UserPassesTestMixin невозможно объединить более одного в цепочке наследования. Следующий код НЕ будет работать:
Если бы TestMixin1 позвонил super() и учел результат, TestMixin1 уже не работал бы автономно.
Декоратор permission_required ¶
Относительно часто требуется проверять наличие у пользователя определенных прав. Для этого в Django есть ярлык: декоратор permission_required() :
Декоратор также принимает список разрешений, и в этом случае пользователь должен иметь все разрешения в списке, чтобы иметь доступ к представлению.
Обратите внимание, что permission_required() также принимает необязательный параметр login_url :
Если параметр raise_exception присутствует, декоратор генерирует исключение PermissionDenied (в разрешении отказано), вызывая представление 403 (HTTP Forbidden) вместо перенаправления на страницу входа.
Класс миксинов PermissionRequiredMixin ¶
Вы можете определить любой из параметров, AccessMixin чтобы настроить обработку неаутентифицированных пользователей.
Вы также можете переопределить эти методы:
Перенаправление неавторизованных запросов в представлениях на основе классов ¶
класс AccessMixin ¶ login_url ¶
Аннулирование сессии при смене пароля ¶
Эта функция принимает в качестве входных данных текущий запрос, а также обновленный объект пользователя, из которого будет вычислено новое значение хеш-функции сеанса; он обновляет хеш-значение сеанса. Он также заботится об изменении ключа сеанса, чтобы украденный файл cookie сеанса стал недействительным:
Просмотры аутентификации ¶
Использование представлений ¶
Это будет включать следующие шаблоны URL
У представлений есть URL-имя для облегчения поиска. Подробную информацию об использовании именованных шаблонов URL см. В документации по URL.
Если вы хотите больше контролировать свои URL-адреса, вы можете указать конкретное представление в своем URLconf.
Все представления аутентификации ¶
Имя URL: login
Подробную информацию об использовании именованных шаблонов URL см. В документации по URL.
Атрибуты:
extra_context : словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
success_url_allowed_hosts : набор дополнительных set хостов, request.get_host() которые безопасны в качестве цели перенаправления после подключения. По set умолчанию набор пуст.
Вот что он делает LoginView :
Вы обязаны предоставить HTML-код для шаблона подключения с именем registration/login.html по умолчанию. Этот шаблон получает четыре контекстных переменных шаблона:
Вот пример шаблона registration/login.html в качестве отправной точки. Он полагается на наличие шаблона, base.html который определяет блок content :
Выходит из системы.
Имя URL: logout
Атрибуты:
Контекст шаблона:
Выполняет выход пользователя из системы, а затем перенаправляет его на страницу входа.
Имя URL: без URL по умолчанию
Необязательные параметры:
Имя URL: password_change
Позволяет пользователю изменить свой пароль.
Атрибуты:
Контекст шаблона:
Имя URL: password_change_done
Страница, отображаемая после смены пароля пользователем.
Атрибуты:
Имя URL: password_reset
Позволяет пользователю сбросить свой пароль, создав одноразовую ссылку для сброса пароля. Эта ссылка отправляется на адрес электронной почты, зарегистрированный для этого пользователя.
Пользователям с непригодным для использования паролем (см. set_unusable_password() ) Не разрешается запрашивать сброс пароля для предотвращения неправильного использования с внешними источниками аутентификации, такими как LDAP. Обратите внимание, что они не получают сообщения об ошибке, так как это означает, что их учетная запись существует, но они также не получают сообщения электронной почты.
Атрибуты:
Контекст шаблона:
Контекст шаблона электронного письма:
Пример registration/password_reset_email.html (шаблона тела сообщения):
Шаблон субъекта получает тот же контекст шаблона. Тема должна быть одной строкой обычного текста.
Имя URL: password_reset_done
Если указанный адрес электронной почты не существует в системе, если пользователь неактивен или если его пароль не используется, это представление все равно будет отображаться, но сообщение не будет отправлено.
Атрибуты:
Имя URL: password_reset_confirm
Отображает форму для ввода нового пароля.
Именованные параметры из URL:
Атрибуты:
post_reset_login : Логическое значение, указывающее, должен ли пользователь проходить автоматическую аутентификацию после успешного сброса пароля. Есть False по умолчанию.
extra_context : словарь данных контекста, который будет объединен с данными контекста по умолчанию, переданными в шаблон.
Атрибут класса reset_url_token был добавлен.
Контекст шаблона:
Имя URL: password_reset_complete
Отображает представление, информирующее пользователя об успешной смене пароля.
Атрибуты:
Служебные функции ¶
Перенаправляет на страницу входа, а затем на другой URL-адрес, если вход был успешным.
Обязательные параметры:
Необязательные параметры:
Встроенные формы ¶
Если вы не хотите использовать встроенные представления, но хотите воспользоваться преимуществом отсутствия необходимости переписывать формы для этой функции, система аутентификации предоставляет несколько встроенных форм, которые можно найти в django.contrib.auth.forms :
Форма, используемая в интерфейсе администрирования для изменения пароля пользователя.
Принимается user как первый позиционный параметр.
Форма для подключения пользователя.
Принимается request как первый позиционный параметр, который затем сохраняется в экземпляре формы, доступном для подклассов.
Например, чтобы разрешить всем пользователям подключаться, независимо от их «активного» статуса:
Или разрешить подключение только определенным активным пользователям:
Форма, позволяющая пользователю изменить свой пароль.
Форма для создания и отправки по электронной почте одноразовой ссылки для сброса пароля пользователя.
По умолчанию save() заполните его context теми же переменными, которые PasswordResetView передаются в его контекст отправки электронной почты.
Форма, позволяющая пользователю изменить свой пароль без ввода старого пароля.
Форма, используемая в интерфейсе администрирования для изменения данных и разрешений пользователя.
Один ModelForm для создания нового пользователя.
Данные для аутентификации в шаблонах ¶
Пользователи ¶
Эта переменная контекста шаблона недоступна, если RequestContext не используется.
Разрешения ¶
Вот более полный пример управления разрешениями в шаблоне
Управление пользователями на сайте администрирования ¶
Когда django.contrib.admin и django.contrib.auth оба установлены, сайт администрирования предлагает удобный интерфейс для просмотра и управления пользователями, группами и разрешениями. Пользователи могут создаваться и удаляться, как и любая другая модель Django. Можно создавать группы и назначать разрешения пользователям и группам. Изменения модели, внесенные пользователями в процессе администрирования, также регистрируются и отображаются.
Создание пользователей ¶
Вы должны увидеть ссылку на «Пользователи» в разделе «Auth» на главной странице сайта администрирования. Страница администрирования «Добавить пользователя» отличается от других страниц администрирования тем, что требует, чтобы вы сначала вводили имя пользователя и пароль, прежде чем вы сможете редактировать другие поля в пользователь.
Обратите внимание на то, как вы позволяете пользователям управлять разрешениями. Если вы дадите не суперпользователю возможность редактировать пользователей, это в конечном итоге сведется к тому же, что и предоставление им статуса суперпользователя, поскольку они смогут повышать права пользователей, включая свои собственные!
Смена паролей ¶
Пароли пользователей не отображаются на сайте администрирования (и не хранятся в базе данных), но детали хранения паролей видны. Эта информация содержит ссылку на форму изменения пароля, которая позволяет администраторам изменять пароли пользователей.
