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.
\nThe most direct way to create users is to use the included\ncreate_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 >` .
\nCreate superusers using the createsuperuser command:
Linux / macOS
$ python manage.py createsuperuser --username=joe --email=joe@example.com\nWindows
...\\> py 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:
\nmanage.py changepassword *username* offers a method\nof changing a user’s password from the command line. It prompts you to\nchange the password of a given user which you must enter twice. If\nthey both match, the new password will be changed immediately. If you\ndo not supply a user, the command will attempt to change the password\nwhose username matches the current system user.
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.
\nMudar a senha de um usuário irá “deslogar” todas as suas sessões. Para detalhes veja ref:session-invalidation-on-password-change.
\nAsynchronous version: aauthenticate()
Use a authenticate() para verificar um conjunto de credenciais. Ela recebe as credenciais como argumentos nomeados, username e password para o caso padrão, e os checa com todos os backends de autenticação, e retornar um objeto User se as credenciais forem válidas para um dos backends. Se as credenciais não forem válidas para qualquer um dos “backends” ou se um “backend” emitir uma PermissionDenied, ele retorna None. Por exemplo:
from django.contrib.auth import authenticate\n\nuser = authenticate(username="john", password="secret")\nif user is not None:\n # A backend authenticated the credentials\n ...\nelse:\n # No backend authenticated the credentials\n ...\nrequest is an optional HttpRequest which is\npassed on the authenticate() method of the authentication backends.
O Django usa sessions e o middleware para vincular o sistema de autenticação dentro dos objetos de requisição.
These provide a request.user attribute\nand a request.auser async method\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.
Você pode distinguí-los com is_authenticated, como a seguir:
if request.user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nOr in an asynchronous view:
\nuser = await request.auser()\nif 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().
Asynchronous version: alogin()
Para “logar” um usuário, em uma “view”, use login(). Essa função recebe um objeto HttpRequest e um objeto User. A login() salva o ID do usuário na sessão, usando o framework de sessão do Django.
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 as funções authenticate() e login():
from django.contrib.auth import authenticate, login\n\n\ndef my_view(request):\n username = request.POST["username"]\n password = request.POST["password"]\n user = authenticate(request, username=username, password=password)\n if user is not None:\n login(request, user)\n # Redirect to a success page.\n ...\n else:\n # Return an 'invalid login' error message.\n ...\nQuando um usuário se “loga” no sistema, o ID do usuário e o “backend” que foi usado para autenticação são salvos na sessão. Isso permite que o mesmo “backend” de autenticação seja usado para retornar detalhes do usuário em uma requisição futura. O “backend” de autenticação a ser salvo na sessão é selecionado da seguinte maneira:
\nUsa o valor do argumento backend opcional, se fornecido.
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 o backend no AUTHENTICATION_BACKENDS, se houver somente um.
Caso contrário, gera uma exceção.
Nos casos 1 e 2, o valor do argumento backend ou do atributo user.backend deve ser uma string com o caminho de importação na notação de pontos (como aquela encontrada em AUTHENTICATION_BACKENDS), e não a classe de “backend” atual.
Asynchronous version: alogout()
Para finalizar a sessão de um usuário que tenha se autenticado via django.contrib.auth.login(), use django.contrib.auth.logout() dentro de sua view. Ele recebe um objeto HttpRequest e não tem um valor de retorno. Exemplo:
from django.contrib.auth import logout\n\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\nRepare que a logout() não emiti nenhum erro se o usuário não estiver autenticado.
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 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\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return redirect(f"{settings.LOGIN_URL}?next={request.path}")\n # ...\n… ou mostrar uma mensagem de erro:
\nfrom django.shortcuts import render\n\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#Como atalho, você pode usar o decorador conveniente login_required()
from django.contrib.auth.decorators import login_required\n\n\n@login_required\ndef my_view(request): ...\nA login_required() faz o seguinte:
Se o usuário não registrou seu acesso, redireciona para settings.LOGIN_URL, passando caminho absoluto corrente na “querystring”. Example: /accounts/login/?next=/polls/3/.
Se o usuário está autenticado, executa a “view” normalmente. O código da “view” é livre para assumir que o usuário está autenticado.
Por padrão, o caminho para o qual o usuário deve ser redirecionado após a autenticação está armazenado em um parâmetro na “query string” chamado "next". Se preferir usar um outro nome para este parâmetro, a login_required() recebe um parâmetro adicional redirect_field_name:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(redirect_field_name="my_redirect_field")\ndef my_view(request): ...\nRepare que se você fornecer um valor para redirect_field_name, você deverá também personalizar seus templates de login, já que a variável de contexto do template a qual armazena o caminho de redirecionamento irá usar o valor de redirect_field_name como sua chave ao invés de "next" (o padrão).
A login_required() também receve um parâmetro adicional chamado login_url. Example:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(login_url="/accounts/login/")\ndef my_view(request): ...\nRepare que se você não especificar o parâmetro login_url, terá que ter certeza que o settings.LOGIN_URL e sua “view” de login estão associados corretamente. Por exemplo, usando os padrões, adicione a seguinte linha ao seu URLconf:
from django.contrib.auth import views as auth_views\n\npath("accounts/login/", auth_views.LoginView.as_view()),\nA settings.LOGIN_URL também aceita nome de funções “view”e named URL patterns. Isso permite a você mapear livremente sua “view” de login dentro do URconf sem ter que atualizar o arquivo de definições.
LoginRequiredMixin mixinLink para este cabeçalho#Quando usar class-based views, você pode ter o mesmo comportamento que o login_required usando o LoginRequiredMixin. Este “mixin” deve estar na última posição mais a esquerda na lista de herança.
Se a “view” estiver usando o “mixin”, todos as requisições de usuário não autenticados serão redirecionadas para a página de login ou mostram um erro de falta de permissão HTTP 403, dependendo da definição do parâmetro raise_exception.
Você pode definir qualquer dos parâmetros da AccessMixin para personalizar a maneira como o sistema lida com usuários não autorizados:
from django.contrib.auth.mixins import LoginRequiredMixin\n\n\nclass MyView(LoginRequiredMixin, View):\n login_url = "/login/"\n redirect_field_name = "redirect_to"\nlogin_not_required decoratorLink para este cabeçalho#When LoginRequiredMiddleware is\ninstalled, all views require authentication by default. Some views, such as the\nlogin view, may need to disable this behavior.
Allows unauthenticated requests to this view when\nLoginRequiredMiddleware is\ninstalled.
Para limitar o acesso baseado em certas permissões ou outros testes, você deve fazer o mesmo que foi descrito na seção anterior.
\nYou can run your test on request.user in\nthe view directly. For example, this view checks to make sure the user has an\nemail in the desired domain and if not, redirects to the login page:
from django.shortcuts import redirect\n\n\ndef my_view(request):\n if not request.user.email.endswith("@example.com"):\n return redirect("/login/?next=%s" % request.path)\n # ...\nComo atalho, você pode usar o conveniente decorador user_passes_test o qual executa um redirecionamento quando a função passada retorna False:
from django.contrib.auth.decorators import user_passes_test\n\n\ndef email_check(user):\n return user.email.endswith("@example.com")\n\n\n@user_passes_test(email_check)\ndef my_view(request): ...\nA user_passes_test() recebe um argumento obrigatório: um executável que recebe um objeto do tipo User e retorna True se é permitido ao usuário acessar a página. Note que a user_passes_test() não verifica automaticamente se o User não é anônimo.
A user_passes_test() pode receber dois argumentos opcionais:
login_urlPermite que você especifique a URL para a qual os usuários que não passam no teste sejam redirecionados. Pode ser uma página de autenticação e seu padrão é o que estiver definido em settings.LOGIN_URL se você não especificar nenhum.
redirect_field_nameO mesmo que login_required(). Se definido como None ele será removido da URL, o que você talvez queira que aconteça se você estiver redirecionando usuários que não passem no teste para uma página que não é a de autenticação e que não tenha o “next page”.
Por exemplo:
\n@user_passes_test(email_check, login_url="/login/")\ndef my_view(request): ...\nQuando usar as “views” baseadas em classes, você pode usar o UserPassesTestMixin para isso.
Você tem que sobrescrever o método test_func() da classe para fornecer o teste a ser executado. Mais ainda, você pode definir qualquer dos parâmetros da AccessMixin para personalizar a manipulação de usuários não autorizados:
from django.contrib.auth.mixins import UserPassesTestMixin\n\n\nclass MyView(UserPassesTestMixin, View):\n def test_func(self):\n return self.request.user.email.endswith("@example.com")\nVocê pode também sobrescrever o método get_test_func() para que seja possível para o “mixin” usar um nome de função diferente para suas verificações (ao invés de test_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\n@permission_required("polls.add_choice")\ndef my_view(request): ...\nJust like the has_perm() method,\npermission names take the form "<app label>.<permission codename>"\n(i.e. polls.add_choice for a permission on a model in the polls\napplication).
O decorador pode também receber um iterável de permissões, e neste caso o usuário deve ter todas as permissões para acessar a “view”.
\nNote que a permission_required() também recebe um parâmetro login_url opcional:
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice", login_url="/loginpage/")\ndef my_view(request): ...\nAssim como no decorador login_required(), o padrão para login_url é a definição de settings.LOGIN_URL.
Se o parâmetro raise_exception é fornecido, o decorador irá emitir um PermissionDenied, mostrando o the 403 (HTTP Forbidden) view ao invés de redirecionar para uma página de autenticação.
Se quiser usar o raise_exception mas também dar aos usuários a chance de se autenticar, você pode adicionar o decorador login_required():
from django.contrib.auth.decorators import login_required, permission_required\n\n\n@login_required\n@permission_required("polls.add_choice", raise_exception=True)\ndef my_view(request): ...\nThis also avoids a redirect loop when LoginView’s\nredirect_authenticated_user=True and the logged-in user doesn’t have\nall of the required permissions.
PermissionRequiredMixin mixinLink para este cabeçalho#Para aplicar verificações de permissões a “views” baseadas em classes, você pode usar o PermissionRequiredMixin:
Este “mixin”, tal como o decorador permission_required, verifica se o usuário que está acessando a “view” tem todas as permissões. Você deve especificar as permissões (ou um iterável de permissões) usando o parâmetro permission_required:
from django.contrib.auth.mixins import PermissionRequiredMixin\n\n\nclass MyView(PermissionRequiredMixin, View):\n permission_required = "polls.add_choice"\n # Or multiple of permissions:\n permission_required = ["polls.view_choice", "polls.change_choice"]\nVocê pode definir qualquer um dos parâmetros da AccessMixin para personalizar o tratamento de usuários não autorizados.
Você pode também sobrescrever estes métodos:
\nRetorna um iterável de nomes de permissões usados pelo “mixin”. O padrão é o que está definido no atributo permission_required, convertido para uma tupla se necessário.
Retorna um booleano informando se o usuário corrente tem permissão para executar a “view” decorada. Por padrão, ele retorna o resultado da chamado do has_perms() com uma lista de permissões retornada pelo get_permission_required().
O Django disponibiliza várias views que você pode utilizar para lidar com login (autenticação), logout (saída), e alteração de senhas. Essas views fazem uso dos stock auth forms, porém, você pode passar/utilizar seus próprios forms (formulários), caso prefira.
\nO Django não disponibiliza um template padrão para as views de autenticação. Você deve criar seus próprios templates para as views que quiser uitlizar. O contexto do template está documentado em cada view. veja: Todas as views de autenticação.
\nExistem formas diferentes de implementar essas views em seu projeto. A mais fácil delas é: incluir a URLconf disponível em django.contrib.auth.urls dentro da sua própria URLconf. Por exemplo:
urlpatterns = [\n path("accounts/", include("django.contrib.auth.urls")),\n]\nThis will include the following URL patterns:
\naccounts/login/ [name='login']\naccounts/logout/ [name='logout']\naccounts/password_change/ [name='password_change']\naccounts/password_change/done/ [name='password_change_done']\naccounts/password_reset/ [name='password_reset']\naccounts/password_reset/done/ [name='password_reset_done']\naccounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']\naccounts/reset/done/ [name='password_reset_complete']\nAs views disponibilizam um nome de URL, para serem referênciadas com mais facilidade. Veja the URL documentation para mais detalhes sobre como usar padrões de URL nomeados.
\nCaso queira ter mais controle sobre suas URLs, você pode referenciar uma view específica em seu URLconf:
\nfrom django.contrib.auth import views as auth_views\n\nurlpatterns = [\n path("change-password/", auth_views.PasswordChangeView.as_view()),\n]\nAs views tem argumentos opcionais que podem ser utilizados para alterar o comportamento delas. Por exemplo, para mudar o nome do template de uma view, basta passar o argumento template_name. Uma maneira de fazer isso, é colocando **kwargs (argumentos de palvras chave) no seu URLconf. Estes argumentos serão passados para a view. Por exemplo:
urlpatterns = [\n path(\n "change-password/",\n auth_views.PasswordChangeView.as_view(template_name="change-password.html"),\n ),\n]\nAll views are class-based, which allows\nyou to easily customize them by subclassing.
\nEssa é uma lista com todas as views que django.contrib.auth disponibiliza. Para detalhes de implementação, veja Usando as views.
Nome da URL: login
Para detalhes sobre como usar padrões de URLs nomeadas, veja: the URL documentation
\nMétodos e Atributos
\nThe name of a template to display for the view used to log the user in.\nDefaults to registration/login.html.
The URL to redirect to after login. Defaults to\nLOGIN_REDIRECT_URL.
The name of a GET field containing the URL to redirect to after\nlogin. Defaults to next. Overrides the\nget_default_redirect_url() URL if the given GET parameter is\npassed.
A callable (typically a form class) to use for authentication. Defaults\nto AuthenticationForm.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nA boolean that controls whether or not authenticated users accessing\nthe login page will be redirected as if they had just successfully\nlogged in. Defaults to False.
A set of hosts, in addition to request.get_host(), that are safe for redirecting\nafter login. Defaults to an empty set.
Returns the URL to redirect to after login. The default implementation\nresolves and returns next_page if set, or\nLOGIN_REDIRECT_URL otherwise.
Isto é o que “LoginView” faz:
\nSe for chamado via GET, ele mostrará um formulário de login que enviará um POST para a mesma URL. Explicaremos isso melhor em um instante.
Se for chamado via POST, com as credenciais enviadas pelo usuário, ele vai tentar logar o usuário. Se o login der certo, a view irá redirecionar para a URL especificada em next. Se next não tiver sido definido, então a view redirecionará para settings.LOGIN_REDIRECT_URL (which defaults to /accounts/profile/). Se o login não der certo, o formulário de login será exibido novamente.
A responsabilidade de colocar o html, para o template de login, é toda sua. Esse template se chama registration/login.html por padrão. Ele recebe 4 variáveis de contexto de template.
form: Um objeto Form que representa a AuthenticationForm.
next: A URL para a qual será redirecionado depois de uma autenticação bem sucedida. Esta pode conter também uma “query string”.
site: A current Site atual, de acordo com a configuração SITE_ID. Se você não tiver o framework de sites instalado, então site será definido como uma instância da classe of RequestSite, que pegará o nome e o domínio do site da HttpRequest atual.
site_name: Um alias/atalho para site.name. Se você não tiver o framework de sites instalado, então site_name receberá o valor de de request.META['SERVER_NAME']. Para mais informações sobre sites, veja The “sites” framework.
Caso prefira não chamar o template :arquivo:`registration/login.html`, você pode passar o parâmetro template_name como argumento extra para o método ``as_view` na sua URLconf. Por exemplo, esta linha URLconf usaria :arquivo:`myapp/login.html` como alternativa:
path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),\nVocê também pode escolher o nome do campo GET que contém a URL para redirecionar após o login usando redirect_field_name. Por padrão, o campo é chamado de next.
Você pode usar o seguinte exemplo de template registration/login.html como ponto de partida. Esse exemplo assume que você tenha um template base.html que defina um bloco content:
{% 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 set up 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 Customizing Authentication) you can use a custom authentication form by\nsetting the authentication_form attribute. This form must accept a\nrequest keyword argument in its __init__() method and provide a\nget_user() method which returns the authenticated user object (this\nmethod is only ever called after successful form validation).
Logs a user out on POST requests.
Nome da URL: logout
Atributos:
\nThe URL to redirect to after logout. Defaults to\nLOGOUT_REDIRECT_URL.
The full name of a template to display after logging the user out.\nDefaults to registration/logged_out.html.
The name of a GET field containing the URL to redirect to after log\nout. Defaults to 'next'. Overrides the\nnext_page URL if the given GET parameter is\npassed.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nA set of hosts, in addition to request.get_host(), that are safe for redirecting\nafter logout. Defaults to an empty set.
Contexto de Template:
\ntitle: Versão localizada da string “Logged out” (deslogado). Ou seja, você pode substituir “Logged out” por uma versão traduziada (como deslogado) para o idioma que desejar.
site: A current Site atual, de acordo com a configuração SITE_ID. Se você não tiver o framework de sites instalado, então site será definido como uma instância da classe of RequestSite, que pegará o nome e o domínio do site da HttpRequest atual.
site_name: Um alias/atalho para site.name. Se você não tiver o framework de sites instalado, então site_name receberá o valor de de request.META['SERVER_NAME']. Para mais informações sobre sites, veja The “sites” framework.
Logs a user out on POST requests, then redirects to the login page.
Nome da URL: não é fornecido uma URL padrão.
\nArgumentos opcionais:
\nlogin_url: a URL da página de login, para onde o usuário deve ser redirecionado. Caso esse parâmetro não seja passado, ele irá tomar o o valor settings.LOGIN_URL por padrão.
Nome da URL: password_change
Permite a um usuário alterar sua senha.
\nAtributos:
\nThe full name of a template to use for displaying the password change\nform. Defaults to registration/password_change_form.html if not\nsupplied.
The URL to redirect to after a successful password change. Defaults to\n'password_change_done'.
A custom “change password” form which must accept a user keyword\nargument. The form is responsible for actually changing the user’s\npassword. Defaults to\nPasswordChangeForm.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nContexto de Template:
\nform: The password change form (see form_class above).
Nome da URL: password_change_done
A pagina que é exibida após um usuário ter alterado sua senha.
\nAtributos:
\nThe full name of a template to use. Defaults to\nregistration/password_change_done.html if not supplied.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nNome da URL: password_reset
Gera um link de uso único, que permite o usuário cadastrar uma nova senha. Esse link será enviado para o e-mail do usuário.
\nThis view will send an email if the following conditions are met:
\nThe email address provided exists in the system.
The requested user is active (User.is_active is True).
The requested user has a usable password. Users flagged with an unusable\npassword (see\nset_unusable_password()) aren’t\nallowed to request a password reset to prevent misuse when using an\nexternal authentication source like LDAP.
If any of these conditions are not met, no email will be sent, but the\nuser won’t receive any error message either. This prevents information\nleaking to potential attackers. If you want to provide an error message in\nthis case, you can subclass\nPasswordResetForm and use the\nform_class attribute.
Atributos:
\nThe full name of a template to use for displaying the password reset\nform. Defaults to registration/password_reset_form.html if not\nsupplied.
Form that will be used to get the email of the user to reset the\npassword for. Defaults to\nPasswordResetForm.
The full name of a template to use for generating the email with the\nreset password link. Defaults to\nregistration/password_reset_email.html if not supplied.
The full name of a template to use for the subject of the email with\nthe reset password link. Defaults to\nregistration/password_reset_subject.txt if not supplied.
Instance of the class to check the one time link. This will default to\ndefault_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
The URL to redirect to after a successful password reset request.\nDefaults to 'password_reset_done'.
A valid email address. By default Django uses the\nDEFAULT_FROM_EMAIL.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nThe full name of a template to use for generating a\ntext/html multipart email with the password reset link. By\ndefault, HTML email is not sent.
\nA dictionary of context data that will be available in the email\ntemplate. It can be used to override default template context values\nlisted below e.g. domain.
Contexto de Template:
\nform: The form (see form_class above) for resetting the user’s\npassword.
O contexto do template do email:
\nemail: um apelido para user.email
user: o usuário do tipo User, de acordo com o campo do email do formulário. Somente usuários ativos conseguem resetar suas senhas (User.is_active is True).
site_name: Um alias/atalho para site.name. Se você não tiver o framework de sites instalado, então site_name receberá o valor de de request.META['SERVER_NAME']. Para mais informações sobre sites, veja The “sites” framework.
domain: um apelido para site.domain. Se você não tem o framework “site” instalado, este parâmetro será setado com o valor do request.get_host().
protocol: http ou https
uid: a chave primária do usuário codificada em base 64
token: o “Token” para verificar se o link de reset é valido.
Exemplo de registration/password_reset_email.html (template do corpo do email):
Someone asked for password reset for email {{ email }}. Follow the link below:\n{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}\nO mesmo contexto de template é usado para o template do assunto. O assunto de ser uma única em uma string de texto plano.
\nNome da URL: password_reset_done
The page shown after a user has been emailed a link to reset their\npassword. This view is called by default if the PasswordResetView\ndoesn’t have an explicit success_url URL set.
Atributos:
\nThe full name of a template to use. Defaults to\nregistration/password_reset_done.html if not supplied.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nNome da URL: password_reset_confirm
Apresenta uma formulário para informar uma nova senha.
\nArgumentos palavra-chave da URL:
\nuidb64: The user’s id encoded in base 64.
token: Token to check that the password is valid.
Atributos:
\nThe full name of a template to display the confirm password view.\nDefault value is registration/password_reset_confirm.html.
Instance of the class to check the password. This will default to\ndefault_token_generator, it’s an instance of\ndjango.contrib.auth.tokens.PasswordResetTokenGenerator.
A boolean indicating if the user should be automatically authenticated\nafter a successful password reset. Defaults to False.
A dotted path to the authentication backend to use when authenticating\na user if post_reset_login is True. Required only if you have\nmultiple AUTHENTICATION_BACKENDS configured. Defaults to\nNone.
Form that will be used to set the password. Defaults to\nSetPasswordForm.
URL to redirect after the password reset done. Defaults to\n'password_reset_complete'.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nToken parameter displayed as a component of password reset URLs.\nDefaults to 'set-password'.
Contexto de Template:
\nform: The form (see form_class above) for setting the new user’s\npassword.
validlink: Boolenano, verdadeiro se o link (combinação de uidb64 e token) é válido ou ainda não utilizado.
Nome da URL: password_reset_complete
Apresentando a “view” a qual informa ao usuário que sua senha foi alterada com sucesso.
\nAtributos:
\nThe full name of a template to display the view. Defaults to\nregistration/password_reset_complete.html.
A dictionary of context data that will be added to the default context\ndata passed to the template.
\nRedireciona para a página de autenticação, e então retornar a outra URL depois de uma autenticação com sucesso.
\nArgumentos requeridos:
\nnext: URL para a qual é redirecionado depois de uma autenticação bem sucedida.
Argumentos opcionais:
\nlogin_url: a URL da página de login, para onde o usuário deve ser redirecionado. Caso esse parâmetro não seja passado, ele irá tomar o o valor settings.LOGIN_URL por padrão.
redirect_field_name: The name of a GET field containing the\nURL to redirect to after login. Overrides next if the given\nGET parameter is passed.
Caso não queira utilizar a “views” embutidas no Django, mas quer a conveniência de não escrever formulários para esta funcionalidade, o sistema de autenticação fornece vários formulários prontos localizados em django.contrib.auth.forms:
A form used in the admin interface to change a user’s password, including\nthe ability to set an unusable password, which blocks the\nuser from logging in with password-based authentication.
Recebe o user como primeiro argumento posicional.
A form used in the admin interface to create a new user. Inherits from\nUserCreationForm.
It includes an additional usable_password field, enabled by default. If\nusable_password is enabled, it verifies that password1 and\npassword2 are non empty and match, validates the password using\nvalidate_password(), and\nsets the user’s password using\nset_password().\nIf usable_password is disabled, no password validation is done, and\npassword-based authentication is disabled for the user by calling\nset_unusable_password().
Um formulário para autenticar o usuário.
\nRecebe o request como seu primeiro parâmetro posicional, o qual é armazenado na instância do formulário para ser usado pelas sub-classes.
Por padrão, o AuthenticationForm rejeita usuários que tenham o indicador is_active definido como False. Você pode alterar este comportamento com uma regra personalizada para determinar quais usuários podem se autenticar. Faça isso com um formulário personalizado que herda a AuthenticationForm e sobreescreve o método confirm_login_allowed(). Este método deve emitir uma ValidationError se o usuário fornecido não deve ser autenticado.
Por exemplo, para permitir que todos os usuários se autentiquem independente do status “active”:
\nfrom django.contrib.auth.forms import AuthenticationForm\n\n\nclass AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):\n def confirm_login_allowed(self, user):\n pass\n(In this case, you’ll also need to use an authentication backend that\nallows inactive users, such as\nAllowAllUsersModelBackend.)
Ou para permitir somente alguns usuários ativos a se autenticarem:
\nclass PickyAuthenticationForm(AuthenticationForm):\n def confirm_login_allowed(self, user):\n if not user.is_active:\n raise ValidationError(\n _("This account is inactive."),\n code="inactive",\n )\n if user.username.startswith("b"):\n raise ValidationError(\n _("Sorry, accounts starting with 'b' aren't welcome here."),\n code="no_b_users",\n )\nA ModelForm for creating a new user. This is the\nrecommended base class if you need to customize the user creation form.
Ela tem três campos: username (vindo o modelo do usuário), password1, e password2. Ela verifica se o password1 e o password2 combinam, validando a senha usando a validate_password(), e define a senha do usuário usando o set_password().
Um formulário para permitir que o usuário altere sua senha.
\nUm formulário para gerar e enviar um email com um link de uso único para resetar a senha do usuário.
\nUses the arguments to send an EmailMultiAlternatives.\nCan be overridden to customize how the email is sent to the user. If\nyou choose to override this method, be mindful of handling potential\nexceptions raised due to email sending failures.
subject_template_name – O template para o assunto.
email_template_name – O template para o corpo do email.
context – O contexto passado para o subject_template, email_template, e para o html_email_template (se não for None).
from_email – O email do remetente.
to_email – O email do usuário que requisitou.
html_email_template_name – O template para o corpo HTML; o valor padrão é None, neste caso um email com texto plano sem marcação é enviado.
By default, save() populates the context with the\nsame variables that\nPasswordResetView passes to its\nemail context.
Um formulário que permite ao usuário alterar sua senha sem informar a senha antiga.
\nUm formulário usado na interface de administração para alterar informações e permissões do usuário.
\nInherits from BaseUserCreationForm. To help prevent confusion with\nsimilar usernames, the form doesn’t allow usernames that differ only in\ncase.
O usuário atualmente autenticado e suas permissões são disponibilizadas no contexto do template quando você usa a RequestContext.
Quando a RequestContext renderiza um template, o usuário autenticado no momento, seja uma instância de User ou uma instância de AnonymousUser, são armazenadas em uma variável de template chamada {{ 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 %}\nEsta variável de template não está disponível se um RequestContext não for usado.
As permissões do usuário autenticado são armazenadas na variável {{ perms }} do template. Isso é uma instância de django.contrib.auth.context_processors.PermWrapper, o qual é um “proxy” de permissões amigável ao template.
Evaluating a single-attribute lookup of {{ perms }} as a boolean is a proxy\nto User.has_module_perms(). For example, to check if\nthe logged-in user has any permissions in the foo app:
{% if perms.foo %}\nEvaluating a two-level-attribute lookup as a boolean is a proxy to\nUser.has_perm(). For example,\nto check if the logged-in user has the permission foo.add_vote:
{% if perms.foo.add_vote %}\nHere’s a more complete example of checking permissions in a template:
\n{% if perms.foo %}\n <p>You have permission to do something in the foo app.</p>\n {% if perms.foo.add_vote %}\n <p>You can vote!</p>\n {% endif %}\n {% if perms.foo.add_driving %}\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 %}\nÉ possível também conferir as permissões através das declarações “{% if in %}”. Por exemplo:
\n{% if 'foo' in perms %}\n {% if 'foo.add_vote' in perms %}\n <p>In lookup works, too.</p>\n {% endif %}\n{% endif %}\nQuando você tem instalados “django.contrib.admin” e “django.contrib.auth”, o admin provides um jeito conveniente de visualizar e gerenciar usuários, grupos e permissões. Usuários podem ser criados e deletados como qualquer modelo Django. Grupos podem ser criados, e permissões podem ser dadas a usuários ou grupos. Um registro das edições dos usuários aos modelos é criado no admin e também é armazenado e exibido.
\nYou 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.\nAlternatively, on this page, you can choose a username and disable\npassword-based authentication for the user.
\nTambém observe: se você quer que uma conta de usuário possa criar usuários usando o site do Django admin, você precisará dar permissão para que essa conta adicione usuários e modifique usuários (por exemplo, as permissões “Adicionar usuário” e “Modificar usuário”). Se uma conta tem a permissão de adicionar usuários, mas não de modificá-los, então a conta não poderá adicionar usuários. Por quê? Porque se você tem permissão de adicionar usuários, você tem poder de criar superusuários, que pode, então, criar outros usuários. Então o Django exige permissões para adicionar e modificar como uma leve medida de segurança.
\nSeja consciente sobre como você permite aos usuários que gerenciem as permissões. Se você dá a habilidade de editar usuários a um não superusuário, isso, em última instância, é o mesmo que dá-lo a condição de superusuário, já que ele poderá elevar permissões de usuários, inclusive dele mesmo!
\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 or unset user passwords.
\n