mirror of
https://github.com/django/django.git
synced 2025-08-03 18:38:50 +00:00
Fixed #3011 -- Added swappable auth.User models.
Thanks to the many people that contributed to the development and review of this patch, including (but not limited to) Jacob Kaplan-Moss, Anssi Kääriäinen, Ramiro Morales, Preston Holmes, Josh Ourisman, Thomas Sutton, and Roger Barnes, as well as the many, many people who have contributed to the design discussion around this ticket over many years. Squashed commit of the following: commitd84749a0f0Merge:531e7717c11b1aAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Wed Sep 26 18:37:04 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commit531e7715daMerge:29d1abb1f84b04Author: Russell Keith-Magee <russell@keith-magee.com> Date: Wed Sep 26 07:09:23 2012 +0800 Merged recent trunk changes. commit29d1abbe35Merge:8a527dd54c81a1Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Sep 24 07:49:46 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commit8a527dda13Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Sep 24 07:48:05 2012 +0800 Ensure sequences are reset correctly in the presence of swapped models. commite2b6e22f29Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 23 17:53:05 2012 +0800 Modifications to the handling and docs for auth forms. commit98aba856b5Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 23 15:28:57 2012 +0800 Improved error handling and docs for get_user_model() commit0229209c84Merge:6494bf98599f64Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 23 14:50:11 2012 +0800 Merged recent Django trunk changes. commit6494bf91f2Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Sep 17 21:38:44 2012 +0800 Improved validation of swappable model settings. commit5a04cde342Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Sep 17 07:15:14 2012 +0800 Removed some unused imports. commitffd535e413Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 20:31:28 2012 +0800 Corrected attribute access on for get_by_natural_key commit913e1ac84cAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 20:12:34 2012 +0800 Added test for proxy model safeguards on swappable models. commit280bf19e94Merge:dbb3900935a863Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 18:16:49 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commitdbb3900775Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 18:09:27 2012 +0800 Fixes for Python 3 compatibility. commitdfd72131d8Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 15:54:30 2012 +0800 Added protection against proxying swapped models. commitabcb027190Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 15:11:10 2012 +0800 Cleanup and documentation of AbstractUser base class. commita9491a8776Merge:fd8bb4e08bcb4aAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 14:46:49 2012 +0800 Merge commit '08bcb4aec1' into t3011 commitfd8bb4e3e4Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 14:20:14 2012 +0800 Documentation improvements coming from community review. commitb550a6d06dAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 13:52:47 2012 +0800 Refactored skipIfCustomUser into the contrib.auth tests. commit52a02f1110Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 13:46:10 2012 +0800 Refactored common 'get' pattern into manager method. commitb441a6bbc7Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 16 13:41:33 2012 +0800 Added note about backwards incompatible change to admin login messages. commit08bcb4aec1Author: Anssi Kääriäinen <akaariai@gmail.com> Date: Sat Sep 15 18:30:33 2012 +0300 Splitted User to AbstractUser and User commitd9f5e5addbAuthor: Anssi Kääriäinen <akaariai@gmail.com> Date: Sat Sep 15 18:30:02 2012 +0300 Reworked REQUIRED_FIELDS + create_user() interaction commit579f152e4aMerge:918497293e6733Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 15 20:18:37 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commit918497218cAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 15 20:18:19 2012 +0800 Deprecate AUTH_PROFILE_MODULE and get_profile(). commit334cdfc1bbAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 15 20:00:12 2012 +0800 Added release notes for new swappable User feature. commit5d7bb22e8dAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 15 19:59:49 2012 +0800 Ensure swapped models can't be queried. commit57ac6e3d32Merge:f2ec915abfba3bAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 15 14:31:54 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commitf2ec915b20Merge:19526565e99a3dAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 9 08:29:51 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commit19526563b5Merge:2c5e833c4aa26aAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 9 08:22:26 2012 +0800 Merge recent changes from master. commit2c5e833a30Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 9 07:53:46 2012 +0800 Corrected admin_views tests following removal of the email fallback on admin logins. commit20d1892491Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sun Sep 9 01:00:37 2012 +0800 Added conditional skips for all tests dependent on the default User model commit40ea8b8882Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 8 23:47:02 2012 +0800 Added documentation for REQUIRED_FIELDS in custom auth. commite6aaf65970Author: Russell Keith-Magee <russell@keith-magee.com> Date: Sat Sep 8 23:20:02 2012 +0800 Added first draft of custom User docs. Thanks to Greg Turner for the initial text. commit75118bd242Author: Thomas Sutton <me@thomas-sutton.id.au> Date: Mon Aug 20 11:17:26 2012 +0800 Admin app should not allow username discovery The admin app login form should not allow users to discover the username associated with an email address. commitd088b3af58Author: Thomas Sutton <me@thomas-sutton.id.au> Date: Mon Aug 20 10:32:13 2012 +0800 Admin app login form should use swapped user model commit7e82e83d67Merge:e29c01039aa890Author: Russell Keith-Magee <russell@keith-magee.com> Date: Fri Sep 7 23:45:03 2012 +0800 Merged master changes. commite29c010bebMerge:8e3fd7030bdf22Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Aug 20 13:12:57 2012 +0800 Merge remote-tracking branch 'django/master' into t3011 commit8e3fd703d0Merge:507bb5026e0ba0Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Aug 20 13:09:09 2012 +0800 Merged recent changes from trunk. commit507bb50a92Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Jun 4 20:41:37 2012 +0800 Modified auth app so that login with alternate auth app is possible. commitdabe362836Author: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Jun 4 20:10:51 2012 +0800 Modified auth management commands to handle custom user definitions. commit7cc0baf89dAuthor: Russell Keith-Magee <russell@keith-magee.com> Date: Mon Jun 4 14:17:28 2012 +0800 Added model Meta option for swappable models, and made auth.User a swappable model
This commit is contained in:
Russell Keith-Magee
parent
7c11b1a470
commit
70a0de37d1
57 changed files with 1426 additions and 357 deletions
|
|
@ -286,6 +286,9 @@ these changes.
|
|||
* The ``mimetype`` argument to :class:`~django.http.HttpResponse` ``__init__``
|
||||
will be removed (``content_type`` should be used instead).
|
||||
|
||||
* The ``AUTH_PROFILE_MODULE`` setting, and the ``get_profile()`` method on
|
||||
the User model, will be removed.
|
||||
|
||||
2.0
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -110,15 +110,14 @@ A tuple of authentication backend classes (as strings) to use when attempting to
|
|||
authenticate a user. See the :doc:`authentication backends documentation
|
||||
</ref/authbackends>` for details.
|
||||
|
||||
.. setting:: AUTH_PROFILE_MODULE
|
||||
.. setting:: AUTH_USER_MODEL
|
||||
|
||||
AUTH_PROFILE_MODULE
|
||||
-------------------
|
||||
AUTH_USER_MODEL
|
||||
---------------
|
||||
|
||||
Default: Not defined
|
||||
Default: 'auth.User'
|
||||
|
||||
The site-specific user profile model used by this site. See
|
||||
:ref:`auth-profiles`.
|
||||
The model to use to represent a User. See :ref:`auth-custom-user`.
|
||||
|
||||
.. setting:: CACHES
|
||||
|
||||
|
|
@ -2209,6 +2208,22 @@ ADMIN_MEDIA_PREFIX
|
|||
integration. See the :doc:`Django 1.4 release notes</releases/1.4>` for
|
||||
more information.
|
||||
|
||||
.. setting:: AUTH_PROFILE_MODULE
|
||||
|
||||
AUTH_PROFILE_MODULE
|
||||
-------------------
|
||||
|
||||
.. deprecated:: 1.5
|
||||
With the introduction of :ref:`custom User models <auth-custom-user>`,
|
||||
the use of :setting:`AUTH_PROFILE_MODULE` to define a single profile
|
||||
model is no longer supported. See the
|
||||
:doc:`Django 1.5 release notes</releases/1.5>` for more information.
|
||||
|
||||
Default: Not defined
|
||||
|
||||
The site-specific user profile model used by this site. See
|
||||
:ref:`auth-profiles`.
|
||||
|
||||
.. setting:: IGNORABLE_404_ENDS
|
||||
|
||||
IGNORABLE_404_ENDS
|
||||
|
|
|
|||
|
|
@ -34,6 +34,23 @@ release featuring 2.7 support.
|
|||
What's new in Django 1.5
|
||||
========================
|
||||
|
||||
Configurable User model
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In Django 1.5, you can now use your own model as the store for user-related
|
||||
data. If your project needs a username with more than 30 characters, or if
|
||||
you want to store usernames in a format other than first name/last name, or
|
||||
you want to put custom profile information onto your User object, you can
|
||||
now do so.
|
||||
|
||||
If you have a third-party reusable application that references the User model,
|
||||
you may need to make some changes to the way you reference User instances. You
|
||||
should also document any specific features of the User model that your
|
||||
application relies upon.
|
||||
|
||||
See the :ref:`documentation on custom User models <auth-custom-user>` for
|
||||
more details.
|
||||
|
||||
Support for saving a subset of model's fields
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -277,6 +294,18 @@ Session not saved on 500 responses
|
|||
Django's session middleware will skip saving the session data if the
|
||||
response's status code is 500.
|
||||
|
||||
Email checks on failed admin login
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Prior to Django 1.5, if you attempted to log into the admin interface and
|
||||
mistakenly used your email address instead of your username, the admin
|
||||
interface would provide a warning advising that your email address was
|
||||
not your username. In Django 1.5, the introduction of
|
||||
:ref:`custom User models <auth-custom-user>` has required the removal of this
|
||||
warning. This doesn't change the login behavior of the admin site; it only
|
||||
affects the warning message that is displayed under one particular mode of
|
||||
login failure.
|
||||
|
||||
Changes in tests execution
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -394,3 +423,16 @@ The markup contrib module has been deprecated and will follow an accelerated
|
|||
deprecation schedule. Direct use of python markup libraries or 3rd party tag
|
||||
libraries is preferred to Django maintaining this functionality in the
|
||||
framework.
|
||||
|
||||
:setting:`AUTH_PROFILE_MODULE`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
With the introduction of :ref:`custom User models <auth-custom-user>`, there is
|
||||
no longer any need for a built-in mechanism to store user profile data.
|
||||
|
||||
You can still define user profiles models that have a one-to-one relation with
|
||||
the User model - in fact, for many applications needing to associate data with
|
||||
a User account, this will be an appropriate design pattern to follow. However,
|
||||
the :setting:`AUTH_PROFILE_MODULE` setting, and the
|
||||
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
|
||||
the user profile model, should not be used any longer.
|
||||
|
|
|
|||
|
|
@ -250,6 +250,12 @@ Methods
|
|||
|
||||
.. method:: models.User.get_profile()
|
||||
|
||||
.. deprecated:: 1.5
|
||||
With the introduction of :ref:`custom User models <auth-custom-user>`,
|
||||
the use of :setting:`AUTH_PROFILE_MODULE` to define a single profile
|
||||
model is no longer supported. See the
|
||||
:doc:`Django 1.5 release notes</releases/1.5>` for more information.
|
||||
|
||||
Returns a site-specific profile for this user. Raises
|
||||
:exc:`django.contrib.auth.models.SiteProfileNotAvailable` if the
|
||||
current site doesn't allow profiles, or
|
||||
|
|
@ -582,6 +588,12 @@ correct path and environment for you.
|
|||
Storing additional information about users
|
||||
------------------------------------------
|
||||
|
||||
.. deprecated:: 1.5
|
||||
With the introduction of :ref:`custom User models <auth-custom-user>`,
|
||||
the use of :setting:`AUTH_PROFILE_MODULE` to define a single profile
|
||||
model is no longer supported. See the
|
||||
:doc:`Django 1.5 release notes</releases/1.5>` for more information.
|
||||
|
||||
If you'd like to store additional information related to your users, Django
|
||||
provides a method to specify a site-specific related model -- termed a "user
|
||||
profile" -- for this purpose.
|
||||
|
|
@ -1345,6 +1357,9 @@ Helper functions
|
|||
URL to redirect to after log out. Overrides ``next`` if the given
|
||||
``GET`` parameter is passed.
|
||||
|
||||
|
||||
.. _built-in-auth-forms:
|
||||
|
||||
Built-in forms
|
||||
--------------
|
||||
|
||||
|
|
@ -1735,6 +1750,350 @@ Fields
|
|||
group.permissions.remove(permission, permission, ...)
|
||||
group.permissions.clear()
|
||||
|
||||
.. _auth-custom-user:
|
||||
|
||||
Customizing the User model
|
||||
==========================
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Some kinds of projects may have authentication requirements for which Django's
|
||||
built-in :class:`~django.contrib.auth.models.User` model is not always
|
||||
appropriate. For instance, on some sites it makes more sense to use an email
|
||||
address as your identification token instead of a username.
|
||||
|
||||
Django allows you to override the default User model by providing a value for
|
||||
the :setting:`AUTH_USER_MODEL` setting that references a custom model::
|
||||
|
||||
AUTH_USER_MODEL = 'myapp.MyUser'
|
||||
|
||||
This dotted pair describes the name of the Django app, and the name of the Django
|
||||
model that you wish to use as your User model.
|
||||
|
||||
.. admonition:: Warning
|
||||
|
||||
Changing :setting:`AUTH_USER_MODEL` has a big effect on your database
|
||||
structure. It changes the tables that are available, and it will affect the
|
||||
construction of foreign keys and many-to-many relationships. If you intend
|
||||
to set :setting:`AUTH_USER_MODEL`, you should set it before running
|
||||
``manage.py syncdb`` for the first time.
|
||||
|
||||
If you have an existing project and you want to migrate to using a custom
|
||||
User model, you may need to look into using a migration tool like South_
|
||||
to ease the transition.
|
||||
|
||||
.. _South: http://south.aeracode.org
|
||||
|
||||
Referencing the User model
|
||||
--------------------------
|
||||
|
||||
If you reference :class:`~django.contrib.auth.models.User` directly (for
|
||||
example, by referring to it in a foreign key), your code will not work in
|
||||
projects where the :setting:`AUTH_USER_MODEL` setting has been changed to a
|
||||
different User model.
|
||||
|
||||
Instead of referring to :class:`~django.contrib.auth.models.User` directly,
|
||||
you should reference the user model using
|
||||
:func:`django.contrib.auth.get_user_model()`. This method will return the
|
||||
currently active User model -- the custom User model if one is specified, or
|
||||
:class:`~django.contrib.auth.User` otherwise.
|
||||
|
||||
In relations to the User model, you should specify the custom model using
|
||||
the :setting:`AUTH_USER_MODEL` setting. For example::
|
||||
|
||||
from django.conf import settings
|
||||
from django.db import models
|
||||
|
||||
class Article(models.Model)
|
||||
author = models.ForeignKey(settings.AUTH_USER_MODEL)
|
||||
|
||||
Specifying a custom User model
|
||||
------------------------------
|
||||
|
||||
.. admonition:: Model design considerations
|
||||
|
||||
Think carefully before handling information not directly related to
|
||||
authentication in your custom User Model.
|
||||
|
||||
It may be better to store app-specific user information in a model
|
||||
that has a relation with the User model. That allows each app to specify
|
||||
its own user data requirements without risking conflicts with other
|
||||
apps. On the other hand, queries to retrieve this related information
|
||||
will involve a database join, which may have an effect on performance.
|
||||
|
||||
Django expects your custom User model to meet some minimum requirements.
|
||||
|
||||
1. Your model must have a single unique field that can be used for
|
||||
identification purposes. This can be a username, an email address,
|
||||
or any other unique attribute.
|
||||
|
||||
2. Your model must provide a way to address the user in a "short" and
|
||||
"long" form. The most common interpretation of this would be to use
|
||||
the user's given name as the "short" identifier, and the user's full
|
||||
name as the "long" identifier. However, there are no constraints on
|
||||
what these two methods return - if you want, they can return exactly
|
||||
the same value.
|
||||
|
||||
The easiest way to construct a compliant custom User model is to inherit from
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser`.
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser` provides the core
|
||||
implementation of a `User` model, including hashed passwords and tokenized
|
||||
password resets. You must then provide some key implementation details:
|
||||
|
||||
.. attribute:: User.USERNAME_FIELD
|
||||
|
||||
A string describing the name of the field on the User model that is
|
||||
used as the unique identifier. This will usually be a username of
|
||||
some kind, but it can also be an email address, or any other unique
|
||||
identifier. In the following example, the field `identifier` is used
|
||||
as the identifying field::
|
||||
|
||||
class MyUser(AbstractBaseUser):
|
||||
identfier = models.CharField(max_length=40, unique=True, db_index=True)
|
||||
...
|
||||
USERNAME_FIELD = 'identifier'
|
||||
|
||||
.. attribute:: User.REQUIRED_FIELDS
|
||||
|
||||
A list of the field names that *must* be provided when creating
|
||||
a user. For example, here is the partial definition for a User model
|
||||
that defines two required fields - a date of birth and height::
|
||||
|
||||
class MyUser(AbstractBaseUser):
|
||||
...
|
||||
date_of_birth = models.DateField()
|
||||
height = models.FloatField()
|
||||
...
|
||||
REQUIRED_FIELDS = ['date_of_birth', 'height']
|
||||
|
||||
.. method:: User.get_full_name():
|
||||
|
||||
A longer formal identifier for the user. A common interpretation
|
||||
would be the full name name of the user, but it can be any string that
|
||||
identifies the user.
|
||||
|
||||
.. method:: User.get_short_name():
|
||||
|
||||
A short, informal identifier for the user. A common interpretation
|
||||
would be the first name of the user, but it can be any string that
|
||||
identifies the user in an informal way. It may also return the same
|
||||
value as :meth:`django.contrib.auth.User.get_full_name()`.
|
||||
|
||||
You should also define a custom manager for your User model. If your User
|
||||
model defines `username` and `email` fields the same as Django's default User,
|
||||
you can just install Django's
|
||||
:class:`~django.contrib.auth.models.UserManager`; however, if your User model
|
||||
defines different fields, you will need to define a custom manager that
|
||||
extends :class:`~django.contrib.auth.models.BaseUserManager` providing two
|
||||
additional methods:
|
||||
|
||||
.. method:: UserManager.create_user(username, password=None, **other_fields)
|
||||
|
||||
The prototype of `create_user()` should accept all required fields
|
||||
as arguments. For example, if your user model defines `username`,
|
||||
and `date_of_birth` as required fields, then create_user should be
|
||||
defined as::
|
||||
|
||||
def create_user(self, username, date_of_birth, password=None):
|
||||
# create user here
|
||||
|
||||
.. method:: UserManager.create_superuser(username, password, **other_fields)
|
||||
|
||||
The prototype of `create_superuser()` should accept all required fields
|
||||
as arguments. For example, if your user model defines `username`,
|
||||
and `date_of_birth` as required fields, then create_user should be
|
||||
defined as::
|
||||
|
||||
def create_superuser(self, username, date_of_birth, password):
|
||||
# create superuser here
|
||||
|
||||
Unlike `create_user()`, `create_superuser()` *must* require the caller
|
||||
to provider a password.
|
||||
|
||||
Extending Django's default User
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you're entirely happy with Django's :class:`~django.contrib.auth.models.User`
|
||||
model and you just want to add some additional profile information, you can
|
||||
simply subclass :class:`~django.contrib.auth.models.AbstractUser` and add your
|
||||
custom profile fields.
|
||||
|
||||
Custom users and the built-in auth forms
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As you may expect, built-in Django's :ref:`forms <_built-in-auth-forms>`
|
||||
and :ref:`views <other-built-in-views>` make certain assumptions about
|
||||
the user model that they are working with.
|
||||
|
||||
If your user model doesn't follow the same assumptions, it may be necessary to define
|
||||
a replacement form, and pass that form in as part of the configuration of the
|
||||
auth views.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.UserCreationForm`
|
||||
|
||||
Depends on the :class:`~django.contrib.auth.models.User` model.
|
||||
Must be re-written for any custom user model.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.UserChangeForm`
|
||||
|
||||
Depends on the :class:`~django.contrib.auth.models.User` model.
|
||||
Must be re-written for any custom user model.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.AuthenticationForm`
|
||||
|
||||
Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`,
|
||||
and will adapt to use the field defined in `USERNAME_FIELD`.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.PasswordResetForm`
|
||||
|
||||
Assumes that the user model has an integer primary key, has a field named
|
||||
`email` that can be used to identify the user, and a boolean field
|
||||
named `is_active` to prevent password resets for inactive users.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.SetPasswordForm`
|
||||
|
||||
Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`
|
||||
|
||||
* :class:`~django.contrib.auth.forms.PasswordChangeForm`
|
||||
|
||||
Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`
|
||||
|
||||
* :class:`~django.contrib.auth.forms.AdminPasswordChangeForm`
|
||||
|
||||
Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`
|
||||
|
||||
|
||||
Custom users and django.contrib.admin
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you want your custom User model to also work with Admin, your User model must
|
||||
define some additional attributes and methods. These methods allow the admin to
|
||||
control access of the User to admin content:
|
||||
|
||||
.. attribute:: User.is_staff
|
||||
|
||||
Returns True if the user is allowed to have access to the admin site.
|
||||
|
||||
.. attribute:: User.is_active
|
||||
|
||||
Returns True if the user account is currently active.
|
||||
|
||||
.. method:: User.has_perm(perm, obj=None):
|
||||
|
||||
Returns True if the user has the named permission. If `obj` is
|
||||
provided, the permission needs to be checked against a specific object
|
||||
instance.
|
||||
|
||||
.. method:: User.has_module_perms(app_label):
|
||||
|
||||
Returns True if the user has permission to access models in
|
||||
the given app.
|
||||
|
||||
|
||||
Custom users and Proxy models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One limitation of custom User models is that installing a custom User model
|
||||
will break any proxy model extending :class:`~django.contrib.auth.models.User`.
|
||||
Proxy models must be based on a concrete base class; by defining a custom User
|
||||
model, you remove the ability of Django to reliably identify the base class.
|
||||
|
||||
If your project uses proxy models, you must either modify the proxy to extend
|
||||
the User model that is currently in use in your project, or merge your proxy's
|
||||
behavior into your User subclass.
|
||||
|
||||
A full example
|
||||
--------------
|
||||
|
||||
Here is an example of a full models.py for an admin-compliant custom
|
||||
user app. This user model uses an email address as the username, and has a
|
||||
required date of birth; it provides no permission checking, beyond a simple
|
||||
`admin` flag on the user account. This model would be compatible with all
|
||||
the built-in auth forms and views, except for the User creation forms.
|
||||
|
||||
This code would all live in a ``models.py`` file for a custom
|
||||
authentication app::
|
||||
|
||||
from django.db import models
|
||||
from django.contrib.auth.models import (
|
||||
BaseUserManager, AbstractBaseUser
|
||||
)
|
||||
|
||||
|
||||
class MyUserManager(BaseUserManager):
|
||||
def create_user(self, email, date_of_birth, password=None):
|
||||
"""
|
||||
Creates and saves a User with the given email, date of
|
||||
birth and password.
|
||||
"""
|
||||
if not email:
|
||||
raise ValueError('Users must have an email address')
|
||||
|
||||
user = self.model(
|
||||
email=MyUserManager.normalize_email(email),
|
||||
date_of_birth=date_of_birth,
|
||||
)
|
||||
|
||||
user.set_password(password)
|
||||
user.save(using=self._db)
|
||||
return user
|
||||
|
||||
def create_superuser(self, username, date_of_birth, password):
|
||||
"""
|
||||
Creates and saves a superuser with the given email, date of
|
||||
birth and password.
|
||||
"""
|
||||
u = self.create_user(username,
|
||||
password=password,
|
||||
date_of_birth=date_of_birth
|
||||
)
|
||||
u.is_admin = True
|
||||
u.save(using=self._db)
|
||||
return u
|
||||
|
||||
|
||||
class MyUser(AbstractBaseUser):
|
||||
email = models.EmailField(
|
||||
verbose_name='email address',
|
||||
max_length=255
|
||||
)
|
||||
date_of_birth = models.DateField()
|
||||
is_active = models.BooleanField(default=True)
|
||||
is_admin = models.BooleanField(default=False)
|
||||
|
||||
objects = MyUserManager()
|
||||
|
||||
USERNAME_FIELD = 'email'
|
||||
REQUIRED_FIELDS = ['date_of_birth']
|
||||
|
||||
def get_full_name(self):
|
||||
# The user is identified by their email address
|
||||
return self.email
|
||||
|
||||
def get_short_name(self):
|
||||
# The user is identified by their email address
|
||||
return self.email
|
||||
|
||||
def __unicode__(self):
|
||||
return self.email
|
||||
|
||||
def has_perm(self, perm, obj=None):
|
||||
"Does the user have a specific permission?"
|
||||
# Simplest possible answer: Yes, always
|
||||
return True
|
||||
|
||||
def has_module_perms(self, app_label):
|
||||
"Does the user have permissions to view the app `app_label`?"
|
||||
# Simplest possible answer: Yes, always
|
||||
return True
|
||||
|
||||
@property
|
||||
def is_staff(self):
|
||||
"Is the user a member of staff?"
|
||||
# Simplest possible answer: All admins are staff
|
||||
return self.is_admin
|
||||
|
||||
|
||||
.. _authentication-backends:
|
||||
|
||||
Other authentication sources
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue