/usr/share/doc/python-django-allauth/html/advanced.html is in python-django-allauth-doc 0.35.0-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 | <!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>Advanced Usage — django-allauth 0.32.0 documentation</title>
<link rel="stylesheet" href="_static/classic.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: './',
VERSION: '0.32.0',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true,
SOURCELINK_SUFFIX: '.txt'
};
</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="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Frequently Asked Questions" href="faq.html" />
<link rel="prev" title="Decorators" href="decorators.html" />
</head>
<body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="faq.html" title="Frequently Asked Questions"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="decorators.html" title="Decorators"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">django-allauth 0.32.0 documentation</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="advanced-usage">
<h1>Advanced Usage<a class="headerlink" href="#advanced-usage" title="Permalink to this headline">¶</a></h1>
<div class="section" id="https">
<h2>HTTPS<a class="headerlink" href="#https" title="Permalink to this headline">¶</a></h2>
<p>This app currently provides no functionality for enforcing views to be
HTTPS only, or switching from HTTP to HTTPS (and back) on demand.
There are third party packages aimed at providing precisely this,
so please use these.</p>
<p>What is provided is the following:</p>
<ul class="simple">
<li>The protocol to be used for generating links (e.g. password
forgotten) for e-mails is configurable by means of the
<code class="docutils literal"><span class="pre">ACCOUNT_DEFAULT_HTTP_PROTOCOL</span></code> setting.</li>
<li>Automatically switching to HTTPS is built-in for OAuth providers
that require this (e.g. Amazon). However, remembering the original
protocol before the switch and switching back after the login is not
provided.</li>
</ul>
</div>
<div class="section" id="custom-user-models">
<h2>Custom User Models<a class="headerlink" href="#custom-user-models" title="Permalink to this headline">¶</a></h2>
<p>If you use a custom user model you need to specify what field
represents the <code class="docutils literal"><span class="pre">username</span></code>, if any. Here, <code class="docutils literal"><span class="pre">username</span></code> really refers to
the field representing the nickname that the user uses to login, and not to
some unique identifier (possibly including an e-mail address) as is
the case for Django’s <code class="docutils literal"><span class="pre">AbstractBaseUser.USERNAME_FIELD</span></code>.</p>
<p>Therefore, if your custom user model does not have a <code class="docutils literal"><span class="pre">username</span></code> field
(again, not to be mistaken with an e-mail address or user id), you
will need to set <code class="docutils literal"><span class="pre">ACCOUNT_USER_MODEL_USERNAME_FIELD</span></code> to <code class="docutils literal"><span class="pre">None</span></code>. This
will disable username related functionality in <code class="docutils literal"><span class="pre">allauth</span></code>. Remember to
also set <code class="docutils literal"><span class="pre">ACCOUNT_USERNAME_REQUIRED</span></code> to <code class="docutils literal"><span class="pre">False</span></code>.</p>
<p>Similarly, you will need to set <code class="docutils literal"><span class="pre">ACCOUNT_USER_MODEL_EMAIL_FIELD</span></code> to
<code class="docutils literal"><span class="pre">None</span></code> or to the proper field (if other than <code class="docutils literal"><span class="pre">email</span></code>).</p>
<p>For example, if you want to use a custom user model that has <code class="docutils literal"><span class="pre">email</span></code>
as the identifying field, and you don’t want to collect usernames, you
need the following in your settings.py:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">ACCOUNT_USER_MODEL_USERNAME_FIELD</span> <span class="o">=</span> <span class="kc">None</span>
<span class="n">ACCOUNT_EMAIL_REQUIRED</span> <span class="o">=</span> <span class="kc">True</span>
<span class="n">ACCOUNT_USERNAME_REQUIRED</span> <span class="o">=</span> <span class="kc">False</span>
<span class="n">ACCOUNT_AUTHENTICATION_METHOD</span> <span class="o">=</span> <span class="s1">'email'</span>
</pre></div>
</div>
</div>
<div class="section" id="creating-and-populating-user-instances">
<h2>Creating and Populating User instances<a class="headerlink" href="#creating-and-populating-user-instances" title="Permalink to this headline">¶</a></h2>
<p>The following adapter methods can be used to intervene in how User
instances are created and populated with data</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">allauth.account.adapter.DefaultAccountAdapter</span></code>:<ul>
<li><code class="docutils literal"><span class="pre">is_open_for_signup(self,</span> <span class="pre">request)</span></code>: The default function
returns <code class="docutils literal"><span class="pre">True</span></code>. You can override this method by returning <code class="docutils literal"><span class="pre">False</span></code>
if you want to disable account signup.</li>
<li><code class="docutils literal"><span class="pre">new_user(self,</span> <span class="pre">request)</span></code>: Instantiates a new, empty <code class="docutils literal"><span class="pre">User</span></code>.</li>
<li><code class="docutils literal"><span class="pre">save_user(self,</span> <span class="pre">request,</span> <span class="pre">user,</span> <span class="pre">form)</span></code>: Populates and saves the
<code class="docutils literal"><span class="pre">User</span></code> instance using information provided in the signup form.</li>
<li><code class="docutils literal"><span class="pre">populate_username(self,</span> <span class="pre">request,</span> <span class="pre">user)</span></code>:
Fills in a valid username, if required and missing. If the
username is already present, then it is assumed to be valid (unique).</li>
<li><code class="docutils literal"><span class="pre">confirm_email(self,</span> <span class="pre">request,</span> <span class="pre">email_address)</span></code>: Marks the email address as
confirmed and saves to the db.</li>
<li><code class="docutils literal"><span class="pre">generate_unique_username(self,</span> <span class="pre">txts,</span> <span class="pre">regex=None)</span></code>: Returns a unique username
from the combination of strings present in txts iterable. A regex pattern
can be passed to the method to make sure the generated username matches it.</li>
</ul>
</li>
<li><code class="docutils literal"><span class="pre">allauth.socialaccount.adapter.DefaultSocialAccountAdapter</span></code>:<ul>
<li><code class="docutils literal"><span class="pre">is_open_for_signup(self,</span> <span class="pre">request)</span></code>: The default function
returns that is the same as <code class="docutils literal"><span class="pre">ACCOUNT_ADAPTER</span></code> in <code class="docutils literal"><span class="pre">settings.py</span></code>.
You can override this method by returning <code class="docutils literal"><span class="pre">True</span></code>/<code class="docutils literal"><span class="pre">False</span></code>
if you want to enable/disable socialaccount signup.</li>
<li><code class="docutils literal"><span class="pre">new_user(self,</span> <span class="pre">request,</span> <span class="pre">sociallogin)</span></code>: Instantiates a new, empty
<code class="docutils literal"><span class="pre">User</span></code>.</li>
<li><code class="docutils literal"><span class="pre">save_user(self,</span> <span class="pre">request,</span> <span class="pre">sociallogin,</span> <span class="pre">form=None)</span></code>: Populates and
saves the <code class="docutils literal"><span class="pre">User</span></code> instance (and related social login data). The
signup form is not available in case of auto signup.</li>
<li><code class="docutils literal"><span class="pre">populate_user(self,</span> <span class="pre">request,</span> <span class="pre">sociallogin,</span> <span class="pre">data)</span></code>: Hook that can
be used to further populate the user instance
(<code class="docutils literal"><span class="pre">sociallogin.account.user</span></code>). Here, <code class="docutils literal"><span class="pre">data</span></code> is a dictionary of
common user properties (<code class="docutils literal"><span class="pre">first_name</span></code>, <code class="docutils literal"><span class="pre">last_name</span></code>, <code class="docutils literal"><span class="pre">email</span></code>,
<code class="docutils literal"><span class="pre">username</span></code>, <code class="docutils literal"><span class="pre">name</span></code>) that the provider already extracted for you.</li>
</ul>
</li>
</ul>
</div>
<div class="section" id="invitations">
<h2>Invitations<a class="headerlink" href="#invitations" title="Permalink to this headline">¶</a></h2>
<p>Invitation handling is not supported, and most likely will not be any
time soon. An invitation app could cover anything ranging from
invitations of new users, to invitations of existing users to
participate in restricted parts of the site. All in all, the scope of
invitation handling is large enough to warrant being addressed in an
app of its own.</p>
<p>Still, everything is in place to easily hook up any third party
invitation app. The account adapter
(<code class="docutils literal"><span class="pre">allauth.account.adapter.DefaultAccountAdapter</span></code>) offers the following
methods:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">is_open_for_signup(self,</span> <span class="pre">request)</span></code>. You can override this method to, for
example, inspect the session to check if an invitation was accepted.</li>
<li><code class="docutils literal"><span class="pre">stash_verified_email(self,</span> <span class="pre">request,</span> <span class="pre">email)</span></code>. If an invitation was
accepted by following a link in an email, then there is no need to
send email verification mails after the signup is completed. Use
this method to record the fact that an email address was verified.</li>
</ul>
</div>
<div class="section" id="sending-email">
<h2>Sending Email<a class="headerlink" href="#sending-email" title="Permalink to this headline">¶</a></h2>
<p>Emails sent (e.g. in case of password forgotten or email
confirmation) can be altered by providing your own
templates. Templates are named as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">account</span><span class="o">/</span><span class="n">email</span><span class="o">/</span><span class="n">email_confirmation_subject</span><span class="o">.</span><span class="n">txt</span>
<span class="n">account</span><span class="o">/</span><span class="n">email</span><span class="o">/</span><span class="n">email_confirmation_message</span><span class="o">.</span><span class="n">txt</span>
</pre></div>
</div>
<p>In case you want to include an HTML representation, add an HTML
template as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">account</span><span class="o">/</span><span class="n">email</span><span class="o">/</span><span class="n">email_confirmation_message</span><span class="o">.</span><span class="n">html</span>
</pre></div>
</div>
<p>The project does not contain any HTML email templates out of the box.
When you do provide these yourself, note that both the text and HTML
versions of the message are sent.</p>
<p>If this does not suit your needs, you can hook up your own custom
mechanism by overriding the <code class="docutils literal"><span class="pre">send_mail</span></code> method of the account adapter
(<code class="docutils literal"><span class="pre">allauth.account.adapter.DefaultAccountAdapter</span></code>).</p>
</div>
<div class="section" id="custom-redirects">
<h2>Custom Redirects<a class="headerlink" href="#custom-redirects" title="Permalink to this headline">¶</a></h2>
<p>If redirecting to statically configurable URLs (as specified in your
project settings) is not flexible enough, then you can override the
following adapter methods:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">allauth.account.adapter.DefaultAccountAdapter</span></code>:<ul>
<li><code class="docutils literal"><span class="pre">get_login_redirect_url(self,</span> <span class="pre">request)</span></code></li>
<li><code class="docutils literal"><span class="pre">get_logout_redirect_url(self,</span> <span class="pre">request)</span></code></li>
<li><code class="docutils literal"><span class="pre">get_email_confirmation_redirect_url(self,</span> <span class="pre">request)</span></code></li>
</ul>
</li>
<li><code class="docutils literal"><span class="pre">allauth.socialaccount.adapter.DefaultSocialAccountAdapter</span></code>:<ul>
<li><code class="docutils literal"><span class="pre">get_connect_redirect_url(self,</span> <span class="pre">request,</span> <span class="pre">socialaccount)</span></code></li>
</ul>
</li>
</ul>
<p>For example, redirecting to <code class="docutils literal"><span class="pre">/accounts/<username>/</span></code> can be implemented as
follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># project/settings.py:</span>
<span class="n">ACCOUNT_ADAPTER</span> <span class="o">=</span> <span class="s1">'project.users.adapter.MyAccountAdapter'</span>
<span class="c1"># project/users/adapter.py:</span>
<span class="kn">from</span> <span class="nn">django.conf</span> <span class="k">import</span> <span class="n">settings</span>
<span class="kn">from</span> <span class="nn">allauth.account.adapter</span> <span class="k">import</span> <span class="n">DefaultAccountAdapter</span>
<span class="k">class</span> <span class="nc">MyAccountAdapter</span><span class="p">(</span><span class="n">DefaultAccountAdapter</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">get_login_redirect_url</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">):</span>
<span class="n">path</span> <span class="o">=</span> <span class="s2">"/accounts/</span><span class="si">{username}</span><span class="s2">/"</span>
<span class="k">return</span> <span class="n">path</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="n">username</span><span class="o">=</span><span class="n">request</span><span class="o">.</span><span class="n">user</span><span class="o">.</span><span class="n">username</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="messages">
<h2>Messages<a class="headerlink" href="#messages" title="Permalink to this headline">¶</a></h2>
<p>The Django messages framework (<code class="docutils literal"><span class="pre">django.contrib.messages</span></code>) is used if
it is listed in <code class="docutils literal"><span class="pre">settings.INSTALLED_APPS</span></code>. All messages (as in
<code class="docutils literal"><span class="pre">django.contrib.messages</span></code>) are configurable by overriding their
respective template. If you want to disable a message, simply override
the message template with a blank one.</p>
</div>
<div class="section" id="admin">
<h2>Admin<a class="headerlink" href="#admin" title="Permalink to this headline">¶</a></h2>
<p>The Django admin site (<code class="docutils literal"><span class="pre">django.contrib.admin</span></code>) does not use Django allauth by
default. Since Django admin provides a custom login view, it does not go through
the normal Django allauth workflow.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p>This limitation means that Django allauth features are not applied to the
Django admin site:</p>
<ul class="last simple">
<li><code class="docutils literal"><span class="pre">ACCOUNT_LOGIN_ATTEMPTS_LIMIT</span></code> and <code class="docutils literal"><span class="pre">ACCOUNT_LOGIN_ATTEMPTS_TIMEOUT</span></code> do not
protect Django’s admin login from being brute forced.</li>
<li>Any other custom workflow that overrides the Django allauth adapter’s
login method will not be applied.</li>
</ul>
</div>
<p>An easy workaround for this is to require users to login before going to the
Django admin site’s login page (note that the following would need to be applied to
every instance of <code class="docutils literal"><span class="pre">AdminSite</span></code>):</p>
<div class="highlight-python"><div class="highlight"><pre><span></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.decorators</span> <span class="kn">import</span> <span class="n">login_required</span>
<span class="n">admin</span><span class="o">.</span><span class="n">site</span><span class="o">.</span><span class="n">login</span> <span class="o">=</span> <span class="n">login_required</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">login</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="customizing-providers">
<h2>Customizing providers<a class="headerlink" href="#customizing-providers" title="Permalink to this headline">¶</a></h2>
<p>When an existing provider doesn’t quite meet your needs, you might find yourself
needing to customize a provider.</p>
<p>This can be achieved by subclassing an existing provider and making your changes
there. Providers are defined as django applications, so typically customizing one
will mean creating a django application in your project. This application will contain your customized
urls.py, views.py and provider.py files. The behaviour that can be customized is beyond
the scope of this documentation.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p>In your <code class="docutils literal"><span class="pre">provider.py</span></code> file, you will need to expose the provider class
by having a module level attribute called <code class="docutils literal"><span class="pre">provider_classes</span></code> with your custom
classes in a list. This allows your custom provider to be registered properly
on the basis of the <code class="docutils literal"><span class="pre">INSTALLED_APPS</span></code> setting.</p>
<p class="last">Be sure to use a custom id property on your provider class such that its default
URLs do not clash with the provider you are subclassing.</p>
</div>
<div class="highlight-python"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">GoogleNoDefaultScopeProvider</span><span class="p">(</span><span class="n">GoogleProvider</span><span class="p">):</span>
<span class="nb">id</span> <span class="o">=</span> <span class="s1">'google_no_scope'</span>
<span class="k">def</span> <span class="nf">get_default_scope</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="p">[]</span>
<span class="n">provider_classes</span> <span class="o">=</span> <span class="p">[</span><span class="n">GoogleNoDefaultScopeProvider</span><span class="p">]</span>
</pre></div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Advanced Usage</a><ul>
<li><a class="reference internal" href="#https">HTTPS</a></li>
<li><a class="reference internal" href="#custom-user-models">Custom User Models</a></li>
<li><a class="reference internal" href="#creating-and-populating-user-instances">Creating and Populating User instances</a></li>
<li><a class="reference internal" href="#invitations">Invitations</a></li>
<li><a class="reference internal" href="#sending-email">Sending Email</a></li>
<li><a class="reference internal" href="#custom-redirects">Custom Redirects</a></li>
<li><a class="reference internal" href="#messages">Messages</a></li>
<li><a class="reference internal" href="#admin">Admin</a></li>
<li><a class="reference internal" href="#customizing-providers">Customizing providers</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="decorators.html"
title="previous chapter">Decorators</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="faq.html"
title="next chapter">Frequently Asked Questions</a></p>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/advanced.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="faq.html" title="Frequently Asked Questions"
>next</a> |</li>
<li class="right" >
<a href="decorators.html" title="Decorators"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">django-allauth 0.32.0 documentation</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 2018, Raymond Penners.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.6.
</div>
</body>
</html>
|