Este documento explica a utilização do sistema de autenticações do Django em suas configurações padrões. Estas configurações evoluíram para atender as necessidades mais comuns de um projeto, lidando com uma considerável quantidade de tarefas e implementando cuidadosamente, o uso de senhas e permissões. Para projetos onde o sistema de autenticações demande outras necessidades diferentes das padrões, o Django oferece suporte para uma extensiva customização: extension and customization de autenticação.
\nA autenticação do Django oferece, tanto autenticação como autorização juntos. Estes serviços são referenciados como “sistema de autenticação” uma vez estas funções são, de alguma forma, interligadas.
\nOs objetos do tipo User são o núcleo do sistema de autenticação. Eles tipicamente representam as pessoas interagindo com seu site e são usados para habilitar coisas como restrinção de acesso, registro de perfis de usuários, associar conteúdo com criadores etc. Somente uma classe de usuário existe no “framework” de autenticação do Django, isto é, usuários 'superusers' ou admin 'staff' são somente objetos do tipo “user” com atributos especiais definidos e não classes diferentes de objetos “user”.
Os atributos primários de usuário padrão são:
\nVeja a :class:` documentação completa da API <django.contrib.auth.models.User>` para maiores detalhes, a documentação em questão é mais orientada a tarefa.
\nA forma mais direta para se criar usuários, é utilizando a função de ajuda inclusa create_user() helper function:
>>> from django.contrib.auth.models import User\n>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')\n\n# At this point, user is a User object that has already been saved\n# to the database. You can continue to change its attributes\n# if you want to change other fields.\n>>> user.last_name = 'Lennon'\n>>> user.save()\nSe você tiver a administração do Django instalado, você também pode: ref: ` criar usuários de forma interativa < auth -admin >` .
\nCriando superusuários usando o commando createsuperuser
$ python manage.py createsuperuser --username=joe --email=joe@example.com\nSerá solicitada então uma senha. Após inserí-la, a conta de usuário será criada imediatamente. Caso seja desligada a opção:--username ou --email, estes valores serão solicitados.
O Django não armazena senha em sua forma bruta (texto limpo) no modelo do usuário, mas somente um “hash” (see documentação de como as senhas são manipuladas para detalhes completos). Por causa disso, não tente manipular diretamente o atributo “password” do usuário. Este é o porque de uma função auxiliar ser usada para criar um usuário.
\nPara mudar a senha de usuários, você tem várias opções:
\nO manage.py changepassword *username* oferece um método para alteração da senha do “User” na linha de comando. Ele pergunta no “prompt” para alterar uma senha de um dado usuário a qual você deve informar duas vezes. Se ambas combinam, uma nova senha será alterada imediatamente. Se você não fornecer um usuário, o comando irá tentar alterar a senha do nome do usuário que combine com o usuário do sistema.
Você pode também mudar a senha programaticamente, usando set_password():
>>> from django.contrib.auth.models import User\n>>> u = User.objects.get(username='john')\n>>> u.set_password('new password')\n>>> u.save()\nSe você tiver a administração do Django instalado, você também pode alterar a senha do usuário nas : ref: páginas de administração do ` sistema de autenticação < auth -admin >` .
\nDjango também fornece : ref: ` views < built-in -auth- vistas >` e : ref: ` forms < built-in -auth-forms>` que podem ser utilizados para permitir que os usuários alterem suas próprias senhas.
\nAo alterar a senha de um usuário, todas as sessões deste serão finalizadas se SessionAuthenticationMiddleware estiver habilitado. Veja : ref:session-invalidation-on-password-change para detalhes.
Para autenticar um dado usuário e senha, utilize authenticate(). As credenciais serão pegas na forma de argumentos chave valor, o que para a configuração padrão é “usuário” e “senha” e será retornado um objeto do tipo User se a senha for válida para este usuário. Caso a senha seja inválida, a função authenticate() retornará “None”. Exemplo:
from django.contrib.auth import authenticate\nuser = authenticate(username='john', password='secret')\nif user is not None:\n # the password verified for the user\n if user.is_active:\n print("User is valid, active and authenticated")\n else:\n print("The password is valid, but the account has been disabled!")\nelse:\n # the authentication system was unable to verify the username and password\n print("The username and password were incorrect.")\nDjango uses sessions and middleware to hook the\nauthentication system into request objects.
These provide a request.user attribute\non every request which represents the current user. If the current user has not\nlogged in, this attribute will be set to an instance\nof AnonymousUser, otherwise it will be an\ninstance of User.
You can tell them apart with\nis_authenticated(), like so:
if request.user.is_authenticated():\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nCaso queira adicionar um usuário autenticado à sessão atual - isto pode ser feito com a função login().
To log a user in, from a view, use login(). It\ntakes an HttpRequest object and a\nUser object.\nlogin() saves the user’s ID in the session,\nusing Django’s session framework.
Note que qualquer dado definido durante um sessão anônima, fica retido na sessão após um usuário logar.
\nEstes exemplos mostram como é possível utilizar ambas funções\nauthenticate() e login():
from django.contrib.auth import authenticate, login\n\ndef my_view(request):\n username = request.POST['username']\n password = request.POST['password']\n user = authenticate(username=username, password=password)\n if user is not None:\n if user.is_active:\n login(request, user)\n # Redirect to a success page.\n else:\n # Return a 'disabled account' error message\n ...\n else:\n # Return an 'invalid login' error message.\n ...\nWhen a user logs in, the user’s ID and the backend that was used for\nauthentication are saved in the user’s session. This allows the same\nauthentication backend to fetch the user’s\ndetails on a future request. The authentication backend to save in the session\nis selected as follows:
\nUse the value of the optional backend argument, if provided.
Use the value of the user.backend attribute, if present. This allows\npairing authenticate() and\nlogin():\nauthenticate()\nsets the user.backend attribute on the User object it returns.
Use the backend in AUTHENTICATION_BACKENDS, if there is only\none.
Caso contrário, gera uma exceção.
In cases 1 and 2, the value of the backend argument or the user.backend\nattribute should be a dotted import path string (like that found in\nAUTHENTICATION_BACKENDS), not the actual backend class.
To log out a user who has been logged in via\ndjango.contrib.auth.login(), use\ndjango.contrib.auth.logout() within your view. It takes an\nHttpRequest object and has no return value.\nExample:
from django.contrib.auth import logout\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\nNote that logout() doesn’t throw any errors if\nthe user wasn’t logged in.
When you call logout(), the session data for\nthe current request is completely cleaned out. All existing data is\nremoved. This is to prevent another person from using the same Web browser\nto log in and have access to the previous user’s session data. If you want\nto put anything into the session that will be available to the user\nimmediately after logging out, do that after calling\ndjango.contrib.auth.logout().
The simple, raw way to limit access to pages is to check\nrequest.user.is_authenticated() and either redirect to a\nlogin page:
from django.conf import settings\nfrom django.shortcuts import redirect\n\ndef my_view(request):\n if not request.user.is_authenticated():\n return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))\n # ...\n…or display an error message:
\nfrom django.shortcuts import render\n\ndef my_view(request):\n if not request.user.is_authenticated():\n return render(request, 'myapp/login_error.html')\n # ...\nlogin_required decoratorLink para este cabeçalho#As a shortcut, you can use the convenient\nlogin_required() decorator:
from django.contrib.auth.decorators import login_required\n\n@login_required\ndef my_view(request):\n ...\nlogin_required() does the following:
If the user isn’t logged in, redirect to\nsettings.LOGIN_URL, passing the current absolute\npath in the query string. Example: /accounts/login/?next=/polls/3/.
If the user is logged in, execute the view normally. The view code is\nfree to assume the user is logged in.
By default, the path that the user should be redirected to upon\nsuccessful authentication is stored in a query string parameter called\n"next". If you would prefer to use a different name for this parameter,\nlogin_required() takes an\noptional redirect_field_name parameter:
from django.contrib.auth.decorators import login_required\n\n@login_required(redirect_field_name='my_redirect_field')\ndef my_view(request):\n ...\nNote that if you provide a value to redirect_field_name, you will most\nlikely need to customize your login template as well, since the template\ncontext variable which stores the redirect path will use the value of\nredirect_field_name as its key rather than "next" (the default).
login_required() also takes an\noptional login_url parameter. Example:
from django.contrib.auth.decorators import login_required\n\n@login_required(login_url='/accounts/login/')\ndef my_view(request):\n ...\nNote that if you don’t specify the login_url parameter, you’ll need to\nensure that the settings.LOGIN_URL and your login\nview are properly associated. For example, using the defaults, add the\nfollowing lines to your URLconf:
from django.contrib.auth import views as auth_views\n\nurl(r'^accounts/login/$', auth_views.login),\nThe settings.LOGIN_URL also accepts view function\nnames and named URL patterns. This allows you\nto freely remap your login view within your URLconf without having to\nupdate the setting.
LoginRequired mixinLink para este cabeçalho#When using class-based views, you can\nachieve the same behavior as with login_required by using the\nLoginRequiredMixin. This mixin should be at the leftmost position in the\ninheritance list.
If a view is using this mixin, all requests by non-authenticated users will\nbe redirected to the login page or shown an HTTP 403 Forbidden error,\ndepending on the\nraise_exception parameter.
You can set any of the parameters of\nAccessMixin to customize the handling\nof unauthorized users:
from django.contrib.auth.mixins import LoginRequiredMixin\n\nclass MyView(LoginRequiredMixin, View):\n login_url = '/login/'\n redirect_field_name = 'redirect_to'\nTo limit access based on certain permissions or some other test, you’d do\nessentially the same thing as described in the previous section.
\nThe simple way is to run your test on request.user in the view directly. For example, this view\nchecks to make sure the user has an email in the desired domain and if not,\nredirects to the login page:
from django.shortcuts import redirect\n\ndef my_view(request):\n if not request.user.email.endswith('@example.com'):\n return redirect('/login/?next=%s' % request.path)\n # ...\nAs a shortcut, you can use the convenient user_passes_test decorator\nwhich performs a redirect when the callable returns False:
from django.contrib.auth.decorators import user_passes_test\n\ndef email_check(user):\n return user.email.endswith('@example.com')\n\n@user_passes_test(email_check)\ndef my_view(request):\n ...\nuser_passes_test() takes a required\nargument: a callable that takes a\nUser object and returns True if\nthe user is allowed to view the page. Note that\nuser_passes_test() does not\nautomatically check that the User is\nnot anonymous.
user_passes_test() takes two\noptional arguments:
login_urlLets you specify the URL that users who don’t pass the test will be\nredirected to. It may be a login page and defaults to\nsettings.LOGIN_URL if you don’t specify one.
redirect_field_nameSame as for login_required().\nSetting it to None removes it from the URL, which you may want to do\nif you are redirecting users that don’t pass the test to a non-login\npage where there’s no “next page”.
Por exemplo:
\n@user_passes_test(email_check, login_url='/login/')\ndef my_view(request):\n ...\nWhen using class-based views, you\ncan use the UserPassesTestMixin to do this.
You have to override the test_func() method of the class to\nprovide the test that is performed. Furthermore, you can set any of the\nparameters of AccessMixin to\ncustomize the handling of unauthorized users:
from django.contrib.auth.mixins import UserPassesTestMixin\n\nclass MyView(UserPassesTestMixin, View):\n\n def test_func(self):\n return self.request.user.email.endswith('@example.com')\nYou can also override the get_test_func() method to have the mixin\nuse a differently named function for its checks (instead of\ntest_func()).
permission_required decoratorLink para este cabeçalho#It’s a relatively common task to check whether a user has a particular\npermission. For that reason, Django provides a shortcut for that case: the\npermission_required() decorator.:
from django.contrib.auth.decorators import permission_required\n\n@permission_required('polls.can_vote')\ndef my_view(request):\n ...\nJust like the has_perm() method,\npermission names take the form "<app label>.<permission codename>"\n(i.e. polls.can_vote for a permission on a model in the polls\napplication).
The decorator may also take an iterable of permissions, in which case the\nuser must have all of the permissions in order to access the view.
\nNote that permission_required()\nalso takes an optional login_url parameter:
from django.contrib.auth.decorators import permission_required\n\n@permission_required('polls.can_vote', login_url='/loginpage/')\ndef my_view(request):\n ...\nAs in the login_required() decorator,\nlogin_url defaults to settings.LOGIN_URL.
If the raise_exception parameter is given, the decorator will raise\nPermissionDenied, prompting the 403\n(HTTP Forbidden) view instead of redirecting to the\nlogin page.
If you want to use raise_exception but also give your users a chance to\nlogin first, you can add the\nlogin_required() decorator:
from django.contrib.auth.decorators import login_required, permission_required\n\n@login_required\n@permission_required('polls.can_vote', raise_exception=True)\ndef my_view(request):\n ...\nPermissionRequiredMixin mixinLink para este cabeçalho#To apply permission checks to class-based views, you can use the PermissionRequiredMixin:
This mixin, just like the permission_required\ndecorator, checks whether the user accessing a view has all given\npermissions. You should specify the permission (or an iterable of\npermissions) using the permission_required parameter:
from django.contrib.auth.mixins import PermissionRequiredMixin\n\nclass MyView(PermissionRequiredMixin, View):\n permission_required = 'polls.can_vote'\n # Or multiple of permissions:\n permission_required = ('polls.can_open', 'polls.can_edit')\nYou can set any of the parameters of\nAccessMixin to customize the handling\nof unauthorized users.
You may also override these methods:
\nReturns an iterable of permission names used by the mixin. Defaults to\nthe permission_required attribute, converted to a tuple if\nnecessary.
Returns a boolean denoting whether the current user has permission to\nexecute the decorated view. By default, this returns the result of\ncalling has_perms() with the\nlist of permissions returned by get_permission_required().
Django provides several views that you can use for handling login, logout, and\npassword management. These make use of the stock auth forms but you can pass in your own forms as well.
\nDjango provides no default template for the authentication views. You should\ncreate your own templates for the views you want to use. The template context\nis documented in each view, see All authentication views.
\nThere are different methods to implement these views in your project. The\neasiest way is to include the provided URLconf in django.contrib.auth.urls\nin your own URLconf, for example:
urlpatterns = [\n url('^', include('django.contrib.auth.urls')),\n]\nThis will include the following URL patterns:
\n^login/$ [name='login']\n^logout/$ [name='logout']\n^password_change/$ [name='password_change']\n^password_change/done/$ [name='password_change_done']\n^password_reset/$ [name='password_reset']\n^password_reset/done/$ [name='password_reset_done']\n^reset/(?P<uidb64>[0-9A-Za-z_\\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$ [name='password_reset_confirm']\n^reset/done/$ [name='password_reset_complete']\nThe views provide a URL name for easier reference. See the URL\ndocumentation for details on using named URL patterns.
\nIf you want more control over your URLs, you can reference a specific view in\nyour URLconf:
\nfrom django.contrib.auth import views as auth_views\n\nurlpatterns = [\n url('^change-password/$', auth_views.password_change),\n]\nThe views have optional arguments you can use to alter the behavior of the\nview. For example, if you want to change the template name a view uses, you can\nprovide the template_name argument. A way to do this is to provide keyword\narguments in the URLconf, these will be passed on to the view. For example:
urlpatterns = [\n url(\n '^change-password/$',\n auth_views.password_change,\n {'template_name': 'change-password.html'}\n ),\n]\nAll views return a TemplateResponse\ninstance, which allows you to easily customize the response data before\nrendering. A way to do this is to wrap a view in your own view:
from django.contrib.auth import views\n\ndef change_password(request):\n template_response = views.password_change(request)\n # Do something with `template_response`\n return template_response\nFor more details, see the TemplateResponse documentation.
\nThis is a list with all the views django.contrib.auth provides. For\nimplementation details see Using the views.
URL name: login
See the URL documentation for details on using\nnamed URL patterns.
\nOptional arguments:
\ntemplate_name: The name of a template to display for the view used to\nlog the user in. Defaults to registration/login.html.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after login. Defaults to next.
authentication_form: A callable (typically just a form class) to\nuse for authentication. Defaults to\nAuthenticationForm.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Here’s what django.contrib.auth.views.login does:
If called via GET, it displays a login form that POSTs to the\nsame URL. More on this in a bit.
If called via POST with user submitted credentials, it tries to log\nthe user in. If login is successful, the view redirects to the URL\nspecified in next. If next isn’t provided, it redirects to\nsettings.LOGIN_REDIRECT_URL (which\ndefaults to /accounts/profile/). If login isn’t successful, it\nredisplays the login form.
It’s your responsibility to provide the html for the login template\n, called registration/login.html by default. This template gets passed\nfour template context variables:
form: A Form object representing the\nAuthenticationForm.
next: The URL to redirect to after successful login. This may\ncontain a query string, too.
site: The current Site,\naccording to the SITE_ID setting. If you don’t have the\nsite framework installed, this will be set to an instance of\nRequestSite, which derives the\nsite name and domain from the current\nHttpRequest.
site_name: An alias for site.name. If you don’t have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The “sites” framework.
If you’d prefer not to call the template registration/login.html,\nyou can pass the template_name parameter via the extra arguments to\nthe view in your URLconf. For example, this URLconf line would use\nmyapp/login.html instead:
url(r'^accounts/login/$', auth_views.login, {'template_name': 'myapp/login.html'}),\nYou can also specify the name of the GET field which contains the URL\nto redirect to after login by passing redirect_field_name to the view.\nBy default, the field is called next.
Here’s a sample registration/login.html template you can use as a\nstarting point. It assumes you have a base.html template that\ndefines a content block:
{% extends "base.html" %}\n\n{% block content %}\n\n{% if form.errors %}\n<p>Your username and password didn't match. Please try again.</p>\n{% endif %}\n\n{% if next %}\n {% if user.is_authenticated %}\n <p>Your account doesn't have access to this page. To proceed,\n please login with an account that has access.</p>\n {% else %}\n <p>Please login to see this page.</p>\n {% endif %}\n{% endif %}\n\n<form method="post" action="{% url 'login' %}">\n{% csrf_token %}\n<table>\n<tr>\n <td>{{ form.username.label_tag }}</td>\n <td>{{ form.username }}</td>\n</tr>\n<tr>\n <td>{{ form.password.label_tag }}</td>\n <td>{{ form.password }}</td>\n</tr>\n</table>\n\n<input type="submit" value="login" />\n<input type="hidden" name="next" value="{{ next }}" />\n</form>\n\n{# Assumes you setup the password_reset view in your URLconf #}\n<p><a href="{% url 'password_reset' %}">Lost password?</a></p>\n\n{% endblock %}\nIf you have customized authentication (see\nCustomizing Authentication) you can pass\na custom authentication form to the login view via the\nauthentication_form parameter. This form must accept a request\nkeyword argument in its __init__ method, and provide a get_user()\nmethod which returns the authenticated user object (this method is only\never called after successful form validation).
Logs a user out.
\nURL name: logout
Optional arguments:
\nnext_page: The URL to redirect to after logout.
template_name: The full name of a template to display after\nlogging the user out. Defaults to\nregistration/logged_out.html if no argument is supplied.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after log out. Defaults to next. Overrides the\nnext_page URL if the given GET parameter is passed.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Template context:
\ntitle: The string “Logged out”, localized.
site: The current Site,\naccording to the SITE_ID setting. If you don’t have the\nsite framework installed, this will be set to an instance of\nRequestSite, which derives the\nsite name and domain from the current\nHttpRequest.
site_name: An alias for site.name. If you don’t have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The “sites” framework.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Logs a user out, then redirects to the login page.
\nURL name: No default URL provided
\nOptional arguments:
\nlogin_url: The URL of the login page to redirect to.\nDefaults to settings.LOGIN_URL if not supplied.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Allows a user to change their password.
\nURL name: password_change
Optional arguments:
\ntemplate_name: The full name of a template to use for\ndisplaying the password change form. Defaults to\nregistration/password_change_form.html if not supplied.
post_change_redirect: The URL to redirect to after a successful\npassword change.
password_change_form: A custom “change password” form which must\naccept a user keyword argument. The form is responsible for\nactually changing the user’s password. Defaults to\nPasswordChangeForm.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Template context:
\nform: The password change form (see password_change_form above).
The page shown after a user has changed their password.
\nURL name: password_change_done
Optional arguments:
\ntemplate_name: The full name of a template to use.\nDefaults to registration/password_change_done.html if not\nsupplied.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Allows a user to reset their password by generating a one-time use link\nthat can be used to reset the password, and sending that link to the\nuser’s registered email address.
\nIf the email address provided does not exist in the system, this view\nwon’t send an email, but the user won’t receive any error message either.\nThis prevents information leaking to potential attackers. If you want to\nprovide an error message in this case, you can subclass\nPasswordResetForm and use the\npassword_reset_form argument.
Users flagged with an unusable password (see\nset_unusable_password() aren’t\nallowed to request a password reset to prevent misuse when using an\nexternal authentication source like LDAP. Note that they won’t receive any\nerror message since this would expose their account’s existence but no\nmail will be sent either.
URL name: password_reset
Optional arguments:
\ntemplate_name: The full name of a template to use for\ndisplaying the password reset form. Defaults to\nregistration/password_reset_form.html if not supplied.
email_template_name: The full name of a template to use for\ngenerating the email with the reset password link. Defaults to\nregistration/password_reset_email.html if not supplied.
subject_template_name: The full name of a template to use for\nthe subject of the email with the reset password link. Defaults\nto registration/password_reset_subject.txt if not supplied.
password_reset_form: Form that will be used to get the email of\nthe user to reset the password for. Defaults to\nPasswordResetForm.
token_generator: Instance of the class to check the one time link.\nThis will default to default_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
post_reset_redirect: The URL to redirect to after a successful\npassword reset request.
from_email: A valid email address. By default Django uses\nthe DEFAULT_FROM_EMAIL.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
html_email_template_name: The full name of a template to use\nfor generating a text/html multipart email with the password reset\nlink. By default, HTML email is not sent.
extra_email_context: A dictionary of context data that will available\nin the email template.
Template context:
\nform: The form (see password_reset_form above) for resetting\nthe user’s password.
Email template context:
\nemail: An alias for user.email
user: The current User,\naccording to the email form field. Only active users are able to\nreset their passwords (User.is_active is True).
site_name: An alias for site.name. If you don’t have the site\nframework installed, this will be set to the value of\nrequest.META['SERVER_NAME'].\nFor more on sites, see The “sites” framework.
domain: An alias for site.domain. If you don’t have the site\nframework installed, this will be set to the value of\nrequest.get_host().
protocol: http or https
uid: The user’s primary key encoded in base 64.
token: Token to check that the reset link is valid.
Sample registration/password_reset_email.html (email body template):
Someone asked for password reset for email {{ email }}. Follow the link below:\n{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}\nThe same template context is used for subject template. Subject must be\nsingle line plain text string.
\nThe page shown after a user has been emailed a link to reset their\npassword. This view is called by default if the password_reset() view\ndoesn’t have an explicit post_reset_redirect URL set.
URL name: password_reset_done
Optional arguments:
\ntemplate_name: The full name of a template to use.\nDefaults to registration/password_reset_done.html if not\nsupplied.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Presents a form for entering a new password.
\nURL name: password_reset_confirm
Optional arguments:
\nuidb64: The user’s id encoded in base 64. Defaults to None.
token: Token to check that the password is valid. Defaults to\nNone.
template_name: The full name of a template to display the confirm\npassword view. Default value is registration/password_reset_confirm.html.
token_generator: Instance of the class to check the password. This\nwill default to default_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
set_password_form: Form that will be used to set the password.\nDefaults to SetPasswordForm
post_reset_redirect: URL to redirect after the password reset\ndone. Defaults to None.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Template context:
\nform: The form (see set_password_form above) for setting the\nnew user’s password.
validlink: Boolean, True if the link (combination of uidb64 and\ntoken) is valid or unused yet.
Presents a view which informs the user that the password has been\nsuccessfully changed.
\nURL name: password_reset_complete
Optional arguments:
\ntemplate_name: The full name of a template to display the view.\nDefaults to registration/password_reset_complete.html.
current_app: A hint indicating which application contains the current\nview. See the namespaced URL resolution strategy for more information.
extra_context: A dictionary of context data that will be added to the\ndefault context data passed to the template.
Redirects to the login page, and then back to another URL after a\nsuccessful login.
\nRequired arguments:
\nnext: The URL to redirect to after a successful login.
Optional arguments:
\nlogin_url: The URL of the login page to redirect to.\nDefaults to settings.LOGIN_URL if not supplied.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after log out. Overrides next if the given\nGET parameter is passed.
If you don’t want to use the built-in views, but want the convenience of not\nhaving to write forms for this functionality, the authentication system\nprovides several built-in forms located in django.contrib.auth.forms:
A form used in the admin interface to change a user’s password.
\nTakes the user as the first positional argument.
A form for logging a user in.
\nTakes request as its first positional argument, which is stored on the\nform instance for use by sub-classes.
By default, AuthenticationForm rejects users whose is_active\nflag is set to False. You may override this behavior with a custom\npolicy to determine which users can log in. Do this with a custom form\nthat subclasses AuthenticationForm and overrides the\nconfirm_login_allowed() method. This method should raise a\nValidationError if the given user may\nnot log in.
For example, to allow all users to log in regardless of “active”\nstatus:
\nfrom django.contrib.auth.forms import AuthenticationForm\n\nclass AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):\n def confirm_login_allowed(self, user):\n pass\nOr to allow only some active users to log in:
\nclass PickyAuthenticationForm(AuthenticationForm):\n def confirm_login_allowed(self, user):\n if not user.is_active:\n raise forms.ValidationError(\n _("This account is inactive."),\n code='inactive',\n )\n if user.username.startswith('b'):\n raise forms.ValidationError(\n _("Sorry, accounts starting with 'b' aren't welcome here."),\n code='no_b_users',\n )\nA form for allowing a user to change their password.
\nA form for generating and emailing a one-time use link to reset a\nuser’s password.
\nUses the arguments to send an EmailMultiAlternatives.\nCan be overridden to customize how the email is sent to the user.
subject_template_name – the template for the subject.
email_template_name – the template for the email body.
context – context passed to the subject_template,\nemail_template, and html_email_template (if it is not\nNone).
from_email – the sender’s email.
to_email – the email of the requester.
html_email_template_name – the template for the HTML body;\ndefaults to None, in which case a plain text email is sent.
By default, save() populates the context with the\nsame variables that password_reset()\npasses to its email context.
A form that lets a user change their password without entering the old\npassword.
\nA form used in the admin interface to change a user’s information and\npermissions.
\nUm formulário para criar um novo usuário.
\nThe currently logged-in user and their permissions are made available in the\ntemplate context when you use\nRequestContext.
When rendering a template RequestContext, the\ncurrently logged-in user, either a User\ninstance or an AnonymousUser instance, is\nstored in the template variable {{ user }}:
{% if user.is_authenticated %}\n <p>Welcome, {{ user.username }}. Thanks for logging in.</p>\n{% else %}\n <p>Welcome, new user. Please log in.</p>\n{% endif %}\nThis template context variable is not available if a RequestContext is not\nbeing used.
The currently logged-in user’s permissions are stored in the template variable\n{{ perms }}. This is an instance of\ndjango.contrib.auth.context_processors.PermWrapper, which is a\ntemplate-friendly proxy of permissions.
In the {{ perms }} object, single-attribute lookup is a proxy to\nUser.has_module_perms.\nThis example would display True if the logged-in user had any permissions\nin the foo app:
{{ perms.foo }}\nTwo-level-attribute lookup is a proxy to\nUser.has_perm. This example\nwould display True if the logged-in user had the permission\nfoo.can_vote:
{{ perms.foo.can_vote }}\nThus, you can check permissions in template {% if %} statements:
{% if perms.foo %}\n <p>You have permission to do something in the foo app.</p>\n {% if perms.foo.can_vote %}\n <p>You can vote!</p>\n {% endif %}\n {% if perms.foo.can_drive %}\n <p>You can drive!</p>\n {% endif %}\n{% else %}\n <p>You don't have permission to do anything in the foo app.</p>\n{% endif %}\nIt is possible to also look permissions up by {% if in %} statements.\nFor example:
{% if 'foo' in perms %}\n {% if 'foo.can_vote' in perms %}\n <p>In lookup works, too.</p>\n {% endif %}\n{% endif %}\nWhen you have both django.contrib.admin and django.contrib.auth\ninstalled, the admin provides a convenient way to view and manage users,\ngroups, and permissions. Users can be created and deleted like any Django\nmodel. Groups can be created, and permissions can be assigned to users or\ngroups. A log of user edits to models made within the admin is also stored and\ndisplayed.
You should see a link to “Users” in the “Auth”\nsection of the main admin index page. The “Add user” admin page is different\nthan standard admin pages in that it requires you to choose a username and\npassword before allowing you to edit the rest of the user’s fields.
\nAlso note: if you want a user account to be able to create users using the\nDjango admin site, you’ll need to give them permission to add users and\nchange users (i.e., the “Add user” and “Change user” permissions). If an\naccount has permission to add users but not to change them, that account won’t\nbe able to add users. Why? Because if you have permission to add users, you\nhave the power to create superusers, which can then, in turn, change other\nusers. So Django requires add and change permissions as a slight security\nmeasure.
\nBe thoughtful about how you allow users to manage permissions. If you give a\nnon-superuser the ability to edit users, this is ultimately the same as giving\nthem superuser status because they will be able to elevate permissions of\nusers including themselves!
\nUser passwords are not displayed in the admin (nor stored in the database), but\nthe password storage details are displayed.\nIncluded in the display of this information is a link to\na password change form that allows admins to change user passwords.
\n