Не работает авторизация django

Не работает login в Django

Пытаюсь на сайте войти на обычного зарегистрированного пользователя на сайте, всё работает через login, пробовал разные способы, ничего не получается, заходит только на суперюзера

После нажатия по вход вылетает ошибка из forms.py(пароль ввожу верно):

2 ответа 2

Рекомендую использовать данную инструкцию

В общем ошибку нашёл в сохранении юзера, просто if form_reg.is_valid() переписал так:

И всё стало работать. В админке смутило, что у юзеров в пароле было это: Неизвестный формат пароля или алгоритм хеширования и я решил переписать и всё стало работать прекрасно, в общем проблема была в паролях

Всё ещё ищете ответ? Посмотрите другие вопросы с метками python python-3.x django или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.10.15.40479

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Настройка аутентификации в Django ¶

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

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

Вы можете предоставить своим моделям специальные разрешения, которые можно проверить через систему авторизации Django.

Вы можете расширить User модель по умолчанию или заменить полностью настроенную модель.

Другие источники аутентификации ¶

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

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

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

См. Справку по бэкэнду аутентификации для получения информации о бэкэндах аутентификации, включенных в Django.

Указание бэкэндов аутентификации ¶

За кулисами Django поддерживает список «бэкэндов аутентификации», которые он проверяет на предмет аутентификации. Когда кто-то звонит django.contrib.auth.authenticate() — как описано в разделе «Как войти в систему» — Django пытается пройти аутентификацию во всех своих бэкэндах аутентификации. Если первый метод аутентификации не работает, Django пробует второй, и так далее, пока все бэкенды не будут выполнены.

Список используемых бэкэндов аутентификации указывается в AUTHENTICATION_BACKENDS настройке. Это должен быть список имен путей Python, указывающих на классы Python, которые знают, как аутентифицироваться. Эти классы могут быть где угодно на вашем пути Python.

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

Порядок имеет AUTHENTICATION_BACKENDS значение, поэтому, если одно и то же имя пользователя и пароль действительны в нескольких бэкэндах, Django прекратит обработку при первом положительном совпадении.

Если серверная часть вызывает PermissionDenied исключение, проверка подлинности немедленно завершится ошибкой. Django не будет проверять последующие серверные ВМ.

После аутентификации пользователя Django сохраняет, какой бэкэнд использовался для аутентификации пользователя в сеансе пользователя, и повторно использует тот же бэкэнд в течение этого сеанса всякий раз, когда требуется доступ к текущему аутентифицированному пользователю. Это фактически означает, что источники аутентификации кэшируются для каждого сеанса, поэтому, если вы измените AUTHENTICATION_BACKENDS , вам нужно будет очистить данные сеанса, если вам нужно заставить пользователей повторно аутентифицироваться с использованием других методов. Самый простой способ сделать это — выполнить Session.objects.all().delete() .

Написание бэкенда аутентификации ¶

Бэкэнд аутентификации — это класс, реализующий два обязательных метода: get_user(user_id) и , а также набор дополнительных методов авторизации, связанных с разрешениями . authenticate(request, **credentials)

get_user Метод берет user_id — что может быть имя пользователя, идентификатор базы данных или любой другой , но должен быть первичным ключом вашего пользовательского объекта — и возвращает объект пользователя или None .

authenticate Метод принимает request аргумент и полномочия в качестве ключевых слов аргументов. В большинстве случаев это будет выглядеть так:

Но он также может аутентифицировать токен, например:

В любом случае authenticate() следует проверить полученные учетные данные и вернуть объект пользователя, который соответствует этим учетным данным, если учетные данные действительны. Если они недействительны, он должен вернуться None .

request является HttpRequest и может быть, None если он не был предоставлен authenticate() (который передает его в серверную часть).

Администратор Django тесно связан с объектом пользователя Django . Лучший способ справиться с этим — создать User объект Django для каждого пользователя, который существует для вашей серверной части (например, в вашем каталоге LDAP, вашей внешней базе данных SQL и т. Д.). Вы можете либо написать сценарий, чтобы сделать это заранее, либо ваш authenticate метод может сделать это при первом входе пользователя в систему.

Вот пример бэкэнда, который аутентифицируется по переменной имени пользователя и пароля, определенной в вашем settings.py файле, и создает User объект Django при первой аутентификации пользователя:

Обработка авторизации в кастомных бэкэндах ¶

Пользовательские серверные части аутентификации могут предоставлять свои собственные разрешения.

Модель пользователя и его менеджер будет делегировать разрешение функции поиска ( get_user_permissions() , get_group_permissions() , get_all_permissions() , has_perm() , has_module_perms() , и with_perm() ) в любой серверной аутентификации , который реализует эти функции.

Разрешения, предоставленные пользователю, будут надмножеством всех разрешений, возвращаемых всеми бэкэндами. То есть Django предоставляет пользователю разрешение, которое предоставляет любой бэкэнд.

Если бэкэнд вызывает PermissionDenied исключение в has_perm() или has_module_perms() , авторизация немедленно завершится ошибкой, и Django не будет проверять последующие бэкэнды.

Бэкэнд может реализовать разрешения для волшебного администратора следующим образом:

Это дает полные разрешения пользователю, которому предоставлен доступ в приведенном выше примере. Обратите внимание, что в дополнение к тем же аргументам, которые передаются связанным django.contrib.auth.models.User функциям, все бэкэнд-функции аутентификации принимают в качестве аргумента объект пользователя, который может быть анонимным пользователем.

Полную реализацию авторизации можно найти в ModelBackend классе django / contrib / auth / backends.py , который является бэкендом по умолчанию и auth_permission большую часть времени запрашивает таблицу.

Авторизация для анонимных пользователей ¶

Анонимный пользователь — это пользователь, который не прошел проверку подлинности, т. Е. Не предоставил действительные данные проверки подлинности. Однако это не обязательно означает, что они не уполномочены что-либо делать. На самом базовом уровне большинство веб-сайтов разрешают анонимным пользователям просматривать большую часть сайта, а многие разрешают анонимную публикацию комментариев и т. Д.

В структуре разрешений Django нет места для хранения разрешений для анонимных пользователей. Однако пользовательский объект, переданный бэкэнду аутентификации, может быть django.contrib.auth.models.AnonymousUser объектом, позволяющим бэкэнду определять настраиваемое поведение авторизации для анонимных пользователей. Это особенно полезно для авторов многоразовых приложений, которые могут делегировать все вопросы авторизации бэкэнду аутентификации, вместо того, чтобы требовать настройки, например, для управления анонимным доступом.

Авторизация для неактивных пользователей ¶

Неактивный пользователь — это тот, у которого в is_active поле установлено значение False . ModelBackend И RemoteUserBackend движки аутентификации запрещает этим пользователям от аутентификации. Если в пользовательской модели пользователя нет is_active поля, всем пользователям будет разрешена аутентификация.

Вы можете использовать AllowAllUsersModelBackend или, AllowAllUsersRemoteUserBackend если хотите разрешить аутентификацию неактивным пользователям.

Поддержка анонимных пользователей в системе разрешений позволяет реализовать сценарий, в котором анонимные пользователи имеют разрешения на какие-либо действия, а неактивные аутентифицированные пользователи — нет.

Не забудьте проверить is_active атрибут пользователя в ваших собственных методах разрешения серверной части.

Обработка прав доступа к объектам ¶

Платформа разрешений Django имеет основу для разрешений на объекты, хотя в ядре ее реализации нет. Это означает, что проверка разрешений объекта всегда будет возвращать False или пустой список (в зависимости от выполненной проверки). Серверная часть аутентификации получит параметры ключевого слова obj и user_obj для каждого метода авторизации, относящегося к объекту, и при необходимости может вернуть разрешение на уровне объекта.

Пользовательские разрешения ¶

Чтобы создать настраиваемые разрешения для данного объекта модели, используйте permissions атрибут Meta модели .

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

Единственное, что это делает, — это создание этих дополнительных разрешений при запуске (функция, создающая разрешения, подключена к сигналу). Ваш код отвечает за проверку значения этих разрешений, когда пользователь пытается получить доступ к функциям, предоставляемым приложением (изменение статуса задач или закрытие задач). Продолжая приведенный выше пример, следующая проверка может ли пользователь закрывать задачи. : manage.py migrate post_migrate

Расширение существующей User модели ¶

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

Если вы хотите сохранить информацию, относящуюся к User , вы можете использовать OneToOneField для модели, содержащей поля для дополнительной информации. Эту модель «один к одному» часто называют моделью профиля, поскольку она может хранить информацию о пользователе сайта, не связанную с авторизацией. Например, вы можете создать модель Сотрудника:

Предполагая, что у существующего сотрудника Фреда Смита есть и модель пользователя, и модель сотрудника, вы можете получить доступ к соответствующей информации, используя стандартные соглашения о связанных моделях Django:

Чтобы добавить поля модели профиля на страницу пользователя в админке, определите InlineModelAdmin (для этого примера мы будем использовать a StackedInline ) в вашем приложении admin.py и добавить его в UserAdmin класс, который зарегистрирован с этим User классом:

Эти модели профилей ни в коем случае не являются особенными — это просто модели Django, которые имеют прямую связь с моделью пользователя. Таким образом, они не создаются автоматически при создании пользователя, но django.db.models.signals.post_save могут использоваться для создания или обновления связанных моделей по мере необходимости.

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

Замена нестандартной User модели ¶

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

Django позволяет вам переопределить модель пользователя по умолчанию, указав значение для AUTH_USER_MODEL параметра, который ссылается на пользовательскую модель:

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

Использование пользовательской модели пользователя при запуске проекта ¶

Если вы начинаете новый проект, настоятельно рекомендуется настроить пользовательскую модель пользователя, даже если User модели по умолчанию вам достаточно. Эта модель ведет себя идентично пользовательской модели по умолчанию, но вы сможете настроить ее в будущем, если возникнет необходимость:

Не забудьте указать AUTH_USER_MODEL на это. Сделайте это перед созданием каких-либо миграций или запуском в первый раз. manage.py migrate

Также зарегистрируйте модель в приложении admin.py :

Переход к пользовательской модели в середине проекта ¶

Изменить AUTH_USER_MODEL после того, как вы создали таблицы базы данных, значительно сложнее, поскольку это влияет, например, на внешние ключи и отношения «многие ко многим».

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

Из-за ограничений функции динамической зависимости Django для заменяемых моделей модель, на которую ссылается, AUTH_USER_MODEL должна быть создана при первой миграции своего приложения (обычно это называется 0001_initial ); в противном случае у вас возникнут проблемы с зависимостями.

Кроме того, вы можете столкнуться с ошибкой CircularDependencyError при выполнении миграции, поскольку Django не сможет автоматически разорвать цикл зависимостей из-за динамической зависимости. Если вы видите эту ошибку, вам следует разорвать цикл, переместив модели, зависящие от вашей пользовательской модели, во вторую миграцию. (Вы можете попробовать создать две нормальные модели, которые связаны ForeignKey друг с другом, и посмотреть, как makemigrations разрешается эта круговая зависимость, если вы хотите увидеть, как это обычно делается.)

Многоразовые приложения и AUTH_USER_MODEL ¶

Многоразовые приложения не должны реализовывать настраиваемую модель пользователя. В проекте может использоваться много приложений, и два многоразовых приложения, реализующих настраиваемую модель пользователя, нельзя использовать вместе. Если вам нужно хранить в информации о пользователях в вашем приложении, используйте ForeignKey или OneToOneField чтобы , settings.AUTH_USER_MODEL как описано ниже.

Ссылка на User модель ¶

Если вы ссылаетесь User напрямую (например, ссылаясь на него во внешнем ключе), ваш код не будет работать в проектах, где AUTH_USER_MODEL параметр был изменен на другую модель пользователя.

Вместо того, чтобы ссылаться User напрямую, вы должны ссылаться на модель пользователя, используя django.contrib.auth.get_user_model() . Этот метод вернет текущую активную модель пользователя — пользовательскую модель пользователя, если она указана, или User иначе.

Когда вы определяете внешний ключ или отношения «многие ко многим» для модели пользователя, вы должны указать настраиваемую модель с помощью AUTH_USER_MODEL параметра. Например:

При подключении к сигналам, отправляемым моделью пользователя, вы должны указать пользовательскую модель с помощью AUTH_USER_MODEL параметра. Например:

Вообще говоря, проще всего ссылаться на пользовательскую модель с AUTH_USER_MODEL настройкой в ​​коде, который выполняется во время импорта, однако также можно вызвать, get_user_model() пока Django импортирует модели, поэтому вы можете использовать . models.ForeignKey(get_user_model(), . )

Если ваше приложение тестируется с несколькими пользовательскими моделями, @override_settings(AUTH_USER_MODEL=. ) например , используя , и вы кэшируете результат get_user_model() в переменной уровня модуля, вам может потребоваться прослушать setting_changed сигнал, чтобы очистить кеш. Например:

Указание пользовательской модели пользователя ¶

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

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

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

Самый простой способ создать совместимую пользовательскую модель — это унаследовать от AbstractBaseUser . AbstractBaseUser предоставляет базовую реализацию модели пользователя, включая хешированные пароли и сброс паролей с помощью токенизации. Затем вы должны предоставить некоторые ключевые детали реализации:

класс models. CustomUser ¶ USERNAME_FIELD ¶

Строка, описывающая имя поля в модели пользователя, которое используется в качестве уникального идентификатора. Обычно это какое-то имя пользователя, но также может быть адрес электронной почты или любой другой уникальный идентификатор. Поле должно быть уникальным (т. Е. unique=True Задано в его определении), если только вы не используете настраиваемый сервер аутентификации, который может поддерживать неуникальные имена пользователей.

В следующем примере поле identifier используется как поле идентификации:

Строка, описывающая имя поля электронной почты в User модели. Это значение возвращается get_email_field_name() .

Список имен полей, которые будут запрошены при создании пользователя с помощью команды createsuperuser управления. Пользователю будет предложено ввести значение для каждого из этих полей. Она должна включать в себя любое поле , для которого blank является False или неопределенным и может включать в себя дополнительные поля , которые вы хотите запрашиваться при создании пользователя в интерактивном режиме . REQUIRED_FIELDS не влияет на другие части Django, например на создание пользователя в админке.

Например, вот частичное определение модели пользователя, которое определяет два обязательных поля — дату рождения и рост:

REQUIRED_FIELDS должен содержать все обязательные поля в вашей пользовательской модели, но не должен содержать USERNAME_FIELD или, так password как эти поля всегда будут запрашиваться.

Логический атрибут, указывающий, считается ли пользователь «активным». Этот атрибут предоставляется как атрибут по AbstractBaseUser умолчанию True . То, как вы решите реализовать это, будет зависеть от деталей выбранных вами бэкэндов аутентификации. Подробности см. В документации . is_active attribute on the built-in user model

По желанию. Более длинный формальный идентификатор пользователя, например полное имя. Если реализовано, это отображается рядом с именем пользователя в истории объекта в django.contrib.admin .

По желанию. Короткий неформальный идентификатор пользователя, например его имя. Если реализовано, это заменяет имя пользователя в приветствии пользователя в заголовке django.contrib.admin .

AbstractBaseUser и BaseUserManager импортируются из файлов, django.contrib.auth.base_user поэтому их можно импортировать без включения django.contrib.auth в INSTALLED_APPS .

Следующие атрибуты и методы доступны в любом подклассе AbstractBaseUser :

класс models. AbstractBaseUser ¶ get_username () ¶

Возвращает значение поля, назначенного USERNAME_FIELD .

Нормализует имя пользователя путем звонка normalize_username() . Если вы переопределите этот метод, обязательно вызовите, super() чтобы сохранить нормализацию.

Возвращает имя поля электронной почты, указанное EMAIL_FIELD атрибутом. По умолчанию, ’email’ если EMAIL_FIELD не указано.

classmethod normalize_username ( имя пользователя ) ¶

Применяет нормализацию NFKC Unicode к именам пользователей, чтобы визуально идентичные символы с разными кодовыми точками Unicode считались идентичными.

Атрибут только для чтения, который есть всегда True (а не AnonymousUser.is_authenticated всегда False ). Это способ узнать, прошел ли пользователь аутентификацию. Это не подразумевает каких-либо разрешений и не проверяет, активен ли пользователь или имеет ли действующий сеанс. Несмотря на то, что обычно вы проверяете этот атрибут, request.user чтобы узнать, был ли он заполнен AuthenticationMiddleware (представляющим текущего пользователя, вошедшего в систему), вы должны знать, что этот атрибут предназначен True для любого User экземпляра.

Атрибут только для чтения, который есть всегда False . Это способ различения объектов User и AnonymousUser объектов. Как правило, вы должны предпочесть использование is_authenticated этого атрибута.

Устанавливает пароль пользователя на заданную необработанную строку, заботясь о хешировании пароля. Не сохраняет AbstractBaseUser объект.

Когда raw_password равен None , будет установлен непригодный для использования пароль, как если бы он set_unusable_password() был использован.

Возвращает, True если данная необработанная строка является правильным паролем для пользователя. (Это позаботится о хешировании пароля при сравнении.)

Помечает пользователя как не имеющего установленного пароля. Это не то же самое, что наличие пустой строки для пароля. check_password() ибо этот пользователь никогда не вернется True . Не сохраняет AbstractBaseUser объект.

Это может вам понадобиться, если аутентификация для вашего приложения выполняется с использованием существующего внешнего источника, такого как каталог LDAP.

Возвращает, False если set_unusable_password() был вызван для этого пользователя.

Возвращает HMAC поля пароля. Используется для аннулирования сеанса при смене пароля .

Алгоритм хеширования был изменен на SHA-256.

класс models. AbstractUser ¶ clean () ¶

Нормализует электронную почту, позвонив BaseUserManager.normalize_email() . Если вы переопределите этот метод, обязательно вызовите, super() чтобы сохранить нормализацию.

Написание менеджера для кастомной модели пользователя ¶

Вы также должны определить настраиваемый менеджер для вашей пользовательской модели. Если ваша модель пользователя определяет username , email , is_staff , is_active , is_superuser , last_login , и date_joined поля так же , как пользователь Джанго по умолчанию, вы можете установить Джанго UserManager ; однако, если ваша пользовательская модель определяет разные поля, вам необходимо определить настраиваемый менеджер, который расширяется и BaseUserManager предоставляет два дополнительных метода:

класс models. CustomUserManager ¶ create_user ( username_field , password = None , ** other_fields ) ¶

Прототип create_user() должен принимать поле имени пользователя и все обязательные поля в качестве аргументов. Например, если ваша модель пользователя использует email в качестве поля имени пользователя и имеет date_of_birth обязательное поле, то его create_user следует определить как:

Прототип create_superuser() должен принимать поле имени пользователя и все обязательные поля в качестве аргументов. Например, если ваша модель пользователя использует email в качестве поля имени пользователя и имеет date_of_birth обязательное поле, то его create_superuser следует определить как:

Для ForeignKey in USERNAME_FIELD или REQUIRED_FIELDS эти методы получают значение to_field ( primary_key по умолчанию) существующего экземпляра.

BaseUserManager предоставляет следующие служебные методы:

класс models. BaseUserManager ¶ classmethod normalize_email ( электронная почта ) ¶

Нормализует адреса электронной почты за счет уменьшения доменной части адреса электронной почты.

get_by_natural_key ( имя пользователя ) ¶

Извлекает пользовательский экземпляр, используя содержимое поля, назначенного USERNAME_FIELD .

make_random_password ( длина = 10 , allowed_chars = ‘abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789’ ) ¶

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

• i , l , I , И 1 (строчные буквы я, строчная буква L, заглавная буква я, и номер один)
• o , O И 0 (строчная буква О, заглавная буква О, и ноль)

Расширение Django по умолчанию User ¶

Если вас полностью устраивает User модель Django , но вы хотите добавить дополнительную информацию о профиле, вы можете django.contrib.auth.models.AbstractUser создать подкласс и добавить свои настраиваемые поля профиля, хотя мы бы порекомендовали отдельную модель, как описано в примечании «Рекомендации по проектированию модели» в разделе « Указание» настраиваемая модель пользователя . AbstractUser предоставляет полную реализацию по умолчанию User в виде абстрактной модели .

Пользовательские пользователи и встроенные формы авторизации ¶

Встроенные формы и представления Django делают определенные предположения о пользовательской модели, с которой они работают.

Следующие формы совместимы с любым подклассом AbstractBaseUser :

Следующие формы делают предположения о пользовательской модели и могут использоваться как есть, если эти предположения соблюдены:

• PasswordResetForm : Предполагается, что модель пользователя имеет поле, в котором хранится адрес электронной почты пользователя с именем, возвращаемым get_email_field_name() ( email по умолчанию), которое может использоваться для идентификации пользователя, и логическое поле с именем is_active для предотвращения сброса пароля для неактивных пользователей.

Наконец, следующие формы привязаны User и должны быть переписаны или расширены для работы с пользовательской моделью:

Если ваша пользовательская модель является подклассом AbstractUser , вы можете расширить эти формы следующим образом:

Пользовательские пользователи и ¶ django.contrib.admin

Если вы хотите, чтобы ваша пользовательская модель также работала с администратором, ваша пользовательская модель должна определять некоторые дополнительные атрибуты и методы. Эти методы позволяют администратору контролировать доступ пользователя к контенту администратора:

класс models. CustomUser is_staff ¶

Возвращает, True если пользователю разрешен доступ к сайту администратора.

Возвращает, True если учетная запись пользователя в настоящее время активна.

Возвращает, True если у пользователя есть указанное разрешение. Если obj предоставляется, необходимо проверить разрешение для конкретного экземпляра объекта.

Возвращает, True если у пользователя есть разрешение на доступ к моделям в данном приложении.

Вам также необходимо будет зарегистрировать свою пользовательскую модель у администратора. Если ваша пользовательская модель расширяется django.contrib.auth.models.AbstractUser , вы можете использовать существующий django.contrib.auth.admin.UserAdmin класс Django . Однако, если ваша модель пользователя расширяется AbstractBaseUser , вам необходимо определить собственный ModelAdmin класс. Возможно создание подкласса по умолчанию django.contrib.auth.admin.UserAdmin ; однако вам необходимо переопределить любое из определений, относящихся к полям django.contrib.auth.models.AbstractUser , не относящимся к вашему пользовательскому классу.

Если вы используете настраиваемый класс, ModelAdmin который является подклассом django.contrib.auth.admin.UserAdmin , вам необходимо добавить свои настраиваемые поля в fieldsets (для полей, которые будут использоваться при редактировании пользователей) и в add_fieldsets (для полей, которые будут использоваться при создании пользователя). Например:

См. Полный пример для получения более подробной информации.

Пользовательские пользователи и разрешения ¶

Чтобы упростить включение инфраструктуры разрешений Django в ваш собственный класс пользователя, Django предоставляет PermissionsMixin . Это абстрактная модель, которую вы можете включить в иерархию классов для своей пользовательской модели, предоставляя вам все методы и поля базы данных, необходимые для поддержки модели разрешений Django.

PermissionsMixin предоставляет следующие методы и атрибуты:

класс models. PermissionsMixin ¶ is_superuser ¶

Булево. Обозначает, что у этого пользователя есть все разрешения, без их явного назначения.

get_user_permissions ( obj = Нет ) ¶

Возвращает набор строк разрешений, которые есть у пользователя напрямую.

Если obj передается, возвращает только разрешения пользователя для этого конкретного объекта.

get_group_permissions ( obj = Нет ) ¶

Возвращает набор строк разрешений, которые есть у пользователя, через их группы.

Если obj передается, возвращает только разрешения группы для этого конкретного объекта.

get_all_permissions ( obj = Нет ) ¶

Возвращает набор строк разрешений, которые есть у пользователя, как для групп, так и для пользователей.

Если obj передается, возвращает только разрешения для этого конкретного объекта.

has_perm ( допустимо , obj = Нет ) ¶

Возвращает, True если у пользователя есть указанное разрешение, где указано perm в формате (см. Разрешения ). Если и оба , этот метод всегда возвращает . » label>.

Если obj передается, этот метод проверяет не разрешение для модели, а для этого конкретного объекта.

has_perms ( perm_list , obj = Нет ) ¶

Возвращает, True если у пользователя есть все указанные разрешения, где каждое разрешение находится в формате . Если и оба , этот метод всегда возвращает . » label>.

Если obj передается, этот метод проверяет разрешения не для модели, а для конкретного объекта.

Возвращает, True если у пользователя есть какие-либо разрешения в данном пакете (метка приложения Django). Если User.is_active и is_superuser оба True , этот метод всегда возвращает True .

PermissionsMixin а также ModelBackend

Если вы не включили PermissionsMixin , убедитесь, что вы не вызываете методы разрешений для ModelBackend . ModelBackend предполагает, что в вашей пользовательской модели доступны определенные поля. Если ваша модель пользователя не предоставляет эти поля, вы получите ошибки базы данных при проверке разрешений.

Пользовательские пользователи и модели прокси ¶

Одним из ограничений пользовательских моделей является то, что установка пользовательской модели нарушит любое расширение прокси-модели User . Прокси-модели должны основываться на конкретном базовом классе; определяя пользовательскую модель пользователя, вы лишаете Django возможности надежно идентифицировать базовый класс.

Если ваш проект использует прокси-модели, вы должны либо изменить прокси, чтобы расширить пользовательскую модель, которая используется в вашем проекте, либо объединить поведение вашего прокси-сервера с вашим User подклассом.

Полный пример ¶

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

Источник