<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Customizing authentication in Django — Django 1.5.9 documentation</title>
<link rel="stylesheet" href="../../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../../',
VERSION: '1.5.9',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../../_static/jquery.js"></script>
<script type="text/javascript" src="../../_static/underscore.js"></script>
<script type="text/javascript" src="../../_static/doctools.js"></script>
<link rel="top" title="Django 1.5.9 documentation" href="../../index.html" />
<link rel="up" title="User authentication in Django" href="index.html" />
<link rel="next" title="Django’s cache framework" href="../cache.html" />
<link rel="prev" title="Password management in Django" href="passwords.html" />
<script type="text/javascript" src="../../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../../index.html">Django 1.5.9 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../../index.html">Home</a> |
<a title="Table of contents" href="../../contents.html">Table of contents</a> |
<a title="Global index" href="../../genindex.html">Index</a> |
<a title="Module index" href="../../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="passwords.html" title="Password management in Django">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="../cache.html" title="Django&#8217;s cache framework">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="topics-auth-customizing">
<div class="section" id="s-customizing-authentication-in-django">
<span id="customizing-authentication-in-django"></span><h1>Customizing authentication in Django<a class="headerlink" href="#customizing-authentication-in-django" title="Permalink to this headline">¶</a></h1>
<p>The authentication that comes with Django is good enough for most common cases,
but you may have needs not met by the out-of-the-box defaults. To customize
authentication to your projects needs involves understanding what points of the
provided system are extendible or replaceable. This document provides details
about how the auth system can be customized.</p>
<p><a class="reference internal" href="#authentication-backends"><em>Authentication backends</em></a> provide an extensible
system for when a username and password stored with the User model need
to be authenticated against a different service than Django’s default.</p>
<p>You can give your models <a class="reference internal" href="#custom-permissions"><em>custom permissions</em></a> that can be
checked through Django’s authorization system.</p>
<p>You can <a class="reference internal" href="#extending-user"><em>extend</em></a> the default User model, or <a class="reference internal" href="#auth-custom-user"><em>substitute</em></a> a completely customized model.</p>
<div class="section" id="s-other-authentication-sources">
<span id="s-authentication-backends"></span><span id="other-authentication-sources"></span><span id="authentication-backends"></span><h2>Other authentication sources<a class="headerlink" href="#other-authentication-sources" title="Permalink to this headline">¶</a></h2>
<p>There may be times you have the need to hook into another authentication source
– that is, another source of usernames and passwords or authentication
methods.</p>
<p>For example, your company may already have an LDAP setup that stores a username
and password for every employee. It’d be a hassle for both the network
administrator and the users themselves if users had separate accounts in LDAP
and the Django-based applications.</p>
<p>So, to handle situations like this, the Django authentication system lets you
plug in other authentication sources. You can override Django’s default
database-based scheme, or you can use the default system in tandem with other
systems.</p>
<p>See the <a class="reference internal" href="../../ref/contrib/auth.html#authentication-backends-reference"><em>authentication backend reference</em></a> for information on the authentication
backends included with Django.</p>
<div class="section" id="s-specifying-authentication-backends">
<span id="specifying-authentication-backends"></span><h3>Specifying authentication backends<a class="headerlink" href="#specifying-authentication-backends" title="Permalink to this headline">¶</a></h3>
<p>Behind the scenes, Django maintains a list of “authentication backends” that it
checks for authentication. When somebody calls
<a class="reference internal" href="default.html#django.contrib.auth.authenticate" title="django.contrib.auth.authenticate"><tt class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.authenticate()</span></tt></a> – as described in <a class="reference internal" href="default.html#how-to-log-a-user-in"><em>How to log
a user in</em></a> – Django tries authenticating across
all of its authentication backends. If the first authentication method fails,
Django tries the second one, and so on, until all backends have been attempted.</p>
<p>The list of authentication backends to use is specified in the
<a class="reference internal" href="../../ref/settings.html#std:setting-AUTHENTICATION_BACKENDS"><tt class="xref std std-setting docutils literal"><span class="pre">AUTHENTICATION_BACKENDS</span></tt></a> setting. This should be a tuple of Python
path names that point to Python classes that know how to authenticate. These
classes can be anywhere on your Python path.</p>
<p>By default, <a class="reference internal" href="../../ref/settings.html#std:setting-AUTHENTICATION_BACKENDS"><tt class="xref std std-setting docutils literal"><span class="pre">AUTHENTICATION_BACKENDS</span></tt></a> is set to:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="p">(</span><span class="s">'django.contrib.auth.backends.ModelBackend'</span><span class="p">,)</span>
</pre></div>
</div>
<p>That’s the basic authentication backend that checks the Django users database
and queries the built-in permissions. It does not provide protection against
brute force attacks via any rate limiting mechanism. You may either implement
your own rate limiting mechanism in a custom auth backend, or use the
mechanisms provided by most Web servers.</p>
<p>The order of <a class="reference internal" href="../../ref/settings.html#std:setting-AUTHENTICATION_BACKENDS"><tt class="xref std std-setting docutils literal"><span class="pre">AUTHENTICATION_BACKENDS</span></tt></a> matters, so if the same
username and password is valid in multiple backends, Django will stop
processing at the first positive match.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Once a user has authenticated, Django stores which backend was used to
authenticate the user in the user’s session, and re-uses the same backend
for the duration of that session whenever access to the currently
authenticated user is needed. This effectively means that authentication
sources are cached on a per-session basis, so if you change
<a class="reference internal" href="../../ref/settings.html#std:setting-AUTHENTICATION_BACKENDS"><tt class="xref std std-setting docutils literal"><span class="pre">AUTHENTICATION_BACKENDS</span></tt></a>, you’ll need to clear out session data if
you need to force users to re-authenticate using different methods. A simple
way to do that is simply to execute <tt class="docutils literal"><span class="pre">Session.objects.all().delete()</span></tt>.</p>
</div>
</div>
<div class="section" id="s-writing-an-authentication-backend">
<span id="writing-an-authentication-backend"></span><h3>Writing an authentication backend<a class="headerlink" href="#writing-an-authentication-backend" title="Permalink to this headline">¶</a></h3>
<p>An authentication backend is a class that implements two required methods:
<tt class="docutils literal"><span class="pre">get_user(user_id)</span></tt> and <tt class="docutils literal"><span class="pre">authenticate(**credentials)</span></tt>, as well as a set of
optional permission related <a class="reference internal" href="#authorization-methods"><em>authorization methods</em></a>.</p>
<p>The <tt class="docutils literal"><span class="pre">get_user</span></tt> method takes a <tt class="docutils literal"><span class="pre">user_id</span></tt> – which could be a username,
database ID or whatever, but has to be the primary key of your <tt class="docutils literal"><span class="pre">User</span></tt> object
– and returns a <tt class="docutils literal"><span class="pre">User</span></tt> object.</p>
<p>The <tt class="docutils literal"><span class="pre">authenticate</span></tt> method takes credentials as keyword arguments. Most of
the time, it’ll just look like this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">MyBackend</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">authenticate</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">username</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span> <span class="n">password</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="c"># Check the username/password and return a User.</span>
<span class="o">...</span>
</pre></div>
</div>
<p>But it could also authenticate a token, like so:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">MyBackend</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">authenticate</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">token</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="c"># Check the token and return a User.</span>
<span class="o">...</span>
</pre></div>
</div>
<p>Either way, <tt class="docutils literal"><span class="pre">authenticate</span></tt> should check the credentials it gets, and it
should return a <tt class="docutils literal"><span class="pre">User</span></tt> object that matches those credentials, if the
credentials are valid. If they’re not valid, it should return <tt class="docutils literal"><span class="pre">None</span></tt>.</p>
<p>The Django admin system is tightly coupled to the Django <tt class="docutils literal"><span class="pre">User</span></tt> object
described at the beginning of this document. For now, the best way to deal with
this is to create a Django <tt class="docutils literal"><span class="pre">User</span></tt> object for each user that exists for your
backend (e.g., in your LDAP directory, your external SQL database, etc.) You
can either write a script to do this in advance, or your <tt class="docutils literal"><span class="pre">authenticate</span></tt>
method can do it the first time a user logs in.</p>
<p>Here’s an example backend that authenticates against a username and password
variable defined in your <tt class="docutils literal"><span class="pre">settings.py</span></tt> file and creates a Django <tt class="docutils literal"><span class="pre">User</span></tt>
object the first time a user authenticates:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.models</span> <span class="kn">import</span> <span class="n">User</span><span class="p">,</span> <span class="n">check_password</span>
<span class="k">class</span> <span class="nc">SettingsBackend</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="sd">"""</span>
<span class="sd"> Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.</span>
<span class="sd"> Use the login name, and a hash of the password. For example:</span>
<span class="sd"> ADMIN_LOGIN = 'admin'</span>
<span class="sd"> ADMIN_PASSWORD = 'sha1$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de'</span>
<span class="sd"> """</span>
<span class="k">def</span> <span class="nf">authenticate</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">username</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span> <span class="n">password</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="n">login_valid</span> <span class="o">=</span> <span class="p">(</span><span class="n">settings</span><span class="o">.</span><span class="n">ADMIN_LOGIN</span> <span class="o">==</span> <span class="n">username</span><span class="p">)</span>
<span class="n">pwd_valid</span> <span class="o">=</span> <span class="n">check_password</span><span class="p">(</span><span class="n">password</span><span class="p">,</span> <span class="n">settings</span><span class="o">.</span><span class="n">ADMIN_PASSWORD</span><span class="p">)</span>
<span class="k">if</span> <span class="n">login_valid</span> <span class="ow">and</span> <span class="n">pwd_valid</span><span class="p">:</span>
<span class="k">try</span><span class="p">:</span>
<span class="n">user</span> <span class="o">=</span> <span class="n">User</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">username</span><span class="o">=</span><span class="n">username</span><span class="p">)</span>
<span class="k">except</span> <span class="n">User</span><span class="o">.</span><span class="n">DoesNotExist</span><span class="p">:</span>
<span class="c"># Create a new user. Note that we can set password</span>
<span class="c"># to anything, because it won't be checked; the password</span>
<span class="c"># from settings.py will.</span>
<span class="n">user</span> <span class="o">=</span> <span class="n">User</span><span class="p">(</span><span class="n">username</span><span class="o">=</span><span class="n">username</span><span class="p">,</span> <span class="n">password</span><span class="o">=</span><span class="s">'get from settings.py'</span><span class="p">)</span>
<span class="n">user</span><span class="o">.</span><span class="n">is_staff</span> <span class="o">=</span> <span class="bp">True</span>
<span class="n">user</span><span class="o">.</span><span class="n">is_superuser</span> <span class="o">=</span> <span class="bp">True</span>
<span class="n">user</span><span class="o">.</span><span class="n">save</span><span class="p">()</span>
<span class="k">return</span> <span class="n">user</span>
<span class="k">return</span> <span class="bp">None</span>
<span class="k">def</span> <span class="nf">get_user</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">user_id</span><span class="p">):</span>
<span class="k">try</span><span class="p">:</span>
<span class="k">return</span> <span class="n">User</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">pk</span><span class="o">=</span><span class="n">user_id</span><span class="p">)</span>
<span class="k">except</span> <span class="n">User</span><span class="o">.</span><span class="n">DoesNotExist</span><span class="p">:</span>
<span class="k">return</span> <span class="bp">None</span>
</pre></div>
</div>
</div>
<div class="section" id="s-handling-authorization-in-custom-backends">
<span id="s-authorization-methods"></span><span id="handling-authorization-in-custom-backends"></span><span id="authorization-methods"></span><h3>Handling authorization in custom backends<a class="headerlink" href="#handling-authorization-in-custom-backends" title="Permalink to this headline">¶</a></h3>
<p>Custom auth backends can provide their own permissions.</p>
<p>The user model will delegate permission lookup functions
(<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.get_group_permissions" title="django.contrib.auth.models.User.get_group_permissions"><tt class="xref py py-meth docutils literal"><span class="pre">get_group_permissions()</span></tt></a>,
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.get_all_permissions" title="django.contrib.auth.models.User.get_all_permissions"><tt class="xref py py-meth docutils literal"><span class="pre">get_all_permissions()</span></tt></a>,
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.has_perm" title="django.contrib.auth.models.User.has_perm"><tt class="xref py py-meth docutils literal"><span class="pre">has_perm()</span></tt></a>, and
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.has_module_perms" title="django.contrib.auth.models.User.has_module_perms"><tt class="xref py py-meth docutils literal"><span class="pre">has_module_perms()</span></tt></a>) to any
authentication backend that implements these functions.</p>
<p>The permissions given to the user will be the superset of all permissions
returned by all backends. That is, Django grants a permission to a user that
any one backend grants.</p>
<p>The simple backend above could implement permissions for the magic admin
fairly simply:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">SettingsBackend</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="o">...</span>
<span class="k">def</span> <span class="nf">has_perm</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">user_obj</span><span class="p">,</span> <span class="n">perm</span><span class="p">,</span> <span class="n">obj</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="k">if</span> <span class="n">user_obj</span><span class="o">.</span><span class="n">username</span> <span class="o">==</span> <span class="n">settings</span><span class="o">.</span><span class="n">ADMIN_LOGIN</span><span class="p">:</span>
<span class="k">return</span> <span class="bp">True</span>
<span class="k">else</span><span class="p">:</span>
<span class="k">return</span> <span class="bp">False</span>
</pre></div>
</div>
<p>This gives full permissions to the user granted access in the above example.
Notice that in addition to the same arguments given to the associated
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">django.contrib.auth.models.User</span></tt></a> functions, the backend auth functions
all take the user object, which may be an anonymous user, as an argument.</p>
<p>A full authorization implementation can be found in the <tt class="docutils literal"><span class="pre">ModelBackend</span></tt> class
in <a class="reference external" href="https://github.com/django/django/blob/master/django/contrib/auth/backends.py">django/contrib/auth/backends.py</a>, which is the default backend and queries
the <tt class="docutils literal"><span class="pre">auth_permission</span></tt> table most of the time. If you wish to provide
custom behavior for only part of the backend API, you can take advantage of
Python inheritance and subclass <tt class="docutils literal"><span class="pre">ModelBackend</span></tt> instead of implementing the
complete API in a custom backend.</p>
<div class="section" id="s-authorization-for-anonymous-users">
<span id="s-anonymous-auth"></span><span id="authorization-for-anonymous-users"></span><span id="anonymous-auth"></span><h4>Authorization for anonymous users<a class="headerlink" href="#authorization-for-anonymous-users" title="Permalink to this headline">¶</a></h4>
<p>An anonymous user is one that is not authenticated i.e. they have provided no
valid authentication details. However, that does not necessarily mean they are
not authorized to do anything. At the most basic level, most Web sites
authorize anonymous users to browse most of the site, and many allow anonymous
posting of comments etc.</p>
<p>Django’s permission framework does not have a place to store permissions for
anonymous users. However, the user object passed to an authentication backend
may be an <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.AnonymousUser" title="django.contrib.auth.models.AnonymousUser"><tt class="xref py py-class docutils literal"><span class="pre">django.contrib.auth.models.AnonymousUser</span></tt></a> object, allowing
the backend to specify custom authorization behavior for anonymous users. This
is especially useful for the authors of re-usable apps, who can delegate all
questions of authorization to the auth backend, rather than needing settings,
for example, to control anonymous access.</p>
</div>
<div class="section" id="s-authorization-for-inactive-users">
<span id="s-inactive-auth"></span><span id="authorization-for-inactive-users"></span><span id="inactive-auth"></span><h4>Authorization for inactive users<a class="headerlink" href="#authorization-for-inactive-users" title="Permalink to this headline">¶</a></h4>
<p>An inactive user is a one that is authenticated but has its attribute
<tt class="docutils literal"><span class="pre">is_active</span></tt> set to <tt class="docutils literal"><span class="pre">False</span></tt>. However this does not mean they are not
authorized to do anything. For example they are allowed to activate their
account.</p>
<p>The support for anonymous users in the permission system allows for a scenario
where anonymous users have permissions to do something while inactive
authenticated users do not.</p>
<p>Do not forget to test for the <tt class="docutils literal"><span class="pre">is_active</span></tt> attribute of the user in your own
backend permission methods.</p>
</div>
<div class="section" id="s-handling-object-permissions">
<span id="handling-object-permissions"></span><h4>Handling object permissions<a class="headerlink" href="#handling-object-permissions" title="Permalink to this headline">¶</a></h4>
<p>Django’s permission framework has a foundation for object permissions, though
there is no implementation for it in the core. That means that checking for
object permissions will always return <tt class="docutils literal"><span class="pre">False</span></tt> or an empty list (depending on
the check performed). An authentication backend will receive the keyword
parameters <tt class="docutils literal"><span class="pre">obj</span></tt> and <tt class="docutils literal"><span class="pre">user_obj</span></tt> for each object related authorization
method and can return the object level permission as appropriate.</p>
</div>
</div>
</div>
<div class="section" id="s-custom-permissions">
<span id="s-id1"></span><span id="custom-permissions"></span><span id="id1"></span><h2>Custom permissions<a class="headerlink" href="#custom-permissions" title="Permalink to this headline">¶</a></h2>
<p>To create custom permissions for a given model object, use the <tt class="docutils literal"><span class="pre">permissions</span></tt>
<a class="reference internal" href="../db/models.html#meta-options"><em>model Meta attribute</em></a>.</p>
<p>This example Task model creates three custom permissions, i.e., actions users
can or cannot do with Task instances, specific to your application:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Task</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="o">...</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">permissions</span> <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="s">"view_task"</span><span class="p">,</span> <span class="s">"Can see available tasks"</span><span class="p">),</span>
<span class="p">(</span><span class="s">"change_task_status"</span><span class="p">,</span> <span class="s">"Can change the status of tasks"</span><span class="p">),</span>
<span class="p">(</span><span class="s">"close_task"</span><span class="p">,</span> <span class="s">"Can remove a task by setting its status as closed"</span><span class="p">),</span>
<span class="p">)</span>
</pre></div>
</div>
<p>The only thing this does is create those extra permissions when you run
<a class="reference internal" href="../../ref/django-admin.html#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">manage.py</span> <span class="pre">syncdb</span></tt></a>. Your code is in charge of checking the
value of these permissions when a user is trying to access the functionality
provided by the application (viewing tasks, changing the status of tasks,
closing tasks.) Continuing the above example, the following checks if a user may
view tasks:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">user</span><span class="o">.</span><span class="n">has_perm</span><span class="p">(</span><span class="s">'app.view_task'</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-extending-the-existing-user-model">
<span id="s-extending-user"></span><span id="extending-the-existing-user-model"></span><span id="extending-user"></span><h2>Extending the existing User model<a class="headerlink" href="#extending-the-existing-user-model" title="Permalink to this headline">¶</a></h2>
<p>There are two ways to extend the default
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> model without substituting your own
model. If the changes you need are purely behavioral, and don’t require any
change to what is stored in the database, you can create a <a class="reference internal" href="../db/models.html#proxy-models"><em>proxy model</em></a> based on <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a>. This
allows for any of the features offered by proxy models including default
ordering, custom managers, or custom model methods.</p>
<p>If you wish to store information related to <tt class="docutils literal"><span class="pre">User</span></tt>, you can use a <a class="reference internal" href="../../ref/models/fields.html#ref-onetoone"><em>one-to-one
relationship</em></a> to a model containing the fields for
additional information. This one-to-one model is often called a profile model,
as it might store non-auth related information about a site user. For example
you might create an Employee model:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.contrib.auth.models</span> <span class="kn">import</span> <span class="n">User</span>
<span class="k">class</span> <span class="nc">Employee</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">user</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">OneToOneField</span><span class="p">(</span><span class="n">User</span><span class="p">)</span>
<span class="n">department</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">100</span><span class="p">)</span>
</pre></div>
</div>
<p>Assuming an existing Employee Fred Smith who has both a User and Employee
model, you can access the related information using Django’s standard related
model conventions:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="n">u</span> <span class="o">=</span> <span class="n">User</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">username</span><span class="o">=</span><span class="s">'fsmith'</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">freds_department</span> <span class="o">=</span> <span class="n">u</span><span class="o">.</span><span class="n">employee</span><span class="o">.</span><span class="n">department</span>
</pre></div>
</div>
<p>To add a profile model’s fields to the user page in the admin, define an
<a class="reference internal" href="../../ref/contrib/admin/index.html#django.contrib.admin.InlineModelAdmin" title="django.contrib.admin.InlineModelAdmin"><tt class="xref py py-class docutils literal"><span class="pre">InlineModelAdmin</span></tt></a> (for this example, we’ll use a
<a class="reference internal" href="../../ref/contrib/admin/index.html#django.contrib.admin.StackedInline" title="django.contrib.admin.StackedInline"><tt class="xref py py-class docutils literal"><span class="pre">StackedInline</span></tt></a>) in your app’s <tt class="docutils literal"><span class="pre">admin.py</span></tt> and
add it to a <tt class="docutils literal"><span class="pre">UserAdmin</span></tt> class which is registered with the
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> class:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">admin</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.admin</span> <span class="kn">import</span> <span class="n">UserAdmin</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.models</span> <span class="kn">import</span> <span class="n">User</span>
<span class="kn">from</span> <span class="nn">my_user_profile_app.models</span> <span class="kn">import</span> <span class="n">Employee</span>
<span class="c"># Define an inline admin descriptor for Employee model</span>
<span class="c"># which acts a bit like a singleton</span>
<span class="k">class</span> <span class="nc">EmployeeInline</span><span class="p">(</span><span class="n">admin</span><span class="o">.</span><span class="n">StackedInline</span><span class="p">):</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">Employee</span>
<span class="n">can_delete</span> <span class="o">=</span> <span class="bp">False</span>
<span class="n">verbose_name_plural</span> <span class="o">=</span> <span class="s">'employee'</span>
<span class="c"># Define a new User admin</span>
<span class="k">class</span> <span class="nc">UserAdmin</span><span class="p">(</span><span class="n">UserAdmin</span><span class="p">):</span>
<span class="n">inlines</span> <span class="o">=</span> <span class="p">(</span><span class="n">EmployeeInline</span><span class="p">,</span> <span class="p">)</span>
<span class="c"># Re-register UserAdmin</span>
<span class="n">admin</span><span class="o">.</span><span class="n">site</span><span class="o">.</span><span class="n">unregister</span><span class="p">(</span><span class="n">User</span><span class="p">)</span>
<span class="n">admin</span><span class="o">.</span><span class="n">site</span><span class="o">.</span><span class="n">register</span><span class="p">(</span><span class="n">User</span><span class="p">,</span> <span class="n">UserAdmin</span><span class="p">)</span>
</pre></div>
</div>
<p>These profile models are not special in any way - they are just Django models that
happen to have a one-to-one link with a User model. As such, they do not get
auto created when a user is created, but
a <a class="reference internal" href="../../ref/signals.html#django.db.models.signals.post_save" title="django.db.models.signals.post_save"><tt class="xref py py-attr docutils literal"><span class="pre">django.db.models.signals.post_save</span></tt></a> could be used to create or update
related models as appropriate.</p>
<p>Note that using related models results in additional queries or joins to
retrieve the related data, and depending on your needs substituting the User
model and adding the related fields may be your better option. However
existing links to the default User model within your project’s apps may justify
the extra database load.</p>
<div class="deprecated" id="auth-profiles">
<span class="title">Deprecated in Django 1.5:</span> With the introduction of <a class="reference internal" href="#auth-custom-user"><em>custom User models</em></a>,
the use of <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a> to define a single profile
model is no longer supported. See the
<a class="reference internal" href="../../releases/1.5.html"><em>Django 1.5 release notes</em></a> for more information.</div>
<p>Prior to 1.5, a single profile model could be specified site-wide with the
setting <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a> with a string consisting of the
following items, separated by a dot:</p>
<ol class="arabic simple">
<li>The name of the application (case sensitive) in which the user
profile model is defined (in other words, the
name which was passed to <a class="reference internal" href="../../ref/django-admin.html#django-admin-startapp"><tt class="xref std std-djadmin docutils literal"><span class="pre">manage.py</span> <span class="pre">startapp</span></tt></a> to create
the application).</li>
<li>The name of the model (not case sensitive) class.</li>
</ol>
<p>For example, if the profile model was a class named <tt class="docutils literal"><span class="pre">UserProfile</span></tt> and was
defined inside an application named <tt class="docutils literal"><span class="pre">accounts</span></tt>, the appropriate setting would
be:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">AUTH_PROFILE_MODULE</span> <span class="o">=</span> <span class="s">'accounts.UserProfile'</span>
</pre></div>
</div>
<p>When a user profile model has been defined and specified in this manner, each
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> object will have a method –
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.get_profile" title="django.contrib.auth.models.User.get_profile"><tt class="xref py py-class docutils literal"><span class="pre">get_profile()</span></tt></a> – which returns the
instance of the user profile model associated with that
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a>.</p>
<p>The method <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.get_profile" title="django.contrib.auth.models.User.get_profile"><tt class="xref py py-class docutils literal"><span class="pre">get_profile()</span></tt></a>
does not create a profile if one does not exist.</p>
</div>
<div class="section" id="s-substituting-a-custom-user-model">
<span id="s-auth-custom-user"></span><span id="substituting-a-custom-user-model"></span><span id="auth-custom-user"></span><h2>Substituting a custom User model<a class="headerlink" href="#substituting-a-custom-user-model" title="Permalink to this headline">¶</a></h2>
<div class="versionadded">
<span class="title">New in Django 1.5.</span> </div>
<p>Some kinds of projects may have authentication requirements for which Django’s
built-in <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> 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.</p>
<p>Django allows you to override the default User model by providing a value for
the <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_USER_MODEL"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></tt></a> setting that references a custom model:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">AUTH_USER_MODEL</span> <span class="o">=</span> <span class="s">'myapp.MyUser'</span>
</pre></div>
</div>
<p>This dotted pair describes the name of the Django app (which must be in your
<a class="reference internal" href="../../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>), and the name of the Django model that you wish to
use as your User model.</p>
<div class="admonition-warning admonition">
<p class="first admonition-title">Warning</p>
<p>Changing <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_USER_MODEL"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></tt></a> 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 <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_USER_MODEL"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></tt></a>, you should set it before running
<tt class="docutils literal"><span class="pre">manage.py</span> <span class="pre">syncdb</span></tt> for the first time.</p>
<p class="last">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 <a class="reference external" href="http://south.aeracode.org">South</a>
to ease the transition.</p>
</div>
<div class="section" id="s-referencing-the-user-model">
<span id="referencing-the-user-model"></span><h3>Referencing the User model<a class="headerlink" href="#referencing-the-user-model" title="Permalink to this headline">¶</a></h3>
<p>If you reference <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> directly (for
example, by referring to it in a foreign key), your code will not work in
projects where the <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_USER_MODEL"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></tt></a> setting has been changed to a
different User model.</p>
<dl class="function">
<dt id="django.contrib.auth.get_user_model">
<tt class="descname">get_user_model</tt>()<a class="headerlink" href="#django.contrib.auth.get_user_model" title="Permalink to this definition">¶</a></dt>
<dd><p>Instead of referring to <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> directly,
you should reference the user model using
<tt class="docutils literal"><span class="pre">django.contrib.auth.get_user_model()</span></tt>. This method will return the
currently active User model – the custom User model if one is specified, or
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> otherwise.</p>
<p>When you define a foreign key or many-to-many relations to the User model,
you should specify the custom model using the <a class="reference internal" href="../../ref/settings.html#std:setting-AUTH_USER_MODEL"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></tt></a>
setting. For example:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
<span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">models</span>
<span class="k">class</span> <span class="nc">Article</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">author</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">ForeignKey</span><span class="p">(</span><span class="n">settings</span><span class="o">.</span><span class="n">AUTH_USER_MODEL</span><span class="p">)</span>
</pre></div>
</div>
</dd></dl>
</div>
<div class="section" id="s-specifying-a-custom-user-model">
<span id="specifying-a-custom-user-model"></span><h3>Specifying a custom User model<a class="headerlink" href="#specifying-a-custom-user-model" title="Permalink to this headline">¶</a></h3>
<div class="admonition-model-design-considerations admonition">
<p class="first admonition-title">Model design considerations</p>
<p>Think carefully before handling information not directly related to
authentication in your custom User Model.</p>
<p class="last">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.</p>
</div>
<p>Django expects your custom User model to meet some minimum requirements.</p>
<ol class="arabic simple">
<li>Your model must have an integer primary key.</li>
<li>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.</li>
<li>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.</li>
</ol>
<p>The easiest way to construct a compliant custom User model is to inherit from
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a>.
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a> provides the core
implementation of a <tt class="docutils literal"><span class="pre">User</span></tt> model, including hashed passwords and tokenized
password resets. You must then provide some key implementation details:</p>
<dl class="class">
<dt id="django.contrib.auth.models.CustomUser">
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">CustomUser</tt><a class="headerlink" href="#django.contrib.auth.models.CustomUser" title="Permalink to this definition">¶</a></dt>
<dd><dl class="attribute">
<dt id="django.contrib.auth.models.CustomUser.USERNAME_FIELD">
<tt class="descname">USERNAME_FIELD</tt><a class="headerlink" href="#django.contrib.auth.models.CustomUser.USERNAME_FIELD" title="Permalink to this definition">¶</a></dt>
<dd><p>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. The field <em>must</em> be unique (i.e., have <tt class="docutils literal"><span class="pre">unique=True</span></tt>
set in its definition).</p>
<p>In the following example, the field <tt class="docutils literal"><span class="pre">identifier</span></tt> is used
as the identifying field:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">MyUser</span><span class="p">(</span><span class="n">AbstractBaseUser</span><span class="p">):</span>
<span class="n">identifier</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">,</span> <span class="n">unique</span><span class="o">=</span><span class="bp">True</span><span class="p">,</span> <span class="n">db_index</span><span class="o">=</span><span class="bp">True</span><span class="p">)</span>
<span class="o">...</span>
<span class="n">USERNAME_FIELD</span> <span class="o">=</span> <span class="s">'identifier'</span>
</pre></div>
</div>
</dd></dl>
<dl class="attribute">
<dt id="django.contrib.auth.models.CustomUser.REQUIRED_FIELDS">
<tt class="descname">REQUIRED_FIELDS</tt><a class="headerlink" href="#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS" title="Permalink to this definition">¶</a></dt>
<dd><p>A list of the field names that will be prompted for when creating a
user via the <a class="reference internal" href="../../ref/django-admin.html#django-admin-createsuperuser"><tt class="xref std std-djadmin docutils literal"><span class="pre">createsuperuser</span></tt></a> management command. The user
will be prompted to supply a value for each of these fields. It must
include any field for which <a class="reference internal" href="../../ref/models/fields.html#django.db.models.Field.blank" title="django.db.models.Field.blank"><tt class="xref py py-attr docutils literal"><span class="pre">blank</span></tt></a> is
<tt class="docutils literal"><span class="pre">False</span></tt> or undefined and may include additional fields you want
prompted for when a user is created interactively. However, it will not
work for <a class="reference internal" href="../../ref/models/fields.html#django.db.models.ForeignKey" title="django.db.models.ForeignKey"><tt class="xref py py-class docutils literal"><span class="pre">ForeignKey</span></tt></a> fields.
<tt class="docutils literal"><span class="pre">REQUIRED_FIELDS</span></tt> has no effect in other parts of Django, like
creating a user in the admin.</p>
<p>For example, here is the partial definition for a <tt class="docutils literal"><span class="pre">User</span></tt> model that
defines two required fields - a date of birth and height:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">MyUser</span><span class="p">(</span><span class="n">AbstractBaseUser</span><span class="p">):</span>
<span class="o">...</span>
<span class="n">date_of_birth</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">DateField</span><span class="p">()</span>
<span class="n">height</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">FloatField</span><span class="p">()</span>
<span class="o">...</span>
<span class="n">REQUIRED_FIELDS</span> <span class="o">=</span> <span class="p">[</span><span class="s">'date_of_birth'</span><span class="p">,</span> <span class="s">'height'</span><span class="p">]</span>
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><tt class="docutils literal"><span class="pre">REQUIRED_FIELDS</span></tt> must contain all required fields on your
<tt class="docutils literal"><span class="pre">User</span></tt> model, but should <em>not</em> contain the <tt class="docutils literal"><span class="pre">USERNAME_FIELD</span></tt> or
<tt class="docutils literal"><span class="pre">password</span></tt> as these fields will always be prompted for.</p>
</div>
</dd></dl>
<dl class="attribute">
<dt id="django.contrib.auth.models.CustomUser.is_active">
<tt class="descname">is_active</tt><a class="headerlink" href="#django.contrib.auth.models.CustomUser.is_active" title="Permalink to this definition">¶</a></dt>
<dd><p>A boolean attribute that indicates whether the user is considered
“active”. This attribute is provided as an attribute on
<tt class="docutils literal"><span class="pre">AbstractBaseUser</span></tt> defaulting to <tt class="docutils literal"><span class="pre">True</span></tt>. How you choose to
implement it will depend on the details of your chosen auth backends.
See the documentation of the <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.is_active" title="django.contrib.auth.models.User.is_active"><tt class="xref py py-attr docutils literal"><span class="pre">attribute</span> <span class="pre">on</span> <span class="pre">the</span> <span class="pre">builtin</span> <span class="pre">user</span> <span class="pre">model</span></tt></a> for details.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.CustomUser.get_full_name">
<tt class="descname">get_full_name</tt>()<a class="headerlink" href="#django.contrib.auth.models.CustomUser.get_full_name" title="Permalink to this definition">¶</a></dt>
<dd><p>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.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.CustomUser.get_short_name">
<tt class="descname">get_short_name</tt>()<a class="headerlink" href="#django.contrib.auth.models.CustomUser.get_short_name" title="Permalink to this definition">¶</a></dt>
<dd><p>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 <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User.get_full_name" title="django.contrib.auth.models.User.get_full_name"><tt class="xref py py-meth docutils literal"><span class="pre">django.contrib.auth.models.User.get_full_name()</span></tt></a>.</p>
</dd></dl>
</dd></dl>
<p>The following methods are available on any subclass of
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a>:</p>
<dl class="class">
<dt id="django.contrib.auth.models.AbstractBaseUser">
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">AbstractBaseUser</tt><a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser" title="Permalink to this definition">¶</a></dt>
<dd><dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.get_username">
<tt class="descname">get_username</tt>()<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.get_username" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns the value of the field nominated by <tt class="docutils literal"><span class="pre">USERNAME_FIELD</span></tt>.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.is_anonymous">
<tt class="descname">is_anonymous</tt>()<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.is_anonymous" title="Permalink to this definition">¶</a></dt>
<dd><p>Always returns <tt class="docutils literal"><span class="pre">False</span></tt>. This is a way of differentiating
from <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.AnonymousUser" title="django.contrib.auth.models.AnonymousUser"><tt class="xref py py-class docutils literal"><span class="pre">AnonymousUser</span></tt></a> objects.
Generally, you should prefer using
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser.is_authenticated" title="django.contrib.auth.models.AbstractBaseUser.is_authenticated"><tt class="xref py py-meth docutils literal"><span class="pre">is_authenticated()</span></tt></a> to this
method.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.is_authenticated">
<tt class="descname">is_authenticated</tt>()<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.is_authenticated" title="Permalink to this definition">¶</a></dt>
<dd><p>Always returns <tt class="docutils literal"><span class="pre">True</span></tt>. This is a way to tell if the user has been
authenticated. This does not imply any permissions, and doesn’t check
if the user is active - it only indicates that the user has provided a
valid username and password.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.set_password">
<tt class="descname">set_password</tt>(<em>raw_password</em>)<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.set_password" title="Permalink to this definition">¶</a></dt>
<dd><p>Sets the user’s password to the given raw string, taking care of the
password hashing. Doesn’t save the
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a> object.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.check_password">
<tt class="descname">check_password</tt>(<em>raw_password</em>)<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.check_password" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the given raw string is the correct password for
the user. (This takes care of the password hashing in making the
comparison.)</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.set_unusable_password">
<tt class="descname">set_unusable_password</tt>()<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.set_unusable_password" title="Permalink to this definition">¶</a></dt>
<dd><p>Marks the user as having no password set. This isn’t the same as
having a blank string for a password.
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser.check_password" title="django.contrib.auth.models.AbstractBaseUser.check_password"><tt class="xref py py-meth docutils literal"><span class="pre">check_password()</span></tt></a> for this user
will never return <tt class="docutils literal"><span class="pre">True</span></tt>. Doesn’t save the
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a> object.</p>
<p>You may need this if authentication for your application takes place
against an existing external source such as an LDAP directory.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.AbstractBaseUser.has_usable_password">
<tt class="descname">has_usable_password</tt>()<a class="headerlink" href="#django.contrib.auth.models.AbstractBaseUser.has_usable_password" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">False</span></tt> if
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser.set_unusable_password" title="django.contrib.auth.models.AbstractBaseUser.set_unusable_password"><tt class="xref py py-meth docutils literal"><span class="pre">set_unusable_password()</span></tt></a> has
been called for this user.</p>
</dd></dl>
</dd></dl>
<p>You should also define a custom manager for your <tt class="docutils literal"><span class="pre">User</span></tt> model. If your
<tt class="docutils literal"><span class="pre">User</span></tt> model defines <tt class="docutils literal"><span class="pre">username</span></tt>, <tt class="docutils literal"><span class="pre">email</span></tt>, <tt class="docutils literal"><span class="pre">is_staff</span></tt>, <tt class="docutils literal"><span class="pre">is_active</span></tt>,
<tt class="docutils literal"><span class="pre">is_superuser</span></tt>, <tt class="docutils literal"><span class="pre">last_login</span></tt>, and <tt class="docutils literal"><span class="pre">date_joined</span></tt> fields the same as
Django’s default <tt class="docutils literal"><span class="pre">User</span></tt>, you can just install Django’s
<a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.UserManager" title="django.contrib.auth.models.UserManager"><tt class="xref py py-class docutils literal"><span class="pre">UserManager</span></tt></a>; however, if your <tt class="docutils literal"><span class="pre">User</span></tt>
model defines different fields, you will need to define a custom manager that
extends <a class="reference internal" href="#django.contrib.auth.models.BaseUserManager" title="django.contrib.auth.models.BaseUserManager"><tt class="xref py py-class docutils literal"><span class="pre">BaseUserManager</span></tt></a> providing two
additional methods:</p>
<dl class="class">
<dt id="django.contrib.auth.models.CustomUserManager">
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">CustomUserManager</tt><a class="headerlink" href="#django.contrib.auth.models.CustomUserManager" title="Permalink to this definition">¶</a></dt>
<dd><dl class="method">
<dt id="django.contrib.auth.models.CustomUserManager.create_user">
<tt class="descname">create_user</tt>(<em>*username_field*</em>, <em>password=None</em>, <em>**other_fields</em>)<a class="headerlink" href="#django.contrib.auth.models.CustomUserManager.create_user" title="Permalink to this definition">¶</a></dt>
<dd><p>The prototype of <tt class="docutils literal"><span class="pre">create_user()</span></tt> should accept the username field,
plus all required fields as arguments. For example, if your user model
uses <tt class="docutils literal"><span class="pre">email</span></tt> as the username field, and has <tt class="docutils literal"><span class="pre">date_of_birth</span></tt> as a
required fields, then <tt class="docutils literal"><span class="pre">create_user</span></tt> should be defined as:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">def</span> <span class="nf">create_user</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">email</span><span class="p">,</span> <span class="n">date_of_birth</span><span class="p">,</span> <span class="n">password</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="c"># create user here</span>
<span class="o">...</span>
</pre></div>
</div>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.CustomUserManager.create_superuser">
<tt class="descname">create_superuser</tt>(<em>*username_field*</em>, <em>password</em>, <em>**other_fields</em>)<a class="headerlink" href="#django.contrib.auth.models.CustomUserManager.create_superuser" title="Permalink to this definition">¶</a></dt>
<dd><p>The prototype of <tt class="docutils literal"><span class="pre">create_superuser()</span></tt> should accept the username
field, plus all required fields as arguments. For example, if your user
model uses <tt class="docutils literal"><span class="pre">email</span></tt> as the username field, and has <tt class="docutils literal"><span class="pre">date_of_birth</span></tt>
as a required fields, then <tt class="docutils literal"><span class="pre">create_superuser</span></tt> should be defined as:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">def</span> <span class="nf">create_superuser</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">email</span><span class="p">,</span> <span class="n">date_of_birth</span><span class="p">,</span> <span class="n">password</span><span class="p">):</span>
<span class="c"># create superuser here</span>
<span class="o">...</span>
</pre></div>
</div>
<p>Unlike <tt class="docutils literal"><span class="pre">create_user()</span></tt>, <tt class="docutils literal"><span class="pre">create_superuser()</span></tt> <em>must</em> require the
caller to provider a password.</p>
</dd></dl>
</dd></dl>
<p><a class="reference internal" href="#django.contrib.auth.models.BaseUserManager" title="django.contrib.auth.models.BaseUserManager"><tt class="xref py py-class docutils literal"><span class="pre">BaseUserManager</span></tt></a> provides the following
utility methods:</p>
<dl class="class">
<dt id="django.contrib.auth.models.BaseUserManager">
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">BaseUserManager</tt><a class="headerlink" href="#django.contrib.auth.models.BaseUserManager" title="Permalink to this definition">¶</a></dt>
<dd><dl class="method">
<dt id="django.contrib.auth.models.BaseUserManager.normalize_email">
<tt class="descname">normalize_email</tt>(<em>email</em>)<a class="headerlink" href="#django.contrib.auth.models.BaseUserManager.normalize_email" title="Permalink to this definition">¶</a></dt>
<dd><p>A classmethod that normalizes email addresses by lowercasing
the domain portion of the email address.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.BaseUserManager.get_by_natural_key">
<tt class="descname">get_by_natural_key</tt>(<em>username</em>)<a class="headerlink" href="#django.contrib.auth.models.BaseUserManager.get_by_natural_key" title="Permalink to this definition">¶</a></dt>
<dd><p>Retrieves a user instance using the contents of the field
nominated by <tt class="docutils literal"><span class="pre">USERNAME_FIELD</span></tt>.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.BaseUserManager.make_random_password">
<tt class="descname">make_random_password</tt>(<em>length=10</em>, <em>allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789'</em>)<a class="headerlink" href="#django.contrib.auth.models.BaseUserManager.make_random_password" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns a random password with the given length and given string of
allowed characters. (Note that the default value of <tt class="docutils literal"><span class="pre">allowed_chars</span></tt>
doesn’t contain letters that can cause user confusion, including:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">i</span></tt>, <tt class="docutils literal"><span class="pre">l</span></tt>, <tt class="docutils literal"><span class="pre">I</span></tt>, and <tt class="docutils literal"><span class="pre">1</span></tt> (lowercase letter i, lowercase
letter L, uppercase letter i, and the number one)</li>
<li><tt class="docutils literal"><span class="pre">o</span></tt>, <tt class="docutils literal"><span class="pre">O</span></tt>, and <tt class="docutils literal"><span class="pre">0</span></tt> (uppercase letter o, lowercase letter o,
and zero)</li>
</ul>
</dd></dl>
</dd></dl>
</div>
<div class="section" id="s-extending-django-s-default-user">
<span id="extending-django-s-default-user"></span><h3>Extending Django’s default User<a class="headerlink" href="#extending-django-s-default-user" title="Permalink to this headline">¶</a></h3>
<p>If you’re entirely happy with Django’s <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a>
model and you just want to add some additional profile information, you can
simply subclass <tt class="docutils literal"><span class="pre">django.contrib.auth.models.AbstractUser</span></tt> and add your
custom profile fields. This class provides the full implementation of the
default <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> as an <a class="reference internal" href="../db/models.html#abstract-base-classes"><em>abstract model</em></a>.</p>
</div>
<div class="section" id="s-custom-users-and-the-built-in-auth-forms">
<span id="s-id2"></span><span id="custom-users-and-the-built-in-auth-forms"></span><span id="id2"></span><h3>Custom users and the built-in auth forms<a class="headerlink" href="#custom-users-and-the-built-in-auth-forms" title="Permalink to this headline">¶</a></h3>
<p>As you may expect, built-in Django’s <a class="reference internal" href="default.html#built-in-auth-forms"><em>forms</em></a> and
<a class="reference internal" href="default.html#built-in-auth-views"><em>views</em></a> make certain assumptions about the user
model that they are working with.</p>
<p>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.</p>
<ul>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.UserCreationForm" title="django.contrib.auth.forms.UserCreationForm"><tt class="xref py py-class docutils literal"><span class="pre">UserCreationForm</span></tt></a></p>
<p>Depends on the <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> model.
Must be re-written for any custom user model.</p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.UserChangeForm" title="django.contrib.auth.forms.UserChangeForm"><tt class="xref py py-class docutils literal"><span class="pre">UserChangeForm</span></tt></a></p>
<p>Depends on the <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a> model.
Must be re-written for any custom user model.</p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.AuthenticationForm" title="django.contrib.auth.forms.AuthenticationForm"><tt class="xref py py-class docutils literal"><span class="pre">AuthenticationForm</span></tt></a></p>
<p>Works with any subclass of <a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a>,
and will adapt to use the field defined in <cite>USERNAME_FIELD</cite>.</p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.PasswordResetForm" title="django.contrib.auth.forms.PasswordResetForm"><tt class="xref py py-class docutils literal"><span class="pre">PasswordResetForm</span></tt></a></p>
<p>Assumes that the user model has an integer primary key, has a field named
<tt class="docutils literal"><span class="pre">email</span></tt> that can be used to identify the user, and a boolean field
named <cite>is_active</cite> to prevent password resets for inactive users.</p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.SetPasswordForm" title="django.contrib.auth.forms.SetPasswordForm"><tt class="xref py py-class docutils literal"><span class="pre">SetPasswordForm</span></tt></a></p>
<p>Works with any subclass of <a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a></p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.PasswordChangeForm" title="django.contrib.auth.forms.PasswordChangeForm"><tt class="xref py py-class docutils literal"><span class="pre">PasswordChangeForm</span></tt></a></p>
<p>Works with any subclass of <a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a></p>
</li>
<li><p class="first"><a class="reference internal" href="default.html#django.contrib.auth.forms.AdminPasswordChangeForm" title="django.contrib.auth.forms.AdminPasswordChangeForm"><tt class="xref py py-class docutils literal"><span class="pre">AdminPasswordChangeForm</span></tt></a></p>
<p>Works with any subclass of <a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a></p>
</li>
</ul>
</div>
<div class="section" id="s-custom-users-and-django-contrib-admin">
<span id="custom-users-and-django-contrib-admin"></span><h3>Custom users and <a class="reference internal" href="../../ref/contrib/admin/index.html#module-django.contrib.admin" title="django.contrib.admin: Django's admin site."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.admin</span></tt></a><a class="headerlink" href="#custom-users-and-django-contrib-admin" title="Permalink to this headline">¶</a></h3>
<p>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:</p>
<dl class="class">
<dt>
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">CustomUser</tt></dt>
<dd></dd></dl>
<dl class="attribute">
<dt id="django.contrib.auth.is_staff">
<tt class="descname">is_staff</tt><a class="headerlink" href="#django.contrib.auth.is_staff" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user is allowed to have access to the admin site.</p>
</dd></dl>
<dl class="attribute">
<dt id="django.contrib.auth.is_active">
<tt class="descname">is_active</tt><a class="headerlink" href="#django.contrib.auth.is_active" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user account is currently active.</p>
</dd></dl>
<dl class="method">
<dt>
<tt class="descname">has_perm(perm, obj=None):</tt></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user has the named permission. If <tt class="docutils literal"><span class="pre">obj</span></tt> is
provided, the permission needs to be checked against a specific object
instance.</p>
</dd></dl>
<dl class="method">
<dt>
<tt class="descname">has_module_perms(app_label):</tt></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user has permission to access models in
the given app.</p>
</dd></dl>
<p>You will also need to register your custom User model with the admin. If
your custom User model extends <tt class="docutils literal"><span class="pre">django.contrib.auth.models.AbstractUser</span></tt>,
you can use Django’s existing <tt class="docutils literal"><span class="pre">django.contrib.auth.admin.UserAdmin</span></tt>
class. However, if your User model extends
<a class="reference internal" href="#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><tt class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></tt></a>, you’ll need to define
a custom ModelAdmin class. It may be possible to subclass the default
<tt class="docutils literal"><span class="pre">django.contrib.auth.admin.UserAdmin</span></tt>; however, you’ll need to
override any of the definitions that refer to fields on
<tt class="docutils literal"><span class="pre">django.contrib.auth.models.AbstractUser</span></tt> that aren’t on your
custom User class.</p>
</div>
<div class="section" id="s-custom-users-and-permissions">
<span id="custom-users-and-permissions"></span><h3>Custom users and permissions<a class="headerlink" href="#custom-users-and-permissions" title="Permalink to this headline">¶</a></h3>
<p>To make it easy to include Django’s permission framework into your own User
class, Django provides <a class="reference internal" href="#django.contrib.auth.models.PermissionsMixin" title="django.contrib.auth.models.PermissionsMixin"><tt class="xref py py-class docutils literal"><span class="pre">PermissionsMixin</span></tt></a>.
This is an abstract model you can include in the class hierarchy for your User
model, giving you all the methods and database fields necessary to support
Django’s permission model.</p>
<p><a class="reference internal" href="#django.contrib.auth.models.PermissionsMixin" title="django.contrib.auth.models.PermissionsMixin"><tt class="xref py py-class docutils literal"><span class="pre">PermissionsMixin</span></tt></a> provides the following
methods and attributes:</p>
<dl class="class">
<dt id="django.contrib.auth.models.PermissionsMixin">
<em class="property">class </em><tt class="descclassname">models.</tt><tt class="descname">PermissionsMixin</tt><a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin" title="Permalink to this definition">¶</a></dt>
<dd><dl class="attribute">
<dt id="django.contrib.auth.models.PermissionsMixin.is_superuser">
<tt class="descname">is_superuser</tt><a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.is_superuser" title="Permalink to this definition">¶</a></dt>
<dd><p>Boolean. Designates that this user has all permissions without
explicitly assigning them.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.PermissionsMixin.get_group_permissions">
<tt class="descname">get_group_permissions</tt>(<em>obj=None</em>)<a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.get_group_permissions" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns a set of permission strings that the user has, through his/her
groups.</p>
<p>If <tt class="docutils literal"><span class="pre">obj</span></tt> is passed in, only returns the group permissions for
this specific object.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.PermissionsMixin.get_all_permissions">
<tt class="descname">get_all_permissions</tt>(<em>obj=None</em>)<a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.get_all_permissions" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns a set of permission strings that the user has, both through
group and user permissions.</p>
<p>If <tt class="docutils literal"><span class="pre">obj</span></tt> is passed in, only returns the permissions for this
specific object.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.PermissionsMixin.has_perm">
<tt class="descname">has_perm</tt>(<em>perm</em>, <em>obj=None</em>)<a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.has_perm" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user has the specified permission, where perm is
in the format <tt class="docutils literal"><span class="pre">"<app</span> <span class="pre">label>.<permission</span> <span class="pre">codename>"</span></tt> (see
<a class="reference internal" href="default.html#topic-authorization"><em>permissions</em></a>). If the user is inactive, this method will
always return <tt class="docutils literal"><span class="pre">False</span></tt>.</p>
<p>If <tt class="docutils literal"><span class="pre">obj</span></tt> is passed in, this method won’t check for a permission for
the model, but for this specific object.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.PermissionsMixin.has_perms">
<tt class="descname">has_perms</tt>(<em>perm_list</em>, <em>obj=None</em>)<a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.has_perms" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user has each of the specified permissions,
where each perm is in the format
<tt class="docutils literal"><span class="pre">"<app</span> <span class="pre">label>.<permission</span> <span class="pre">codename>"</span></tt>. If the user is inactive,
this method will always return <tt class="docutils literal"><span class="pre">False</span></tt>.</p>
<p>If <tt class="docutils literal"><span class="pre">obj</span></tt> is passed in, this method won’t check for permissions for
the model, but for the specific object.</p>
</dd></dl>
<dl class="method">
<dt id="django.contrib.auth.models.PermissionsMixin.has_module_perms">
<tt class="descname">has_module_perms</tt>(<em>package_name</em>)<a class="headerlink" href="#django.contrib.auth.models.PermissionsMixin.has_module_perms" title="Permalink to this definition">¶</a></dt>
<dd><p>Returns <tt class="docutils literal"><span class="pre">True</span></tt> if the user has any permissions in the given package
(the Django app label). If the user is inactive, this method will
always return <tt class="docutils literal"><span class="pre">False</span></tt>.</p>
</dd></dl>
</dd></dl>
<div class="admonition-modelbackend admonition">
<p class="first admonition-title">ModelBackend</p>
<p class="last">If you don’t include the
<a class="reference internal" href="#django.contrib.auth.models.PermissionsMixin" title="django.contrib.auth.models.PermissionsMixin"><tt class="xref py py-class docutils literal"><span class="pre">PermissionsMixin</span></tt></a>, you must ensure you
don’t invoke the permissions methods on <tt class="docutils literal"><span class="pre">ModelBackend</span></tt>. <tt class="docutils literal"><span class="pre">ModelBackend</span></tt>
assumes that certain fields are available on your user model. If your User
model doesn’t provide those fields, you will receive database errors when
you check permissions.</p>
</div>
</div>
<div class="section" id="s-custom-users-and-proxy-models">
<span id="custom-users-and-proxy-models"></span><h3>Custom users and Proxy models<a class="headerlink" href="#custom-users-and-proxy-models" title="Permalink to this headline">¶</a></h3>
<p>One limitation of custom User models is that installing a custom User model
will break any proxy model extending <a class="reference internal" href="../../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><tt class="xref py py-class docutils literal"><span class="pre">User</span></tt></a>.
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.</p>
<p>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.</p>
</div>
<div class="section" id="s-custom-users-and-signals">
<span id="custom-users-and-signals"></span><h3>Custom users and signals<a class="headerlink" href="#custom-users-and-signals" title="Permalink to this headline">¶</a></h3>
<p>Another limitation of custom User models is that you can’t use
<a class="reference internal" href="#django.contrib.auth.get_user_model" title="django.contrib.auth.get_user_model"><tt class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.get_user_model()</span></tt></a> as the sender or target of a signal
handler. Instead, you must register the handler with the resulting User model.
See <a class="reference internal" href="../signals.html"><em>Signals</em></a> for more information on registering an sending
signals.</p>
</div>
<div class="section" id="s-custom-users-and-testing-fixtures">
<span id="custom-users-and-testing-fixtures"></span><h3>Custom users and testing/fixtures<a class="headerlink" href="#custom-users-and-testing-fixtures" title="Permalink to this headline">¶</a></h3>
<p>If you are writing an application that interacts with the User model, you must
take some precautions to ensure that your test suite will run regardless of
the User model that is being used by a project. Any test that instantiates an
instance of User will fail if the User model has been swapped out. This
includes any attempt to create an instance of User with a fixture.</p>
<p>To ensure that your test suite will pass in any project configuration,
<tt class="docutils literal"><span class="pre">django.contrib.auth.tests.utils</span></tt> defines a <tt class="docutils literal"><span class="pre">@skipIfCustomUser</span></tt> decorator.
This decorator will cause a test case to be skipped if any User model other
than the default Django user is in use. This decorator can be applied to a
single test, or to an entire test class.</p>
<p>Depending on your application, tests may also be needed to be added to ensure
that the application works with <em>any</em> user model, not just the default User
model. To assist with this, Django provides two substitute user models that
can be used in test suites:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">django.contrib.auth.tests.custom_user.CustomUser</span></tt>, a custom user
model that uses an <tt class="docutils literal"><span class="pre">email</span></tt> field as the username, and has a basic
admin-compliant permissions setup</li>
<li><tt class="docutils literal"><span class="pre">django.contrib.auth.tests.custom_user.ExtensionUser</span></tt>, a custom
user model that extends <tt class="docutils literal"><span class="pre">django.contrib.auth.models.AbstractUser</span></tt>,
adding a <tt class="docutils literal"><span class="pre">date_of_birth</span></tt> field.</li>
</ul>
<p>You can then use the <tt class="docutils literal"><span class="pre">@override_settings</span></tt> decorator to make that test run
with the custom User model. For example, here is a skeleton for a test that
would test three possible User models – the default, plus the two User
models provided by <tt class="docutils literal"><span class="pre">auth</span></tt> app:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.contrib.auth.tests.utils</span> <span class="kn">import</span> <span class="n">skipIfCustomUser</span>
<span class="kn">from</span> <span class="nn">django.test</span> <span class="kn">import</span> <span class="n">TestCase</span>
<span class="kn">from</span> <span class="nn">django.test.utils</span> <span class="kn">import</span> <span class="n">override_settings</span>
<span class="k">class</span> <span class="nc">ApplicationTestCase</span><span class="p">(</span><span class="n">TestCase</span><span class="p">):</span>
<span class="nd">@skipIfCustomUser</span>
<span class="k">def</span> <span class="nf">test_normal_user</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="s">"Run tests for the normal user model"</span>
<span class="bp">self</span><span class="o">.</span><span class="n">assertSomething</span><span class="p">()</span>
<span class="nd">@override_settings</span><span class="p">(</span><span class="n">AUTH_USER_MODEL</span><span class="o">=</span><span class="s">'auth.CustomUser'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">test_custom_user</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="s">"Run tests for a custom user model with email-based authentication"</span>
<span class="bp">self</span><span class="o">.</span><span class="n">assertSomething</span><span class="p">()</span>
<span class="nd">@override_settings</span><span class="p">(</span><span class="n">AUTH_USER_MODEL</span><span class="o">=</span><span class="s">'auth.ExtensionUser'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">test_extension_user</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="s">"Run tests for a simple extension of the built-in User."</span>
<span class="bp">self</span><span class="o">.</span><span class="n">assertSomething</span><span class="p">()</span>
</pre></div>
</div>
</div>
<div class="section" id="s-a-full-example">
<span id="a-full-example"></span><h3>A full example<a class="headerlink" href="#a-full-example" title="Permalink to this headline">¶</a></h3>
<p>Here is an example of 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 <tt class="docutils literal"><span class="pre">admin</span></tt> 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 example illustrates how most of
the components work together, but is not intended to be copied directly into
projects for production use.</p>
<p>This code would all live in a <tt class="docutils literal"><span class="pre">models.py</span></tt> file for a custom
authentication app:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">models</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.models</span> <span class="kn">import</span> <span class="p">(</span>
<span class="n">BaseUserManager</span><span class="p">,</span> <span class="n">AbstractBaseUser</span>
<span class="p">)</span>
<span class="k">class</span> <span class="nc">MyUserManager</span><span class="p">(</span><span class="n">BaseUserManager</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">create_user</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">email</span><span class="p">,</span> <span class="n">date_of_birth</span><span class="p">,</span> <span class="n">password</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="sd">"""</span>
<span class="sd"> Creates and saves a User with the given email, date of</span>
<span class="sd"> birth and password.</span>
<span class="sd"> """</span>
<span class="k">if</span> <span class="ow">not</span> <span class="n">email</span><span class="p">:</span>
<span class="k">raise</span> <span class="ne">ValueError</span><span class="p">(</span><span class="s">'Users must have an email address'</span><span class="p">)</span>
<span class="n">user</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">model</span><span class="p">(</span>
<span class="n">email</span><span class="o">=</span><span class="n">MyUserManager</span><span class="o">.</span><span class="n">normalize_email</span><span class="p">(</span><span class="n">email</span><span class="p">),</span>
<span class="n">date_of_birth</span><span class="o">=</span><span class="n">date_of_birth</span><span class="p">,</span>
<span class="p">)</span>
<span class="n">user</span><span class="o">.</span><span class="n">set_password</span><span class="p">(</span><span class="n">password</span><span class="p">)</span>
<span class="n">user</span><span class="o">.</span><span class="n">save</span><span class="p">(</span><span class="n">using</span><span class="o">=</span><span class="bp">self</span><span class="o">.</span><span class="n">_db</span><span class="p">)</span>
<span class="k">return</span> <span class="n">user</span>
<span class="k">def</span> <span class="nf">create_superuser</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">email</span><span class="p">,</span> <span class="n">date_of_birth</span><span class="p">,</span> <span class="n">password</span><span class="p">):</span>
<span class="sd">"""</span>
<span class="sd"> Creates and saves a superuser with the given email, date of</span>
<span class="sd"> birth and password.</span>
<span class="sd"> """</span>
<span class="n">user</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">create_user</span><span class="p">(</span><span class="n">email</span><span class="p">,</span>
<span class="n">password</span><span class="o">=</span><span class="n">password</span><span class="p">,</span>
<span class="n">date_of_birth</span><span class="o">=</span><span class="n">date_of_birth</span>
<span class="p">)</span>
<span class="n">user</span><span class="o">.</span><span class="n">is_admin</span> <span class="o">=</span> <span class="bp">True</span>
<span class="n">user</span><span class="o">.</span><span class="n">save</span><span class="p">(</span><span class="n">using</span><span class="o">=</span><span class="bp">self</span><span class="o">.</span><span class="n">_db</span><span class="p">)</span>
<span class="k">return</span> <span class="n">user</span>
<span class="k">class</span> <span class="nc">MyUser</span><span class="p">(</span><span class="n">AbstractBaseUser</span><span class="p">):</span>
<span class="n">email</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">EmailField</span><span class="p">(</span>
<span class="n">verbose_name</span><span class="o">=</span><span class="s">'email address'</span><span class="p">,</span>
<span class="n">max_length</span><span class="o">=</span><span class="mi">255</span><span class="p">,</span>
<span class="n">unique</span><span class="o">=</span><span class="bp">True</span><span class="p">,</span>
<span class="n">db_index</span><span class="o">=</span><span class="bp">True</span><span class="p">,</span>
<span class="p">)</span>
<span class="n">date_of_birth</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">DateField</span><span class="p">()</span>
<span class="n">is_active</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">BooleanField</span><span class="p">(</span><span class="n">default</span><span class="o">=</span><span class="bp">True</span><span class="p">)</span>
<span class="n">is_admin</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">BooleanField</span><span class="p">(</span><span class="n">default</span><span class="o">=</span><span class="bp">False</span><span class="p">)</span>
<span class="n">objects</span> <span class="o">=</span> <span class="n">MyUserManager</span><span class="p">()</span>
<span class="n">USERNAME_FIELD</span> <span class="o">=</span> <span class="s">'email'</span>
<span class="n">REQUIRED_FIELDS</span> <span class="o">=</span> <span class="p">[</span><span class="s">'date_of_birth'</span><span class="p">]</span>
<span class="k">def</span> <span class="nf">get_full_name</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c"># The user is identified by their email address</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">email</span>
<span class="k">def</span> <span class="nf">get_short_name</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c"># The user is identified by their email address</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">email</span>
<span class="k">def</span> <span class="nf">__unicode__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">email</span>
<span class="k">def</span> <span class="nf">has_perm</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">perm</span><span class="p">,</span> <span class="n">obj</span><span class="o">=</span><span class="bp">None</span><span class="p">):</span>
<span class="s">"Does the user have a specific permission?"</span>
<span class="c"># Simplest possible answer: Yes, always</span>
<span class="k">return</span> <span class="bp">True</span>
<span class="k">def</span> <span class="nf">has_module_perms</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">app_label</span><span class="p">):</span>
<span class="s">"Does the user have permissions to view the app `app_label`?"</span>
<span class="c"># Simplest possible answer: Yes, always</span>
<span class="k">return</span> <span class="bp">True</span>
<span class="nd">@property</span>
<span class="k">def</span> <span class="nf">is_staff</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="s">"Is the user a member of staff?"</span>
<span class="c"># Simplest possible answer: All admins are staff</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">is_admin</span>
</pre></div>
</div>
<p>Then, to register this custom User model with Django’s admin, the following
code would be required in the app’s <tt class="docutils literal"><span class="pre">admin.py</span></tt> file:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django</span> <span class="kn">import</span> <span class="n">forms</span>
<span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">admin</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.models</span> <span class="kn">import</span> <span class="n">Group</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.admin</span> <span class="kn">import</span> <span class="n">UserAdmin</span>
<span class="kn">from</span> <span class="nn">django.contrib.auth.forms</span> <span class="kn">import</span> <span class="n">ReadOnlyPasswordHashField</span>
<span class="kn">from</span> <span class="nn">customauth.models</span> <span class="kn">import</span> <span class="n">MyUser</span>
<span class="k">class</span> <span class="nc">UserCreationForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">ModelForm</span><span class="p">):</span>
<span class="sd">"""A form for creating new users. Includes all the required</span>
<span class="sd"> fields, plus a repeated password."""</span>
<span class="n">password1</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">label</span><span class="o">=</span><span class="s">'Password'</span><span class="p">,</span> <span class="n">widget</span><span class="o">=</span><span class="n">forms</span><span class="o">.</span><span class="n">PasswordInput</span><span class="p">)</span>
<span class="n">password2</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">label</span><span class="o">=</span><span class="s">'Password confirmation'</span><span class="p">,</span> <span class="n">widget</span><span class="o">=</span><span class="n">forms</span><span class="o">.</span><span class="n">PasswordInput</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">MyUser</span>
<span class="n">fields</span> <span class="o">=</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,</span> <span class="s">'date_of_birth'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">clean_password2</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c"># Check that the two password entries match</span>
<span class="n">password1</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">cleaned_data</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="s">"password1"</span><span class="p">)</span>
<span class="n">password2</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">cleaned_data</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="s">"password2"</span><span class="p">)</span>
<span class="k">if</span> <span class="n">password1</span> <span class="ow">and</span> <span class="n">password2</span> <span class="ow">and</span> <span class="n">password1</span> <span class="o">!=</span> <span class="n">password2</span><span class="p">:</span>
<span class="k">raise</span> <span class="n">forms</span><span class="o">.</span><span class="n">ValidationError</span><span class="p">(</span><span class="s">"Passwords don't match"</span><span class="p">)</span>
<span class="k">return</span> <span class="n">password2</span>
<span class="k">def</span> <span class="nf">save</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">commit</span><span class="o">=</span><span class="bp">True</span><span class="p">):</span>
<span class="c"># Save the provided password in hashed format</span>
<span class="n">user</span> <span class="o">=</span> <span class="nb">super</span><span class="p">(</span><span class="n">UserCreationForm</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span><span class="n">save</span><span class="p">(</span><span class="n">commit</span><span class="o">=</span><span class="bp">False</span><span class="p">)</span>
<span class="n">user</span><span class="o">.</span><span class="n">set_password</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">cleaned_data</span><span class="p">[</span><span class="s">"password1"</span><span class="p">])</span>
<span class="k">if</span> <span class="n">commit</span><span class="p">:</span>
<span class="n">user</span><span class="o">.</span><span class="n">save</span><span class="p">()</span>
<span class="k">return</span> <span class="n">user</span>
<span class="k">class</span> <span class="nc">UserChangeForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">ModelForm</span><span class="p">):</span>
<span class="sd">"""A form for updating users. Includes all the fields on</span>
<span class="sd"> the user, but replaces the password field with admin's</span>
<span class="sd"> password hash display field.</span>
<span class="sd"> """</span>
<span class="n">password</span> <span class="o">=</span> <span class="n">ReadOnlyPasswordHashField</span><span class="p">()</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">MyUser</span>
<span class="k">def</span> <span class="nf">clean_password</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c"># Regardless of what the user provides, return the initial value.</span>
<span class="c"># This is done here, rather than on the field, because the</span>
<span class="c"># field does not have access to the initial value</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">initial</span><span class="p">[</span><span class="s">"password"</span><span class="p">]</span>
<span class="k">class</span> <span class="nc">MyUserAdmin</span><span class="p">(</span><span class="n">UserAdmin</span><span class="p">):</span>
<span class="c"># The forms to add and change user instances</span>
<span class="n">form</span> <span class="o">=</span> <span class="n">UserChangeForm</span>
<span class="n">add_form</span> <span class="o">=</span> <span class="n">UserCreationForm</span>
<span class="c"># The fields to be used in displaying the User model.</span>
<span class="c"># These override the definitions on the base UserAdmin</span>
<span class="c"># that reference specific fields on auth.User.</span>
<span class="n">list_display</span> <span class="o">=</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,</span> <span class="s">'date_of_birth'</span><span class="p">,</span> <span class="s">'is_admin'</span><span class="p">)</span>
<span class="n">list_filter</span> <span class="o">=</span> <span class="p">(</span><span class="s">'is_admin'</span><span class="p">,)</span>
<span class="n">fieldsets</span> <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="bp">None</span><span class="p">,</span> <span class="p">{</span><span class="s">'fields'</span><span class="p">:</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,</span> <span class="s">'password'</span><span class="p">)}),</span>
<span class="p">(</span><span class="s">'Personal info'</span><span class="p">,</span> <span class="p">{</span><span class="s">'fields'</span><span class="p">:</span> <span class="p">(</span><span class="s">'date_of_birth'</span><span class="p">,)}),</span>
<span class="p">(</span><span class="s">'Permissions'</span><span class="p">,</span> <span class="p">{</span><span class="s">'fields'</span><span class="p">:</span> <span class="p">(</span><span class="s">'is_admin'</span><span class="p">,)}),</span>
<span class="p">(</span><span class="s">'Important dates'</span><span class="p">,</span> <span class="p">{</span><span class="s">'fields'</span><span class="p">:</span> <span class="p">(</span><span class="s">'last_login'</span><span class="p">,)}),</span>
<span class="p">)</span>
<span class="c"># add_fieldsets is not a standard ModelAdmin attribute. UserAdmin</span>
<span class="c"># overrides get_fieldsets to use this attribute when creating a user.</span>
<span class="n">add_fieldsets</span> <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="bp">None</span><span class="p">,</span> <span class="p">{</span>
<span class="s">'classes'</span><span class="p">:</span> <span class="p">(</span><span class="s">'wide'</span><span class="p">,),</span>
<span class="s">'fields'</span><span class="p">:</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,</span> <span class="s">'date_of_birth'</span><span class="p">,</span> <span class="s">'password1'</span><span class="p">,</span> <span class="s">'password2'</span><span class="p">)}</span>
<span class="p">),</span>
<span class="p">)</span>
<span class="n">search_fields</span> <span class="o">=</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,)</span>
<span class="n">ordering</span> <span class="o">=</span> <span class="p">(</span><span class="s">'email'</span><span class="p">,)</span>
<span class="n">filter_horizontal</span> <span class="o">=</span> <span class="p">()</span>
<span class="c"># Now register the new UserAdmin...</span>
<span class="n">admin</span><span class="o">.</span><span class="n">site</span><span class="o">.</span><span class="n">register</span><span class="p">(</span><span class="n">MyUser</span><span class="p">,</span> <span class="n">MyUserAdmin</span><span class="p">)</span>
<span class="c"># ... and, since we're not using Django's builtin permissions,</span>
<span class="c"># unregister the Group model from admin.</span>
<span class="n">admin</span><span class="o">.</span><span class="n">site</span><span class="o">.</span><span class="n">unregister</span><span class="p">(</span><span class="n">Group</span><span class="p">)</span>
</pre></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Customizing authentication in Django</a><ul>
<li><a class="reference internal" href="#other-authentication-sources">Other authentication sources</a><ul>
<li><a class="reference internal" href="#specifying-authentication-backends">Specifying authentication backends</a></li>
<li><a class="reference internal" href="#writing-an-authentication-backend">Writing an authentication backend</a></li>
<li><a class="reference internal" href="#handling-authorization-in-custom-backends">Handling authorization in custom backends</a><ul>
<li><a class="reference internal" href="#authorization-for-anonymous-users">Authorization for anonymous users</a></li>
<li><a class="reference internal" href="#authorization-for-inactive-users">Authorization for inactive users</a></li>
<li><a class="reference internal" href="#handling-object-permissions">Handling object permissions</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#custom-permissions">Custom permissions</a></li>
<li><a class="reference internal" href="#extending-the-existing-user-model">Extending the existing User model</a></li>
<li><a class="reference internal" href="#substituting-a-custom-user-model">Substituting a custom User model</a><ul>
<li><a class="reference internal" href="#referencing-the-user-model">Referencing the User model</a></li>
<li><a class="reference internal" href="#specifying-a-custom-user-model">Specifying a custom User model</a></li>
<li><a class="reference internal" href="#extending-django-s-default-user">Extending Django’s default User</a></li>
<li><a class="reference internal" href="#custom-users-and-the-built-in-auth-forms">Custom users and the built-in auth forms</a></li>
<li><a class="reference internal" href="#custom-users-and-django-contrib-admin">Custom users and <tt class="docutils literal"><span class="pre">django.contrib.admin</span></tt></a></li>
<li><a class="reference internal" href="#custom-users-and-permissions">Custom users and permissions</a></li>
<li><a class="reference internal" href="#custom-users-and-proxy-models">Custom users and Proxy models</a></li>
<li><a class="reference internal" href="#custom-users-and-signals">Custom users and signals</a></li>
<li><a class="reference internal" href="#custom-users-and-testing-fixtures">Custom users and testing/fixtures</a></li>
<li><a class="reference internal" href="#a-full-example">A full example</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="passwords.html">Password management in Django</a></li>
<li>Next: <a href="../cache.html">Django’s cache framework</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../../index.html">Django 1.5.9 documentation</a>
<ul><li><a href="../index.html">Using Django</a>
<ul><li><a href="index.html">User authentication in Django</a>
<ul><li>Customizing authentication in Django</li></ul>
</li></ul></li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../../_sources/topics/auth/customizing.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Mar 19, 2015</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="passwords.html" title="Password management in Django">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="../cache.html" title="Django&#8217;s cache framework">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
