Den autentisering som följer med Django är tillräckligt bra för de flesta vanliga fall, men du kan ha behov som inte uppfylls av standardinställningarna. Att anpassa autentiseringen i dina projekt kräver förståelse för vilka punkter i det tillhandahållna systemet som är utbyggbara eller utbytbara. Detta dokument ger detaljer om hur autentiseringssystemet kan anpassas.
\nAuthentication backends tillhandahåller ett utbyggbart system för när ett användarnamn och lösenord som lagras med användarmodellen behöver autentiseras mot en annan tjänst än Djangos standard.
\nDu kan ge dina modeller custom permissions som kan kontrolleras genom Djangos auktoriseringssystem.
\nDu kan utöka standardmodellen User, eller ersätta en helt anpassad modell.
Det kan finnas tillfällen då du behöver ansluta till en annan autentiseringskälla - det vill säga en annan källa med användarnamn och lösenord eller autentiseringsmetoder.
\nDitt företag kanske redan har en LDAP-installation som lagrar ett användarnamn och lösenord för varje anställd. Det skulle vara krångligt för både nätverksadministratören och användarna själva om användarna hade separata konton i LDAP och de Django-baserade applikationerna.
\nFör att hantera situationer som denna låter Djangos autentiseringssystem dig koppla in andra autentiseringskällor. Du kan åsidosätta Djangos standarddatabasbaserade system, eller så kan du använda standardsystemet i kombination med andra system.
\nSe authentication backend reference för information om de autentiseringsbackends som ingår i Django.
\nBehind the scenes, Django maintains a list of ”authentication backends” that it\nchecks for authentication. When somebody calls\ndjango.contrib.auth.authenticate() – as described in How to log\na user in – Django tries authenticating across\nall of its authentication backends. If the first authentication method fails,\nDjango tries the second one, and so on, until all backends have been attempted.
Listan över autentiseringsbackends som ska användas anges i inställningen AUTHENTICATION_BACKENDS. Detta bör vara en lista med Python-sökvägsnamn som pekar på Python-klasser som vet hur man autentiserar. Dessa klasser kan finnas var som helst på din Python-sökväg.
Som standard är AUTHENTICATION_BACKENDS inställd på:
["django.contrib.auth.backends.ModelBackend"]\nDet är den grundläggande autentiseringsbackend som kontrollerar Djangos användardatabas och frågar efter de inbyggda behörigheterna. Det ger inte skydd mot brute force-attacker via någon hastighetsbegränsningsmekanism. Du kan antingen implementera din egen hastighetsbegränsningsmekanism i en anpassad autentiseringsbackend eller använda de mekanismer som tillhandahålls av de flesta webbservrar.
\nOrdningen på AUTHENTICATION_BACKENDS spelar roll, så om samma användarnamn och lösenord är giltigt i flera backends kommer Django att stoppa bearbetningen vid den första positiva matchningen.
Om en backend ger upphov till ett PermissionDenied undantag, kommer autentiseringen omedelbart att misslyckas. Django kommer inte att kontrollera de backends som följer.
En autentiseringsbackend är en klass som implementerar två obligatoriska metoder: get_user(user_id) och authenticate(request, **credentials), samt en uppsättning valfria behörighetsrelaterade auktoriseringsmetoder.
Metoden get_user tar ett user_id - som kan vara ett användarnamn, databas-ID eller vad som helst, men som måste vara primärnyckeln i ditt användarobjekt - och returnerar ett användarobjekt eller None.
Metoden authenticate tar ett request-argument och referenser som nyckelordsargument. För det mesta kommer det att se ut så här:
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nMen det kan också autentisera en token, så här:
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nI vilket fall som helst bör authenticate() kontrollera de autentiseringsuppgifter den får och returnera ett användarobjekt som matchar dessa autentiseringsuppgifter om autentiseringsuppgifterna är giltiga. Om de inte är giltiga bör den returnera None.
request är en HttpRequest och kan vara None om den inte tillhandahölls till authenticate() (som skickar den vidare till backend).
Djangos admin är tätt kopplad till Djangos User-objekt. För att en användare ska få åtkomst till admin måste till exempel User.is_staff och User.is_active vara True (se AdminSite.has_permission() för detaljer).
Det bästa sättet att hantera detta är att skapa ett Django User-objekt för varje användare som finns för din backend (t.ex. i din LDAP-katalog, din externa SQL-databas etc.) Du kan antingen skriva ett skript för att göra detta i förväg, eller så kan din authenticate-metod göra det första gången en användare loggar in.
Här är ett exempel på en backend som autentiserar mot en användarnamn- och lösenordsvariabel som definieras i din settings.py-fil och skapar ett Django User-objekt första gången en användare autentiserar. I det här exemplet är det skapade Django User-objektet en superanvändare som kommer att ha full tillgång till admin:
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = settings.ADMIN_LOGIN == username\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username) # is_active defaults to True.\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\nFör att skapa anpassade behörigheter för ett visst modellobjekt använder du permissions model Meta attribute.
Detta exempel på en Task-modell skapar två anpassade behörigheter, dvs. åtgärder som användare kan eller inte kan göra med Task-instanser, som är specifika för din applikation:
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n ]\nDet enda detta gör är att skapa dessa extra behörigheter när du kör manage.py migrate (funktionen som skapar behörigheter är kopplad till post_migrate-signalen). Din kod ansvarar för att kontrollera värdet på dessa behörigheter när en användare försöker komma åt den funktionalitet som tillhandahålls av applikationen (ändra status för uppgifter eller stänga uppgifter.) Om vi fortsätter med exemplet ovan kontrollerar följande om en användare kan stänga uppgifter:
user.has_perm("app.close_task")\nUser-modellenLink to this heading#Det finns två sätt att utöka standardmodellen User utan att ersätta den med en egen modell. Om de ändringar du behöver är rent beteendemässiga och inte kräver någon ändring av vad som lagras i databasen kan du skapa en proxymodell baserad på User. Detta möjliggör alla de funktioner som erbjuds av proxymodeller, inklusive standardbeställning, anpassade chefer eller anpassade modellmetoder.
Om du vill lagra information som är relaterad till User kan du använda en OneToOneField till en modell som innehåller fälten för ytterligare information. Denna en-till-en-modell kallas ofta en profilmodell, eftersom den kan lagra icke-auth-relaterad information om en webbplatsanvändare. Du kan till exempel skapa en Employee-modell:
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nOm vi utgår från en befintlig anställd Fred Smith som har både en användar- och en anställdmodell kan du komma åt den relaterade informationen med hjälp av Djangos standardkonventioner för relaterade modeller:
\n>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\nFör att lägga till en profilmodells fält på användarsidan i admin, definiera en InlineModelAdmin (för detta exempel använder vi en StackedInline) i din apps admin.py` och lägg till den i en ``UserAdmin-klass som är registrerad med User-klassen:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = "employee"\n\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nDessa profilmodeller är inte speciella på något sätt - de är bara Django-modeller som råkar ha en en-till-en-länk med en användarmodell. Som sådana skapas de inte automatiskt när en användare skapas, men en django.db.models.signals.post_save kan användas för att skapa eller uppdatera relaterade modeller på lämpligt sätt.
Att använda relaterade modeller resulterar i ytterligare frågor eller joins för att hämta de relaterade uppgifterna. Beroende på dina behov kan en anpassad användarmodell som innehåller de relaterade fälten vara ett bättre alternativ, men befintliga relationer till standardanvändarmodellen i projektets appar kan motivera den extra databasbelastningen.
\nUser-modellLink to this heading#Vissa typer av projekt kan ha autentiseringskrav för vilka Djangos inbyggda User-modell inte alltid är lämplig. På vissa webbplatser är det till exempel mer meningsfullt att använda en e-postadress som din identifieringstoken istället för ett användarnamn.
Django låter dig åsidosätta standardanvändarmodellen genom att tillhandahålla ett värde för inställningen AUTH_USER_MODEL som refererar till en anpassad modell:
AUTH_USER_MODEL = "myapp.MyUser"\nDetta prickade par beskriver label för Django-appen (som måste finnas i din INSTALLED_APPS) och namnet på den Django-modell som du vill använda som din användarmodell.
Om du startar ett nytt projekt kan du ställa in en anpassad användarmodell som beter sig identiskt med standardanvändarmodellen genom att underklassa AbstractUser:
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\nGlöm inte att peka AUTH_USER_MODEL till den. Gör detta innan du skapar några migreringar eller kör manage.py migrate för första gången.
Registrera också modellen i appens admin.py:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nDet är möjligt att ändra AUTH_USER_MODEL efter att du har skapat databastabeller, men det kan vara komplicerat eftersom det påverkar t.ex. utländska nycklar och många-till-många-relationer.
Den här ändringen kan inte göras automatiskt och kräver att du manuellt fixar ditt schema, flyttar dina data från den gamla användartabellen och eventuellt manuellt tillämpar vissa migreringar igen. Se #25313 för en översikt över stegen.
\nPå grund av begränsningar i Djangos dynamiska beroendefunktion för utbytbara modeller måste den modell som refereras till av AUTH_USER_MODEL skapas i den första migreringen av dess app (vanligtvis kallad 0001_initial); annars får du beroendeproblem.
Dessutom kan du stöta på ett CircularDependencyError när du kör dina migreringar eftersom Django inte automatiskt kan bryta beroendeslingan på grund av det dynamiska beroendet. Om du ser det här felet bör du bryta slingan genom att flytta de modeller som din användarmodell är beroende av till en andra migrering. (Du kan prova att skapa två normala modeller som har en ForeignKey till varandra och se hur makemigrations löser det cirkulära beroendet om du vill se hur det vanligtvis görs)
AUTH_USER_MODELLink to this heading#Återanvändbara appar bör inte implementera en anpassad användarmodell. Ett projekt kan använda många appar, och två återanvändbara appar som implementerade en anpassad användarmodell kunde inte användas tillsammans. Om du behöver lagra information per användare i din app, använd en ForeignKey eller OneToOneField till settings.AUTH_USER_MODEL enligt beskrivningen nedan.
UserLink to this heading#Om du refererar till User direkt (t.ex. genom att hänvisa till den i en främmande nyckel), kommer din kod inte att fungera i projekt där AUTH_USER_MODEL har ändrats till en annan användarmodell.
Istället för att referera till User direkt, bör du referera till användarmodellen med django.contrib.auth.get_user_model(). Denna metod returnerar den för närvarande aktiva användarmodellen - den anpassade användarmodellen om en sådan anges, eller User annars.
När du definierar en främmande nyckel eller många-till-många-relationer till användarmodellen bör du ange den anpassade modellen med hjälp av inställningen AUTH_USER_MODEL. Till exempel:
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nNär du ansluter till signaler som skickas av användarmodellen bör du ange den anpassade modellen med hjälp av inställningen AUTH_USER_MODEL. Till exempel:
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nGenerellt sett är det enklast att hänvisa till användarmodellen med inställningen AUTH_USER_MODEL i kod som körs vid importtillfället, men det är också möjligt att anropa get_user_model() medan Django importerar modeller, så du kan använda models.ForeignKey(get_user_model(), ...).
Om din app testas med flera användarmodeller, till exempel med hjälp av @override_settings(AUTH_USER_MODEL=...) och du cachar resultatet av get_user_model() i en variabel på modulnivå, kan du behöva lyssna på setting_changed-signalen för att rensa cacheminnet. Till exempel:
from django.apps import apps\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\nNär du börjar ditt projekt med en anpassad användarmodell bör du fundera på om det är rätt val för ditt projekt.
\nOm du samlar all användarrelaterad information i en modell behöver du inte göra fler eller mer komplexa databasfrågor för att hämta relaterade modeller. Å andra sidan kan det vara mer lämpligt att lagra appspecifik användarinformation i en modell som har en relation till din anpassade användarmodell. Det gör att varje app kan specificera sina egna krav på användardata utan att potentiellt motverka eller bryta mot antaganden från andra appar. Det innebär också att du håller din användarmodell så enkel som möjligt, fokuserad på autentisering och följer de minimikrav som Django förväntar sig att anpassade användarmodeller ska uppfylla.
\nOm du använder standardbackend för autentisering måste din modell ha ett enda unikt fält som kan användas för identifiering. Detta kan vara ett användarnamn, en e-postadress eller något annat unikt attribut. Ett icke-unikt användarnamnsfält är tillåtet om du använder en anpassad autentiseringsbackend som kan stödja det.
\nDet enklaste sättet att konstruera en kompatibel anpassad användarmodell är att ärva från AbstractBaseUser. AbstractBaseUser tillhandahåller kärnimplementeringen av en användarmodell, inklusive hashade lösenord och tokeniserade lösenordsåterställningar. Du måste sedan tillhandahålla några viktiga implementeringsdetaljer:
En sträng som beskriver namnet på det fält i användarmodellen som används som unik identifierare. Detta är vanligtvis ett användarnamn av något slag, men det kan också vara en e-postadress eller någon annan unik identifierare. Fältet måste vara unikt (t.ex. ha unique=True inställt i sin definition), såvida du inte använder en anpassad autentiseringsbackend som kan stödja icke-unika användarnamn.
I följande exempel används fältet identifier som identifieringsfält:
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\nEn sträng som beskriver namnet på e-postfältet i modellen User. Detta värde returneras av get_email_field_name().
En lista över de fältnamn som kommer att efterfrågas när en användare skapas via hanteringskommandot createsuperuser. Användaren kommer att uppmanas att ange ett värde för vart och ett av dessa fält. Det måste inkludera alla fält för vilka blank är False eller odefinierat och kan inkludera ytterligare fält som du vill bli ombedd att ange när en användare skapas interaktivt. REQUIRED_FIELDS har ingen effekt i andra delar av Django, som att skapa en användare i admin.
Här är till exempel den partiella definitionen för en användarmodell som definierar två obligatoriska fält - födelsedatum och längd:
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nA boolean attribute that indicates whether the user is considered\n”active”. This attribute is provided as an attribute on\nAbstractBaseUser defaulting to True. How you choose to\nimplement it will depend on the details of your chosen auth backends.\nSee the documentation of the is_active attribute on the built-in\nuser model for details.
Valfritt. En längre formell identifierare för användaren, t.ex. deras fullständiga namn. Om det implementeras visas detta tillsammans med användarnamnet i ett objekts historik i django.contrib.admin.
Valfritt. En kort, informell identifierare för användaren, t.ex. användarens förnamn. Om det implementeras ersätter detta användarnamnet i hälsningen till användaren i rubriken för django.contrib.admin.
Följande attribut och metoder är tillgängliga för alla subklasser av AbstractBaseUser:
Returnerar värdet på det fält som anges av USERNAME_FIELD.
Normaliserar användarnamnet genom att anropa normalize_username(). Om du åsidosätter den här metoden, se till att anropa super() för att behålla normaliseringen.
Returnerar namnet på det e-postfält som anges av attributet EMAIL_FIELD. Standardvärdet är 'email' om EMAIL_FIELD inte har angetts.
Tillämpar NFKC Unicode-normalisering på användarnamn så att visuellt identiska tecken med olika Unicode-kodpunkter betraktas som identiska.
\nSkrivskyddat attribut som alltid är True (i motsats till AnonymousUser.is_authenticated som alltid är False). Det här är ett sätt att se om användaren har autentiserats. Det innebär inte några behörigheter och kontrollerar inte om användaren är aktiv eller har en giltig session. Även om du normalt kommer att kontrollera detta attribut på request.user för att ta reda på om det har fyllts i av AuthenticationMiddleware (som representerar den för närvarande inloggade användaren), bör du veta att detta attribut är True för alla User-instanser.
Skrivskyddat attribut som alltid är False. Detta är ett sätt att skilja mellan objekten User och AnonymousUser. Generellt sett bör du föredra att använda is_authenticated framför detta attribut.
Ställer in användarens lösenord till den angivna råsträngen och tar hand om lösenordshashningen. Sparar inte AbstractBaseUser-objektet.
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
Asynkron version: acheck_password()
Returnerar True om den angivna råsträngen är rätt lösenord för användaren. (Detta tar hand om lösenordets hashing vid jämförelsen.)
Marks the user as having no password set. This isn’t the same as\nhaving a blank string for a password.\ncheck_password() for\nthis user will never return True. Doesn’t save the\nAbstractBaseUser object.
Du kan behöva detta om autentiseringen för din applikation sker mot en befintlig extern källa, t.ex. en LDAP-katalog.
\nReturns False if\nset_unusable_password()\nhas been called for this user.
Returnerar en HMAC för lösenordsfältet. Används för Inaktivering av session vid byte av lösenord.
\nGer HMAC för lösenordsfältet med hjälp av SECRET_KEY_FALLBACKS. Används av get_user().
AbstractUser subclasses AbstractBaseUser:
Normaliserar e-postmeddelandet genom att anropa BaseUserManager.normalize_email(). Om du åsidosätter den här metoden, se till att anropa super() för att behålla normaliseringen.
Du bör också definiera en anpassad manager för din användarmodell. Om din användarmodell definierar fälten username, email, is_staff, is_active, is_superuser, last_login och date_joined på samma sätt som Djangos standardanvändare, kan du installera Djangos UserManager; men om din användarmodell definierar olika fält måste du definiera en anpassad manager som utökar BaseUserManager med ytterligare två metoder:
Prototypen för create_user() bör acceptera användarnamnsfältet plus alla obligatoriska fält som argument. Om din användarmodell till exempel använder email som användarnamnsfält och har date_of_birth som ett obligatoriskt fält, bör create_user definieras som:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nPrototypen för create_superuser() bör acceptera användarnamnsfältet plus alla obligatoriska fält som argument. Om din användarmodell till exempel använder email som användarnamnsfält och har date_of_birth som ett obligatoriskt fält, bör create_superuser definieras som:
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\nFör en ForeignKey i USERNAME_FIELD eller REQUIRED_FIELDS får dessa metoder värdet av to_field (standard primary_key) i en befintlig instans.
BaseUserManager tillhandahåller följande verktygsmetoder:
Normaliserar e-postadresser genom att skriva domändelen av e-postadressen med liten bokstav.
\nAsynkron version: aget_by_natural_key()
Hämtar en användarinstans med hjälp av innehållet i det fält som anges av USERNAME_FIELD.
UserLink to this heading#Om du är helt nöjd med Djangos User-modell, men du vill lägga till ytterligare profilinformation, kan du underordna django.contrib.auth.models.AbstractUser och lägga till dina egna profilfält, även om vi rekommenderar en separat modell som beskrivs i Ange en anpassad användarmodell. AbstractUser ger den fullständiga implementeringen av standard User som en abstrakt modell.
Djangos inbyggda forms och views gör vissa antaganden om den användarmodell som de arbetar med.
\nFöljande formulär är kompatibla med alla underklasser av AbstractBaseUser:
AuthenticationForm: Använder användarnamnsfältet som anges av USERNAME_FIELD.
Följande formulär innehåller antaganden om användarmodellen och kan användas som de är om dessa antaganden uppfylls:
\nPasswordResetForm: Antar att användarmodellen har ett fält som lagrar användarens e-postadress med det namn som returneras av get_email_field_name() (email som standard) som kan användas för att identifiera användaren och ett booleskt fält med namnet is_active för att förhindra återställning av lösenord för inaktiva användare.
Slutligen är följande formulär knutna till User och måste skrivas om eller utökas för att fungera med en anpassad användarmodell:
Om din anpassade användarmodell är en underklass till AbstractUser kan du utöka dessa formulär på följande sätt:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLink to this heading#Om du vill att din anpassade användarmodell även ska fungera med administratören måste din användarmodell definiera ytterligare några attribut och metoder. Dessa metoder gör det möjligt för administratören att kontrollera användarens åtkomst till administratörsinnehåll:
\nReturnerar True om användaren har rätt att få åtkomst till administratörssidan.
Returnerar True om användarkontot för närvarande är aktivt.
Returnerar True om användaren har den angivna behörigheten. Om obj anges måste behörigheten kontrolleras mot en specifik objektinstans.
Returnerar True om användaren har behörighet att komma åt modeller i den angivna appen.
Du måste också registrera din anpassade användarmodell hos administratören. Om din anpassade användarmodell utökar django.contrib.auth.models.AbstractUser kan du använda Djangos befintliga django.contrib.auth.admin.UserAdmin-klass. Men om din användarmodell utökar AbstractBaseUser`, måste du definiera en anpassad ModelAdmin klass. Det kan vara möjligt att underordna standardklassen django.contrib.auth.admin.UserAdmin; du måste dock åsidosätta alla definitioner som hänvisar till fält på django.contrib.auth.models.AbstractUser som inte finns i din anpassade användarklass.
För att göra det enkelt att inkludera Djangos behörighetsramverk i din egen användarklass tillhandahåller Django PermissionsMixin. Detta är en abstrakt modell som du kan inkludera i klasshierarkin för din användarmodell, vilket ger dig alla metoder och databasfält som krävs för att stödja Djangos behörighetsmodell.
PermissionsMixin tillhandahåller följande metoder och attribut:
Boolesk. Anger att den här användaren har alla behörigheter utan att uttryckligen ha tilldelats dem.
\nReturnerar en uppsättning behörighetssträngar som användaren har direkt.
\nOm obj anges returneras endast användarrättigheterna för detta specifika objekt.
Returnerar en uppsättning behörighetssträngar som användaren har via sina grupper.
\nOm obj anges returneras endast gruppbehörigheterna för detta specifika objekt.
Returnerar en uppsättning behörighetssträngar som användaren har, både genom grupp- och användarbehörigheter.
\nOm obj anges returneras endast behörigheterna för detta specifika objekt.
Returnerar True om användaren har den angivna behörigheten, där perm är i formatet "<app label>.<permission codename>" (se permissions <topic-authorization>`). Om User.is_active och is_superuser båda är True returnerar denna metod alltid True.
Om obj skickas in kommer denna metod inte att söka efter en behörighet för modellen, utan för detta specifika objekt.
Returnerar True om användaren har alla de angivna behörigheterna, där varje behörighet är i formatet "<app label>.<permission codename>". Om User.is_active och is_superuser båda är True returnerar denna metod alltid True.
Om obj anges kommer den här metoden inte att kontrollera behörigheter för modellen, utan för det specifika objektet.
Returnerar True om användaren har några behörigheter i det angivna paketet (Django-appens etikett). Om User.is_active och is_superuser båda är True, returnerar denna metod alltid True.
En begränsning med anpassade användarmodeller är att installation av en anpassad användarmodell kommer att bryta alla proxymodeller som utökar User. Proxymodeller måste baseras på en konkret basklass; genom att definiera en anpassad användarmodell tar du bort Djangos förmåga att på ett tillförlitligt sätt identifiera basklassen.
Om ditt projekt använder proxymodeller måste du antingen ändra proxyn för att utöka den användarmodell som används i ditt projekt, eller slå samman din proxys beteende i din User-underklass.
Här är ett exempel på en anpassad användarapp som är kompatibel med administratörer. Denna användarmodell använder en e-postadress som användarnamn och har ett obligatoriskt födelsedatum; den ger ingen behörighetskontroll utöver en admin-flagga på användarkontot. Den här modellen skulle vara kompatibel med alla inbyggda auth-formulär och -vyer, förutom formulären för att skapa användare. Detta exempel illustrerar hur de flesta komponenterna fungerar tillsammans, men är inte avsett att kopieras direkt till projekt för produktionsanvändning.
Denna kod skulle alla leva i en models.py-fil för en anpassad autentiseringsapp:
from django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError("Users must have an email address")\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password=None):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name="email address",\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = "email"\n REQUIRED_FIELDS = ["date_of_birth"]\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nFör att sedan registrera denna anpassade användarmodell med Djangos admin krävs följande kod i appens fil admin.py:
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\nfrom django.core.exceptions import ValidationError\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\n\n class Meta:\n model = MyUser\n fields = ["email", "date_of_birth"]\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ["email", "date_of_birth", "is_admin"]\n list_filter = ["is_admin"]\n fieldsets = [\n (None, {"fields": ["email", "password"]}),\n ("Personal info", {"fields": ["date_of_birth"]}),\n ("Permissions", {"fields": ["is_admin"]}),\n ]\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = [\n (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\nSlutligen anger du den anpassade modellen som standardanvändarmodell för ditt projekt med hjälp av inställningen AUTH_USER_MODEL i din settings.py:
AUTH_USER_MODEL = "customauth.MyUser"\nFör att optimera prestanda när den anropas från en asynkron kontextautentisering kan backends implementera asynkrona versioner av varje funktion - aget_user(user_id) och aauthenticate(request, **credentials). När en autentiseringsbackend utökar BaseBackend och async-versioner av dessa funktioner inte tillhandahålls, kommer de automatiskt att syntetiseras med sync_to_async. Detta har performance penalties.
Medan ett asynkront gränssnitt är valfritt, krävs alltid ett synkront gränssnitt. Det finns ingen automatisk syntes för ett synkront gränssnitt om ett asynkront gränssnitt är implementerat.
\nDjangos out-of-the-box autentiseringsbackends har inbyggt async-stöd. Om dessa inbyggda backends utökas, var särskilt noga med att se till att async-versionerna av modifierade funktioner också modifieras.
\n