Detta dokument förklarar användningen av Djangos autentiseringssystem i dess standardkonfiguration. Denna konfiguration har utvecklats för att tjäna de vanligaste projektbehoven, hantera ett rimligt brett spektrum av uppgifter och har en noggrann implementering av lösenord och behörigheter. För projekt där autentiseringsbehoven skiljer sig från standardkonfigurationen stöder Django omfattande förlängning och anpassning av autentisering.
\nDjango Authentication tillhandahåller både autentisering och auktorisering tillsammans och kallas i allmänhet autentiseringssystemet, eftersom dessa funktioner är något kopplade.
\nUser-objektLink to this heading#User-objekt är kärnan i autentiseringssystemet. De representerar vanligtvis de personer som interagerar med din webbplats och används för att möjliggöra saker som att begränsa åtkomst, registrera användarprofiler, associera innehåll med skapare etc. Endast en klass av användare finns i Djangos autentiseringsramverk, dvs. 'superusers' eller admin 'staff' användare är bara användarobjekt med speciella attribut inställda, inte olika klasser av användarobjekt.
De primära attributen för standardanvändaren är:
\nSe full API-dokumentation för fullständig referens, dokumentationen som följer är mer uppgiftsorienterad.
Det mest direkta sättet att skapa användare är att använda den inkluderade create_user() hjälpfunktionen:
>>> 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()\nOm du har Django admin installerat kan du också skapa användare interaktivt.
\nSkapa superanvändare med hjälp av kommandot createsuperuser:
Linux / macOS
$ python manage.py createsuperuser --username=joe --email=joe@example.com\nWindows
...\\> py manage.py createsuperuser --username=joe --email=joe@example.com\nDu kommer att bli ombedd att ange ett lösenord. När du har angett ett skapas användaren omedelbart. Om du utelämnar alternativen --username eller --email kommer du att bli tillfrågad om dessa värden.
Django lagrar inte råa (klartext) lösenord i användarmodellen, utan endast en hash (se dokumentation av hur lösenord hanteras för fullständiga detaljer). På grund av detta ska du inte försöka manipulera användarens lösenordsattribut direkt. Det är därför som en hjälpfunktion används när en användare skapas.
\nOm du vill ändra en användares lösenord har du flera alternativ:
\nmanage.py changepassword *username* erbjuder en metod för att ändra en användares lösenord från kommandoraden. Du uppmanas att ändra lösenordet för en viss användare och du måste ange det två gånger. Om båda stämmer överens kommer det nya lösenordet att ändras omedelbart. Om du inte anger någon användare kommer kommandot att försöka ändra lösenordet för den användare vars användarnamn matchar den aktuella systemanvändaren.
Du kan också ändra ett lösenord programmatiskt med 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()\nOm du har Django admin installerat kan du också ändra användarens lösenord på autentiseringssystemets adminsidor.
\nDjango tillhandahåller även views och forms som kan användas för att låta användare ändra sina egna lösenord.
\nOm du ändrar en användares lösenord loggas alla deras sessioner ut. Se Inaktivering av session vid byte av lösenord för mer information.
\nAsynkron version: aauthenticate()
Använd authenticate() för att verifiera en uppsättning autentiseringsuppgifter. Den tar referenser som nyckelordsargument, användarnamn och lösenord för standardfallet, kontrollerar dem mot varje authentication backend, och returnerar ett User-objekt om referensen är giltig för en backend. Om autentiseringsuppgifterna inte är giltiga för någon backend eller om en backend ger upphov till PermissionDenied, returnerar den None. Till exempel:
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 är en valfri HttpRequest som skickas till authenticate()-metoden i autentiseringsbackends.
Django använder sessions och middleware för att koppla autentiseringssystemet till request-objekt.
Dessa tillhandahåller ett request.user-attribut och en request.auser async-metod på varje begäran som representerar den aktuella användaren. Om den aktuella användaren inte har loggat in kommer detta attribut att sättas till en instans av AnonymousUser, annars kommer det att vara en instans av User.
Du kan skilja dem åt med is_authenticated, så här:
if request.user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nEller i en asynkron vy:
\nuser = await request.auser()\nif user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nOm du har en autentiserad användare som du vill koppla till den aktuella sessionen - detta görs med en login()-funktion.
Asynkron version: alogin()
För att logga in en användare från en vy, använd login(). Den tar ett HttpRequest-objekt och ett User-objekt. login() sparar användarens ID i sessionen med hjälp av Djangos sessionsramverk.
Observera att alla uppgifter som anges under den anonyma sessionen sparas i sessionen efter att en användare loggat in.
\nDetta exempel visar hur du kan använda både authenticate() och 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 ...\nNär en användare loggar in sparas användarens ID och den backend som användes för autentisering i användarens session. Detta gör att samma autentiseringsbackend kan hämta användarens uppgifter vid en framtida begäran. Den autentiseringsbackend som ska sparas i sessionen väljs enligt följande:
\nAnvänd värdet för det valfria argumentet backend, om det anges.
Använd värdet på attributet user.backend, om det finns. Detta gör det möjligt att para ihop authenticate() och login(): authenticate() sätter attributet user.backend på det användarobjekt som returneras.
Använd backend i AUTHENTICATION_BACKENDS, om det bara finns en.
I annat fall, skapa ett undantag.
I fall 1 och 2 ska värdet för argumentet backend eller attributet user.backend vara en sträng med prickad importsökväg (som den som finns i AUTHENTICATION_BACKENDS), inte den faktiska backendklassen.
Asynkron version: alogout()
För att logga ut en användare som har loggat in via django.contrib.auth.login(), använd django.contrib.auth.logout() i din vy. Den tar ett HttpRequest-objekt och har inget returvärde. Exempel:
from django.contrib.auth import logout\n\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\nObservera att logout() inte ger några felmeddelanden om användaren inte var inloggad.
När du anropar logout() rensas sessionsdata för den aktuella begäran helt och hållet. Alla befintliga data tas bort. Detta för att förhindra att en annan person använder samma webbläsare för att logga in och få tillgång till den tidigare användarens sessionsdata. Om du vill lägga in något i sessionen som kommer att vara tillgängligt för användaren omedelbart efter utloggning, gör det efter anropet django.contrib.auth.logout().
Det enkla sättet att begränsa åtkomst till sidor är att kontrollera request.user.is_authenticated och antingen omdirigera till en inloggningssida:
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…eller visa ett felmeddelande:
\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 (inloggning krävs)Link to this heading#Som en genväg kan du använda den praktiska login_required() decorator:
from django.contrib.auth.decorators import login_required\n\n\n@login_required\ndef my_view(request): ...\nlogin_required() gör följande:
Om användaren inte är inloggad, omdirigera till settings.LOGIN_URL och ange den aktuella absoluta sökvägen i frågesträngen. Exempel: /accounts/login/?next=/polls/3/.
Om användaren är inloggad körs vyn normalt. Det står vykoden fritt att anta att användaren är inloggad.
Som standard lagras den sökväg som användaren ska omdirigeras till efter framgångsrik autentisering i en frågesträngsparameter som heter "next". Om du föredrar att använda ett annat namn för denna parameter, login_required() tar en valfri redirect_field_name parameter:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(redirect_field_name="my_redirect_field")\ndef my_view(request): ...\nObservera att om du anger ett värde för redirect_field_name kommer du troligen att behöva anpassa din inloggningsmall också, eftersom mallens kontextvariabel som lagrar omdirigeringssökvägen kommer att använda värdet för redirect_field_name som nyckel i stället för "next" (standard).
login_required() tar också en valfri login_url parameter. Exempel:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(login_url="/accounts/login/")\ndef my_view(request): ...\nObservera att om du inte anger parametern login_url måste du se till att settings.LOGIN_URL och din inloggningsvy är korrekt associerade. Använd till exempel standardinställningarna och lägg till följande rader i din URLconf:
from django.contrib.auth import views as auth_views\n\npath("accounts/login/", auth_views.LoginView.as_view()),\nInställningen settings.LOGIN_URL accepterar även namn på vyfunktioner och named URL patterns. Detta gör att du fritt kan ändra din inloggningsvy i din URLconf utan att behöva uppdatera inställningen.
LoginRequiredMixin mixinLink to this heading#När du använder klassbaserade vyer kan du uppnå samma beteende som med login_required genom att använda LoginRequiredMixin. Denna mixin bör vara längst till vänster i arvslistan.
Om en vy använder denna mixin kommer alla förfrågningar från icke-autentiserade användare att omdirigeras till inloggningssidan eller visa ett HTTP 403 Forbidden-fel, beroende på raise_exception-parametern.
Du kan ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare:
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_requiredLink to this heading#När LoginRequiredMiddleware är installerad kräver alla vyer autentisering som standard. Vissa vyer, t.ex. inloggningsvyn, kan behöva inaktivera detta beteende.
Tillåter oautentiserade förfrågningar till denna vy när LoginRequiredMiddleware är installerad.
Om du vill begränsa åtkomsten baserat på vissa behörigheter eller något annat test gör du i princip samma sak som beskrivs i föregående avsnitt.
\nDu kan köra ditt test på request.user i vyn direkt. Till exempel kontrollerar den här vyn att användaren har en e-postadress i den önskade domänen och om inte, omdirigeras till inloggningssidan:
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 # ...\nSom en genväg kan du använda den praktiska dekoratorn user_passes_test som utför en omdirigering när den anropsbara returnerar 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): ...\nuser_passes_test() tar ett obligatoriskt argument: en anropbar som tar ett User-objekt och returnerar True om användaren får visa sidan. Observera att user_passes_test() inte automatiskt kontrollerar att User inte är anonym.
user_passes_test() tar två valfria argument:
login_urlLåter dig ange den URL som användare som inte klarar testet kommer att omdirigeras till. Det kan vara en inloggningssida och standardvärdet är settings.LOGIN_URL om du inte anger någon.
omdirigering_fältnamnSamma som för login_required(). Om du ställer in den på None tas den bort från webbadressen, vilket du kanske vill göra om du omdirigerar användare som inte klarar testet till en icke-inloggningssida där det inte finns någon ”nästa sida”.
Till exempel:
\n@user_passes_test(email_check, login_url="/login/")\ndef my_view(request): ...\nNär du använder klassbaserade vyer kan du använda UserPassesTestMixin för att göra detta.
Du måste åsidosätta metoden test_func() i klassen för att tillhandahålla det test som utförs. Dessutom kan du ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare:
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")\nDu kan också åsidosätta metoden get_test_func() för att mixin ska använda en funktion med ett annat namn för sina kontroller (i stället för test_func()).
permission_required (tillstånd krävs)Link to this heading#Det är en relativt vanlig uppgift att kontrollera om en användare har en viss behörighet. Av den anledningen tillhandahåller Django en genväg för det fallet: permission_required() decorator:
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice")\ndef my_view(request): ...\nPrecis som metoden has_perm(), har namn på behörigheter formen "<app label>.<permission codename>" (t.ex. polls.add_choice för en behörighet på en modell i applikationen polls).
Dekoratorn kan också ta en iterabel av behörigheter, i vilket fall användaren måste ha alla behörigheter för att få tillgång till vyn.
\nObservera att permission_required() också tar en valfri login_url parameter:
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice", login_url="/loginpage/")\ndef my_view(request): ...\nPrecis som i login_required()-dekoratorn är login_url standardvärdet för settings.LOGIN_URL.
Om parametern raise_exception anges, kommer dekoratorn att höja PermissionDenied och uppmana :ref:` 403 (HTTP Forbidden)-vyn<http_forbidden_view>` istället för att omdirigera till inloggningssidan.
Om du vill använda raise_exception men också ge dina användare en chans att logga in först, kan du lägga till login_required() decorator:
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): ...\nDetta undviker också en omdirigeringsslinga när LoginView’s redirect_authenticated_user=True och den inloggade användaren inte har alla nödvändiga behörigheter.
PermissionRequiredMixin mixinLink to this heading#För att tillämpa behörighetskontroller på klassbaserade vyer kan du använda PermissionRequiredMixin:
Denna mixin, precis som dekoratorn permission_required, kontrollerar om användaren som öppnar en vy har alla givna behörigheter. Du bör ange behörigheten (eller en iterabel av behörigheter) med hjälp av parametern 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"]\nDu kan ställa in någon av parametrarna i AccessMixin för att anpassa hanteringen av obehöriga användare.
Du kan också åsidosätta dessa metoder:
\nReturnerar en iterabel med namn på behörigheter som används av mixinen. Standard är attributet permission_required, konverterat till en tupel om det behövs.
Returnerar en boolean som anger om den aktuella användaren har behörighet att köra den dekorerade vyn. Som standard returnerar detta resultatet av att anropa has_perms() med listan över behörigheter som returneras av get_permission_required().
Django tillhandahåller flera vyer som du kan använda för att hantera inloggning, utloggning och lösenordshantering. Dessa använder stock auth forms men du kan också skicka in dina egna formulär.
\nDjango tillhandahåller ingen standardmall för autentiseringsvyerna. Du bör skapa dina egna mallar för de vyer du vill använda. Mallkontexten är dokumenterad i varje vy, se Alla autentiseringsvyer.
\nDet finns olika metoder för att implementera dessa vyer i ditt projekt. Det enklaste sättet är att inkludera den tillhandahållna URLconf i django.contrib.auth.urls i din egen URLconf, till exempel:
urlpatterns = [\n path("accounts/", include("django.contrib.auth.urls")),\n]\nDetta kommer att omfatta följande URL-mönster:
\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']\nVyerna ger ett URL-namn för enklare referens. Se URL-dokumentationen för information om hur du använder namngivna URL-mönster.
\nOm du vill ha mer kontroll över dina webbadresser kan du referera till en specifik vy i din URLconf:
\nfrom django.contrib.auth import views as auth_views\n\nurlpatterns = [\n path("change-password/", auth_views.PasswordChangeView.as_view()),\n]\nVyerna har valfria argument som du kan använda för att ändra vyns beteende. Om du t.ex. vill ändra mallnamnet som en vy använder kan du ange argumentet template_name. Ett sätt att göra detta är att ange nyckelordsargument i URLconf, dessa kommer att vidarebefordras till vyn. Till exempel:
urlpatterns = [\n path(\n "change-password/",\n auth_views.PasswordChangeView.as_view(template_name="change-password.html"),\n ),\n]\nAlla vyer är klassbaserade, vilket gör att du enkelt kan anpassa dem genom subklassning.
\nDetta är en lista med alla vyer som django.contrib.auth tillhandahåller. För implementationsdetaljer se Använda vyerna.
Namn på webbadress: login
Se URL-dokumentationen för mer information om hur du använder namngivna URL-mönster.
\nMetoder och egenskaper
\nNamnet på en mall som ska visas för den vy som används för att logga in användaren. Standardvärdet är registration/login.html.
Den URL som ska omdirigeras till efter inloggning. Standardvärde är LOGIN_REDIRECT_URL.
Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter inloggning. Standard är next. Åsidosätter get_default_redirect_url() URL om den angivna GET parametern skickas.
En anropsbar (vanligtvis en formulärklass) som ska användas för autentisering. Standardinställning är AuthenticationForm.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nEtt boolean som styr om autentiserade användare som öppnar inloggningssidan ska omdirigeras som om de precis hade loggat in. Standardvärdet är False.
En uppsättning av värdar, utöver request.get_host(), som är säkra för omdirigering efter inloggning. Standardvärdet är en tom set.
Returnerar den URL som ska omdirigeras till efter inloggning. Standardimplementeringen löser och returnerar next_page om den är inställd, eller LOGIN_REDIRECT_URL annars.
Här är vad LoginView gör:
Om den anropas via GET visar den ett inloggningsformulär som POSTAS till samma URL. Mer om detta om en liten stund.
Om den anropas via POST med inloggningsuppgifter från användaren försöker den logga in användaren. Om inloggningen lyckas omdirigeras vyn till den URL som anges i next. Om next inte anges, omdirigeras den till settings.LOGIN_REDIRECT_URL (som standard till /accounts/profile/). Om inloggningen inte lyckas visas inloggningsformuläret på nytt.
Det är ditt ansvar att tillhandahålla html för inloggningsmallen, som heter registration/login.html som standard. Den här mallen får fyra mallkontextvariabler:
form: Ett Form-objekt som representerar AuthenticationForm.
nästa: Den URL som ska omdirigeras till efter en lyckad inloggning. Den kan också innehålla en frågesträng.
site: Den aktuella Site, enligt inställningen SITE_ID. Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av RequestSite, som härleder webbplatsnamnet och domänen från den aktuella HttpRequest.
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.
Om du föredrar att inte anropa mallen registration/login.html kan du skicka parametern template_name via de extra argumenten till metoden as_view i din URLconf. Till exempel skulle denna URLconf-rad använda myapp/login.html istället:
path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),\nDu kan också ange namnet på fältet GET som innehåller den URL som ska omdirigeras till efter inloggning med hjälp av redirect_field_name. Som standard kallas fältet next.
Här är ett exempel på en mall för registration/login.html som du kan använda som utgångspunkt. Det förutsätter att du har en base.html-mall som definierar ett 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 set up the password_reset view in your URLconf #}\n<p><a href="{% url 'password_reset' %}">Lost password?</a></p>\n\n{% endblock %}\nOm du har anpassat autentiseringen (se Customizing Authentication) kan du använda ett anpassat autentiseringsformulär genom att ange attributet authentication_form. Detta formulär måste acceptera ett argument med nyckelordet request i sin metod __init__() och tillhandahålla en metod get_user() som returnerar det autentiserade användarobjektet (denna metod anropas endast efter en lyckad formulärvalidering).
Loggar ut en användare på POST-förfrågningar.
Namn på webbadress: logout
Attribut:
\nDen URL som ska omdirigeras till efter utloggning. Standardvärde är LOGOUT_REDIRECT_URL.
Det fullständiga namnet på en mall som ska visas efter att användaren har loggat ut. Standardvärdet är registration/logged_out.html.
Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter utloggning. Standard är 'next'. Åsidosätter next_page URL om den angivna GET parametern skickas.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nEn uppsättning av värdar, utöver request.get_host(), som är säkra för omdirigering efter utloggning. Standardvärdet är en tom set.
Template context:
\ntitle: Strängen ”Logged out”, lokaliserad.
site: Den aktuella Site, enligt inställningen SITE_ID. Om du inte har installerat webbplatsramverket kommer detta att ställas in till en instans av RequestSite, som härleder webbplatsnamnet och domänen från den aktuella HttpRequest.
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.
Loggar ut en användare på POST-förfrågningar och omdirigerar sedan till inloggningssidan.
URL-namn: Ingen standard-URL angiven
\n**Valfria argument: **
\nlogin_url: URL-adressen till inloggningssidan som du ska omdirigeras till. Standardvärdet är settings.LOGIN_URL om det inte anges.
Namn på webbadress: password_change
Tillåter en användare att ändra sitt lösenord.
\nAttribut:
\nDet fullständiga namnet på en mall som ska användas för att visa formuläret för lösenordsändring. Standardvärdet är registration/password_change_form.html om det inte anges.
Den URL som ska omdirigeras till efter en lyckad lösenordsändring. Standard är 'password_change_done.
Ett anpassat formulär för ”byte av lösenord” som måste acceptera ett argument i form av nyckelordet user. Formuläret är ansvarigt för att faktiskt ändra användarens lösenord. Standardinställning är PasswordChangeForm.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nTemplate context:
\nformulär: Formuläret för lösenordsändring (se form_class ovan).
Namn på webbadress: password_change_done
Den sida som visas efter att en användare har bytt lösenord.
\nAttribut:
\nDet fullständiga namnet på en mall som ska användas. Standardvärdet är registration/password_change_done.html om det inte anges.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nNamn på webbadress: password_reset
Gör det möjligt för en användare att återställa sitt lösenord genom att generera en engångslänk som kan användas för att återställa lösenordet och skicka länken till användarens registrerade e-postadress.
\nDen här vyn skickar ett e-postmeddelande om följande villkor är uppfyllda:
\nDen angivna e-postadressen finns i systemet.
Den begärda användaren är aktiv (User.is_active är True).
Den begärda användaren har ett användbart lösenord. Användare som flaggas med ett oanvändbart lösenord (se set_unusable_password()) får inte begära en återställning av lösenordet för att förhindra missbruk vid användning av en extern autentiseringskälla som LDAP.
Om något av dessa villkor inte är uppfyllt skickas inget e-postmeddelande, men användaren får inte heller något felmeddelande. Detta förhindrar att information läcker ut till potentiella angripare. Om du vill tillhandahålla ett felmeddelande i det här fallet kan du underordna dig PasswordResetForm och använda attributet form_class.
Attribut:
\nDet fullständiga namnet på en mall som ska användas för att visa formuläret för återställning av lösenord. Standardvärdet är registration/password_reset_form.html om det inte anges.
Formulär som kommer att användas för att få e-postadressen till den användare som lösenordet ska återställas för. Standardinställning är PasswordResetForm.
Det fullständiga namnet på en mall som ska användas för att generera e-postmeddelandet med länken för återställning av lösenord. Standardvärdet är registration/password_reset_email.html om det inte anges.
Det fullständiga namnet på en mall som ska användas för ämnet i e-postmeddelandet med länken för återställning av lösenord. Standardvärdet är registration/password_reset_subject.txt om det inte anges.
Instans av klassen för att kontrollera engångslänken. Detta kommer som standard att vara default_token_generator, det är en instans av django.contrib.auth.tokens.PasswordResetTokenGenerator.
Den URL som ska omdirigeras till efter en lyckad begäran om återställning av lösenord. Standardvärdet är ``’password_reset_done’’.
\nEn giltig e-postadress. Som standard använder Django DEFAULT_FROM_EMAIL.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nDet fullständiga namnet på en mall som ska användas för att generera ett text/html flerdelat e-postmeddelande med länken för återställning av lösenord. Som standard skickas inte HTML-e-post.
\nEn ordbok med kontextdata som kommer att finnas tillgänglig i e-postmallen. Den kan användas för att åsidosätta standardvärden för mallkontext som anges nedan, t.ex. domain.
Template context:
\nformulär: Formuläret (se form_class ovan) för återställning av användarens lösenord.
**E-postmallens sammanhang: **
\nemail: Ett alias för user.email
user: Den aktuella User, enligt formulärfältet email. Endast aktiva användare kan återställa sina lösenord (User.is_active is True).
site_name: Ett alias för site.name. Om du inte har installerat site-ramverket kommer detta att ställas in till värdet av request.META['SERVER_NAME']. För mer information om webbplatser, se Ramverket för ”webbplatser”.
domän: Ett alias för site.domain. Om du inte har installerat site-ramverket kommer detta att sättas till värdet av request.get_host().
protokoll: http eller https
uid: Användarens primärnyckel kodad i bas 64.
token: Token för att kontrollera att återställningslänken är giltig.
Exempel på registration/password_reset_email.html (mall för e-postens brödtext):
Someone asked for password reset for email {{ email }}. Follow the link below:\n{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}\nSamma mallkontext används för ämnesmallen. Ämnet måste vara en vanlig textsträng på en rad.
\nNamn på webbadress: password_reset_done
Den sida som visas efter att en användare har fått en länk för att återställa sitt lösenord via e-post. Denna vy anropas som standard om PasswordResetView inte har en explicit uccess_url URL inställd.
Attribut:
\nDet fullständiga namnet på en mall som ska användas. Standardvärdet är registration/password_reset_done.html om det inte anges.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nNamn på webbadress: password_reset_confirm
Visar ett formulär för att ange ett nytt lösenord.
\n**Nyckelordsargument från webbadressen: **
\nuidb64: Användarens id kodat i bas 64.
token: Token för att kontrollera att lösenordet är giltigt.
Attribut:
\nDet fullständiga namnet på en mall som ska visa vyn för bekräftelse av lösenord. Standardvärdet är registration/password_reset_confirm.html.
Instans av klassen för att kontrollera lösenordet. Detta kommer som standard att vara default_token_generator, det är en instans av django.contrib.auth.tokens.PasswordResetTokenGenerator.
En boolean som anger om användaren ska autentiseras automatiskt efter en lyckad återställning av lösenordet. Standardvärdet är False.
En prickad sökväg till den autentiseringsbackend som ska användas när en användare autentiseras om post_reset_login är True. Krävs endast om du har flera AUTHENTICATION_BACKENDS konfigurerade. Standardvärdet är None.
Formulär som kommer att användas för att ställa in lösenordet. Standard är SetPasswordForm.
URL att omdirigera efter att lösenordsåterställningen är klar. Standardvärdet är 'password_reset_complete'.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nTokenparameter som visas som en komponent i URL:er för återställning av lösenord. Standardvärdet är ”set-password”.
\nTemplate context:
\nformulär: Formuläret (se form_class ovan) för att ange den nya användarens lösenord.
validlink: Boolean, True om länken (kombination av uidb64 och token) är giltig eller oanvänd ännu.
Namn på webbadress: password_reset_complete
Visar en vy som informerar användaren om att lösenordet har ändrats.
\nAttribut:
\nDet fullständiga namnet på en mall för att visa vyn. Standardvärdet är registration/password_reset_complete.html.
En ordbok med kontextdata som läggs till i de standardkontextdata som skickas till mallen.
\nOmdirigerar till inloggningssidan och sedan tillbaka till en annan URL efter en lyckad inloggning.
\n**Nödvändiga argument: **
\nnästa: Den URL som ska omdirigeras till efter en lyckad inloggning.
**Valfria argument: **
\nlogin_url: URL-adressen till inloggningssidan som du ska omdirigeras till. Standardvärdet är settings.LOGIN_URL om det inte anges.
namn på fältet redirect_field_name: Namnet på ett GET-fält som innehåller den URL som ska omdirigeras till efter inloggning. Åsidosätter next om den angivna GET-parametern skickas.
Om du inte vill använda de inbyggda vyerna, men vill ha bekvämligheten med att inte behöva skriva formulär för den här funktionaliteten, tillhandahåller autentiseringssystemet flera inbyggda formulär som finns i django.contrib.auth.forms:
Ett formulär som används i admin-gränssnittet för att ändra en användares lösenord, inklusive möjligheten att ange ett unusable password, som blockerar användaren från att logga in med lösenordsbaserad autentisering.
Tar användaren som det första positionella argumentet.
Ett formulär som används i admin-gränssnittet för att skapa en ny användare. Ärver från UserCreationForm.
Den innehåller ett extra fält usable_password som är aktiverat som standard. Om usable_password är aktiverat verifierar den att password1 och password2 inte är tomma och matchar, validerar lösenordet med validate_password(), och ställer in användarens lösenord med set_password(). Om usable_password är inaktiverat görs ingen lösenordsvalidering och lösenordsbaserad autentisering inaktiveras för användaren genom att anropa set_unusable_password().
Ett formulär för att logga in en användare.
\nTar request som sitt första positionella argument, som lagras i formulärinstansen för att användas av underklasser.
Som standard avvisar AuthenticationForm användare vars flagga is_active är inställd på False. Du kan åsidosätta detta beteende med en anpassad policy för att avgöra vilka användare som kan logga in. Gör detta med ett anpassat formulär som underklassar AuthenticationForm och åsidosätter metoden confirm_login_allowed(). Denna metod bör ge upphov till ett ValidationError om den angivna användaren inte kan logga in.
Till exempel, för att tillåta alla användare att logga in oavsett ”aktiv” status:
\nfrom django.contrib.auth.forms import AuthenticationForm\n\n\nclass AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):\n def confirm_login_allowed(self, user):\n pass\n(I det här fallet måste du också använda en autentiseringsbackend som tillåter inaktiva användare, till exempel AllowAllUsersModelBackend)
Eller för att bara tillåta vissa aktiva användare att logga in:
\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 )\nEn ModelForm för att skapa en ny användare. Detta är den rekommenderade basklassen om du behöver anpassa formuläret för att skapa en användare.
Den har tre fält: username (från användarmodellen), password1 och password2. Den kontrollerar att password1 och password2 matchar, validerar lösenordet med validate_password(), och ställer in användarens lösenord med set_password().
Ett formulär för att tillåta en användare att ändra sitt lösenord.
\nEtt formulär för att generera och e-posta en engångslänk för att återställa en användares lösenord.
\nAnvänder argumenten för att skicka ett EmailMultiAlternatives. Kan åsidosättas för att anpassa hur e-postmeddelandet skickas till användaren. Om du väljer att åsidosätta den här metoden bör du tänka på att hantera eventuella undantag som uppstår om e-postmeddelandet inte skickas.
subject_template_name – mallen för ämnet.
email_template_name – mallen för e-postmeddelandets brödtext.
context – kontext som skickas till subject_template, email_template och html_email_template (om det inte är None).
from_email – avsändarens e-postadress.
to_email – e-postadressen till den som begär utdraget.
html_email_template_name – mallen för HTML-texten; standardvärdet är None, i vilket fall ett e-postmeddelande med ren text skickas.
Som standard fyller save() i context med samma variabler som PasswordResetView skickar till sin e-postkontext.
Ett formulär som låter en användare ändra sitt lösenord utan att ange det gamla lösenordet.
\nEtt formulär som används i administratörsgränssnittet för att ändra en användares information och behörigheter.
\nÄrver från BaseUserCreationForm. För att förhindra förväxling med liknande användarnamn tillåter formuläret inte användarnamn som skiljer sig åt endast i bokstäver.
Den för närvarande inloggade användaren och deras behörigheter görs tillgängliga i template context när du använder RequestContext.
Vid rendering av en mall RequestContext lagras den för närvarande inloggade användaren, antingen en User-instans eller en AnonymousUser-instans, i mallvariabeln {{ 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 %}\nDenna mallkontextvariabel är inte tillgänglig om en RequestContext inte används.
Den inloggade användarens behörigheter lagras i mallvariabeln {{ perms }}. Detta är en instans av django.contrib.auth.context_processors.PermWrapper, som är en mallvänlig proxy av behörigheter.
Att utvärdera en enattributsuppslagning av {{perms }} som en boolean är en proxy till User.has_module_perms(). Till exempel, för att kontrollera om den inloggade användaren har några behörigheter i appen foo:
{% if perms.foo %}\nAtt utvärdera en två-nivå-attributuppslagning som en boolean är en proxy till User.has_perm(). Till exempel för att kontrollera om den inloggade användaren har behörigheten foo.add_vote:
{% if perms.foo.add_vote %}\nHär är ett mer komplett exempel på kontroll av behörigheter i en mall:
\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 %}\nDet är också möjligt att slå upp behörigheter med {% if i %}-satser. Till exempel:
{% if 'foo' in perms %}\n {% if 'foo.add_vote' in perms %}\n <p>In lookup works, too.</p>\n {% endif %}\n{% endif %}\nNär du har både django.contrib.admin och django.contrib.auth installerade, ger admin ett bekvämt sätt att visa och hantera användare, grupper och behörigheter. Användare kan skapas och tas bort som vilken Django-modell som helst. Grupper kan skapas och behörigheter kan tilldelas användare eller grupper. En logg över användares redigeringar av modeller som görs i admin lagras och visas också.
Du bör se en länk till ”Användare” i avsnittet ”Auth” på huvudadministratörens indexsida. Administrationssidan ”Lägg till användare” skiljer sig från vanliga administrationssidor genom att du måste välja ett användarnamn och lösenord innan du kan redigera resten av användarens fält. Alternativt kan du på den här sidan välja ett användarnamn och inaktivera lösenordsbaserad autentisering för användaren.
\nObservera också: om du vill att ett användarkonto ska kunna skapa användare med hjälp av Django-adminsidan måste du ge dem behörighet att lägga till användare och ändra användare (dvs. behörigheterna ”Lägg till användare” och ”Ändra användare”). Om ett konto har behörighet att lägga till användare men inte att ändra dem, kommer det kontot inte att kunna lägga till användare. Varför inte? För att om du har behörighet att lägga till användare har du möjlighet att skapa superanvändare, som sedan i sin tur kan ändra andra användare. Så Django kräver lägg till och ändringsbehörigheter som en liten säkerhetsåtgärd.
\nTänk noga igenom hur du låter användare hantera behörigheter. Om du ger en icke-superanvändare möjlighet att redigera användare är det i slutändan samma sak som att ge dem superanvändarstatus eftersom de kommer att kunna höja behörigheterna för användare inklusive sig själva!
\nAnvändarlösenord visas inte i administratören (och lagras inte heller i databasen), men Lagringsdetaljer för lösenord visas. När denna information visas finns en länk till ett formulär för lösenordsändring som gör det möjligt för administratörer att ändra eller ta bort användarlösenord.
\n