django.contrib.auth

यह दस्तावेज़ Django के प्रमाणीकरण प्रणाली के घटकों के लिए एपीआई संदर्भ सामग्री प्रदान करता है। इन घटकों के उपयोग पर अधिक विवरण के लिए या प्रमाणीकरण और प्राधिकरण को कैसे अनुकूलित किया जाए, प्रमाणीकरण विषय गाइड देखें ।

User मॉडल

खेत

class models.User

User ऑब्जेक्ट्स में निम्नलिखित फ़ील्ड हैं:

username

आवश्यक है। 150 अक्षर या उससे कम। उपयोगकर्ता नाम में अल्फ़ान्यूमेरिक, _ , @ , + ,, हो सकते हैं . और - अक्षर।

कई उपयोग मामलों के लिए max_length पर्याप्त होनी चाहिए। यदि आपको एक लंबी लंबाई की आवश्यकता है, तो कृपया एक कस्टम उपयोगकर्ता मॉडल का उपयोग करें । यदि आप utf8mb4 एन्कोडिंग (उचित यूनिकोड समर्थन के लिए अनुशंसित) के साथ MySQL का उपयोग करते हैं, तो utf8mb4 max_length=191 पर निर्दिष्ट करें क्योंकि MySQL डिफ़ॉल्ट रूप से उस मामले में केवल 191 वर्णों के साथ अद्वितीय अनुक्रमित बना सकता है।

उपयोगकर्ता नाम और यूनिकोड

Django ने मूल रूप से उपयोगकर्ता नामों में केवल ASCII अक्षरों और संख्याओं को स्वीकार किया है। यद्यपि यह एक जानबूझकर विकल्प नहीं था, यूनिकोड वर्णों को हमेशा पायथन 3 का उपयोग करते समय स्वीकार किया गया है। Django 1.10 ने आधिकारिक तौर पर उपयोगकर्ता नाम में यूनिकोड समर्थन जोड़ा, पायथन 2 पर User.username_validator केवल व्यवहार रखते हुए, User.username_validator का उपयोग करके व्यवहार को अनुकूलित करने के विकल्प के साथ। ।

first_name

वैकल्पिक ( blank=True )। ३० अक्षर या उससे कम।

last_name

वैकल्पिक ( blank=True )। 150 अक्षर या उससे कम।

Django 2.0 में बदला:

max_length 30 से 150 वर्णों तक बढ़ गई।

email

वैकल्पिक ( blank=True )। ईमेल पता।

password

आवश्यक है। पासवर्ड के बारे में और मेटाडेटा का हैश, और। (Django कच्चे पासवर्ड को संग्रहीत नहीं करता है।) कच्चे पासवर्ड मनमाने ढंग से लंबे हो सकते हैं और इसमें कोई भी चरित्र हो सकता है। पासवर्ड प्रलेखन देखें।

groups

Group से कई-कई संबंध

user_permissions

Permission लिए कई-से-कई संबंध

is_staff

बूलियन। नामित करता है कि क्या यह उपयोगकर्ता व्यवस्थापक साइट तक पहुंच सकता है।

is_active

बूलियन। नामित करता है कि क्या इस उपयोगकर्ता खाते को सक्रिय माना जाना चाहिए। हम अनुशंसा करते हैं कि आप खातों को हटाने के बजाय इस ध्वज को False सेट करें; इस तरह, यदि आपके एप्लिकेशन में उपयोगकर्ताओं के लिए कोई विदेशी कुंजी है, तो विदेशी कुंजी नहीं टूटेगी।

यह आवश्यक रूप से नियंत्रित नहीं करता है कि उपयोगकर्ता लॉग इन कर सकता है या नहीं। प्रमाणीकरण बैकएंड को is_active फ्लैग की जांच करने की आवश्यकता नहीं है लेकिन डिफ़ॉल्ट बैकएंड ( ModelBackend ) और RemoteUserBackend करते हैं। यदि आप निष्क्रिय उपयोगकर्ताओं को लॉगिन करने की अनुमति देना चाहते हैं, तो आप AllowAllUsersModelBackend या AllowAllUsersRemoteUserBackend उपयोग कर सकते हैं। इस स्थिति में, आप निष्क्रिय उपयोगकर्ताओं द्वारा उपयोग किए गए AuthenticationForm LoginView को निष्क्रिय करना LoginView क्योंकि यह निष्क्रिय उपयोगकर्ताओं को अस्वीकार करता है। ज्ञात हो कि अनुमति-जाँच के तरीके जैसे has_perm() और प्रमाणीकरण में Django व्यवस्थापक सभी निष्क्रिय उपयोगकर्ताओं के लिए False लौटाते हैं।

is_superuser

बूलियन। यह निर्दिष्ट करता है कि इस उपयोगकर्ता के पास स्पष्ट रूप से निर्दिष्ट किए बिना सभी अनुमतियां हैं।

last_login

उपयोगकर्ता के अंतिम लॉगिन का एक डेटाटाइम।

date_joined

जब खाता बनाया गया था तो एक डेटाइम पदनाम। खाता बनाते समय डिफ़ॉल्ट रूप से वर्तमान दिनांक / समय पर सेट किया जाता है।

गुण

class models.User

is_authenticated

केवल-पढ़ने का गुण जो हमेशा True (जैसा कि AnonymousUser.is_authenticated विपरीत है जो हमेशा False )। यह यह बताने का एक तरीका है कि क्या उपयोगकर्ता को प्रमाणित किया गया है। यह किसी भी अनुमति का अर्थ नहीं है और यह जाँच नहीं करता है कि उपयोगकर्ता सक्रिय है या उसके पास एक वैध सत्र है। भले ही आम तौर पर आप request.user पर इस विशेषता की जांच करेंगे। यह पता लगाने के लिए कि क्या यह AuthenticationMiddleware (वर्तमान में लॉग-इन उपयोगकर्ता का प्रतिनिधित्व करते हुए) द्वारा आबाद किया गया है, आपको पता होना चाहिए कि यह विशेषता किसी भी User उदाहरण के लिए True ।

is_anonymous

पढ़ें-केवल विशेषता जो हमेशा False । यह User और AnonymousUser वस्तुओं को अलग करने का एक तरीका है। आम तौर पर, आपको इस विशेषता के लिए is_authenticated का उपयोग करना पसंद करना चाहिए।

username_validator

उपयोगकर्ता नाम को मान्य करने के लिए उपयोग किए जाने वाले सत्यापनकर्ता उदाहरण के बिंदु। validators.UnicodeUsernameValidator लिए डिफ़ॉल्ट। validators.UnicodeUsernameValidator ।

डिफ़ॉल्ट उपयोगकर्ता नाम सत्यापनकर्ता को बदलने के लिए, आप User मॉडल को उपवर्ग कर सकते हैं और इस विशेषता को एक अलग सत्यापनकर्ता उदाहरण में सेट कर सकते हैं। उदाहरण के लिए, ASCII उपयोगकर्ता नाम का उपयोग करने के लिए:

from django.contrib.auth.models import User
from django.contrib.auth.validators import ASCIIUsernameValidator

class CustomUser(User):
    username_validator = ASCIIUsernameValidator()

    class Meta:
        proxy = True  # If no new field is added.

तरीके

class models.User

get_username()

उपयोगकर्ता के लिए उपयोगकर्ता नाम लौटाता है। चूंकि User मॉडल को स्वैप किया जा सकता है, इसलिए आपको सीधे उपयोगकर्ता नाम विशेषता को संदर्भित करने के बजाय इस पद्धति का उपयोग करना चाहिए।

get_full_name()

बीच में एक स्थान के साथ last_name और last_name लौटाता है।

get_short_name()

first_name लौटाता है।

set_password(raw_password)

पासवर्ड हैशिंग का ध्यान रखते हुए, दिए गए कच्चे स्ट्रिंग में उपयोगकर्ता का पासवर्ड सेट करता है। User ऑब्जेक्ट को सहेजता नहीं है।

जब raw_password None , तो पासवर्ड अनुपयोगी पासवर्ड पर सेट हो जाएगा, जैसे कि set_unusable_password() का उपयोग किया गया था।

check_password(raw_password)

यदि दिया गया कच्चा स्ट्रिंग उपयोगकर्ता के लिए सही पासवर्ड है तो सही है। (यह तुलना करने में पासवर्ड हैशिंग का ध्यान रखता है।)

set_unusable_password()

पासवर्ड सेट न होने के कारण उपयोगकर्ता को चिह्नित करता है। यह पासवर्ड के लिए रिक्त स्ट्रिंग के समान नहीं है। इस उपयोगकर्ता के लिए check_password() कभी भी वापस नहीं आएगा। User ऑब्जेक्ट को सहेजता नहीं है।

यदि आपके आवेदन के लिए प्रमाणीकरण किसी मौजूदा बाहरी स्रोत जैसे LDAP निर्देशिका के लिए होता है, तो आपको इसकी आवश्यकता हो सकती है।

has_usable_password()

यदि इस उपयोगकर्ता के लिए set_unusable_password() कहा जाता है, तो False रिटर्न देता है।

Django 2.1 में परिवर्तित:

पुराने संस्करणों में, यह पासवर्ड या कोई खाली स्ट्रिंग None होने पर भी False रिटर्न देता है, या यदि पासवर्ड एक हैशर का उपयोग करता है जो PASSWORD_HASHERS सेटिंग में नहीं है। यह व्यवहार बग के रूप में माना जाता है क्योंकि यह ऐसे पासवर्ड वाले उपयोगकर्ताओं को पासवर्ड रीसेट करने का अनुरोध करने से रोकता है।

get_group_permissions(obj=None)

उपयोगकर्ता द्वारा अपने समूहों के माध्यम से अनुमति स्ट्रिंग का एक सेट लौटाता है।

यदि obj पास हो जाता है, तो केवल इस विशिष्ट ऑब्जेक्ट के लिए समूह की अनुमति देता है।

get_all_permissions(obj=None)

अनुमति स्ट्रिंग का एक सेट लौटाता है जो उपयोगकर्ता के पास समूह और उपयोगकर्ता अनुमतियों के माध्यम से होता है।

यदि obj पास हो जाता है, तो केवल इस विशिष्ट ऑब्जेक्ट के लिए अनुमति देता है।

has_perm(perm, obj=None)

यदि उपयोगकर्ता के पास निर्दिष्ट अनुमति है तो यह True , जहां प्रारूप "<app label>.<permission codename>" प्रारूप में है। ( permissions पर प्रलेखन देखें)। यदि उपयोगकर्ता निष्क्रिय है, तो यह विधि हमेशा False लौटेगी।

यदि obj पास हो जाता है, तो यह विधि मॉडल की अनुमति के लिए नहीं, बल्कि इस विशिष्ट ऑब्जेक्ट के लिए जाँच करेगी।

has_perms(perm_list, obj=None)

यदि उपयोगकर्ता के पास प्रत्येक निर्दिष्ट अनुमतियाँ हैं, तो यह True , जहाँ प्रत्येक अनुमति "<app label>.<permission codename>" प्रारूप में है। यदि उपयोगकर्ता निष्क्रिय है, तो यह विधि हमेशा False लौटेगी।

यदि obj पास हो जाता है, तो यह विधि मॉडल के लिए अनुमतियों के लिए नहीं, बल्कि विशिष्ट ऑब्जेक्ट के लिए जाँच करेगी।

has_module_perms(package_name)

यदि उपयोगकर्ता दिए गए पैकेज (Django ऐप लेबल) में कोई अनुमति है तो True । यदि उपयोगकर्ता निष्क्रिय है, तो यह विधि हमेशा False लौटेगी।

email_user(subject, message, from_email=None, **kwargs)

उपयोगकर्ता को एक ईमेल भेजता है। यदि from_email None , तो Django DEFAULT_FROM_EMAIL का उपयोग करता है। किसी भी **kwargs को अंतर्निहित send_mail() कॉल पर send_mail() दिया जाता है।

प्रबंधक के तरीके

class models.UserManager

User मॉडल में एक कस्टम प्रबंधक होता है जिसमें निम्न सहायक विधियाँ होती हैं ( BaseUserManager द्वारा प्रदान की गई विधियों के अतिरिक्त):

create_user(username, email=None, password=None, **extra_fields)

एक User बनाता है, बचाता है और वापस लौटाता है।

username और password दिए गए हैं। email का डोमेन भाग स्वचालित रूप से लोअरकेस में बदल जाता है, और लौटाए गए User ऑब्जेक्ट में is_active सेट टू True ।

यदि कोई पासवर्ड प्रदान नहीं किया गया है, तो set_unusable_password() कहा जाएगा।

extra_fields खोजशब्द तर्क एक कस्टम मॉडल मॉडल पर मनमाने ढंग से फ़ील्ड सेट करने की अनुमति देने के लिए User के __init__ विधि के माध्यम से पारित किए जाते हैं।

उदाहरण उपयोग के लिए उपयोगकर्ता बनाना देखें।

create_superuser(username, email, password, **extra_fields)

create_user() रूप में भी, लेकिन सेट is_staff और is_superuser से True ।

AnonymousUser वस्तु

class models.AnonymousUser

AnonymousUser इन अंतरों के साथ User इंटरफ़ेस को लागू करने User एक वर्ग है:

• id हमेशा None
• username हमेशा रिक्त स्ट्रिंग है।
• get_username() हमेशा खाली स्ट्रिंग लौटाता है।
• is_anonymous False बजाय True ।
• is_authenticated True बजाय False ।
• is_staff और is_superuser हमेशा False होते हैं।
• is_active हमेशा False ।
• groups और user_permissions हमेशा खाली होते हैं।
• set_password() , check_password() , save() और delete() NotImplementedError ।

व्यवहार में, आपको शायद अपने दम पर AnonymousUser ऑब्जेक्ट्स का उपयोग करने की आवश्यकता नहीं होगी, लेकिन वे वेब अनुरोधों द्वारा उपयोग किए जाते हैं, जैसा कि अगले भाग में बताया गया है।

Permission मॉडल

class models.Permission

खेत

Permission ऑब्जेक्ट्स में निम्नलिखित फ़ील्ड हैं:

class models.Permission

name

आवश्यक है। 255 अक्षर या उससे कम। उदाहरण: 'Can vote' ।

content_type

आवश्यक है। django_content_type डेटाबेस तालिका का संदर्भ, जिसमें प्रत्येक स्थापित मॉडल के लिए एक रिकॉर्ड होता है।

codename

आवश्यक है। 100 अक्षर या उससे कम। उदाहरण: 'can_vote' ।

तरीके

Permission ऑब्जेक्ट में किसी भी अन्य Django मॉडल की तरह मानक डेटा-एक्सेस के तरीके हैं।

Group मॉडल

class models.Group

खेत

Group ऑब्जेक्ट में निम्न फ़ील्ड हैं:

class models.Group

name

आवश्यक है। 80 अक्षर या उससे कम। किसी भी वर्ण की अनुमति है। उदाहरण: 'Awesome Users' ।

permissions

Permission लिए कई-से-कई फ़ील्ड:

group.permissions.set([permission_list])
group.permissions.add(permission, permission, ...)
group.permissions.remove(permission, permission, ...)
group.permissions.clear()

प्रमाणकों

class validators.ASCIIUsernameValidator

एक फ़ील्ड सत्यापनकर्ता @ अलावा, केवल ASCII अक्षरों और संख्याओं की अनुमति देता है . , + , - , और _ ।

class validators.UnicodeUsernameValidator

एक फ़ील्ड सत्यापनकर्ता, @ अलावा, यूनिकोड वर्णों को अनुमति देता है . , + , - , और _ । User.username लिए डिफ़ॉल्ट सत्यापनकर्ता।

लॉगिन और लॉगआउट सिग्नल

उपयोगकर्ता द्वारा अंदर या बाहर जाने पर सूचना के लिए उपयोग किए जा सकने वाले निम्न signals का उपयोग करता है।

user_logged_in()

जब उपयोगकर्ता सफलतापूर्वक लॉग इन करता है तो भेजा जाता है।

इस संकेत के साथ भेजे गए तर्क:

sender

उपयोगकर्ता का वर्ग जो अभी लॉग इन किया है।

request

वर्तमान HttpRequest उदाहरण।

user

उपयोगकर्ता उदाहरण है कि बस में लॉग इन किया।

user_logged_out()

लॉगआउट विधि कहा जाता है जब भेजा।

sender

जैसा कि ऊपर: उपयोगकर्ता का वर्ग जो केवल लॉग आउट किया था या यदि उपयोगकर्ता प्रमाणित नहीं किया गया था तो None नहीं।

request

वर्तमान HttpRequest उदाहरण।

user

उपयोगकर्ता उदाहरण जो सिर्फ लॉग आउट किया गया था या यदि उपयोगकर्ता प्रमाणित नहीं था तो None नहीं।

user_login_failed()

भेजा गया जब उपयोगकर्ता सफलतापूर्वक लॉगिन करने में विफल रहा

sender

प्रमाणीकरण के लिए उपयोग किए जाने वाले मॉड्यूल का नाम।

credentials

उपयोगकर्ता के तर्क युक्त एक शब्दकोष जिसमें उपयोगकर्ता क्रेडेंशियल्स को authenticate() करने के लिए पारित किया गया था authenticate() या आपके स्वयं के कस्टम प्रमाणीकरण बैकएंड। क्रेडेंशियल 'संवेदनशील' पैटर्न के एक सेट से मेल खाते हैं, (पासवर्ड सहित) सिग्नल के हिस्से के रूप में स्पष्ट में नहीं भेजा जाएगा।

request

HttpRequest ऑब्जेक्ट, यदि कोई authenticate() करने के लिए प्रदान किया गया था authenticate() ।

प्रमाणीकरण का समर्थन करता है

यह खंड उन प्रमाणीकरणों का विवरण देता है जो Django के साथ आते हैं। उनका उपयोग कैसे करें और अपने स्वयं के प्रमाणीकरण बैकेंड कैसे लिखें, इसकी जानकारी के लिए, उपयोगकर्ता प्रमाणीकरण मार्गदर्शिका के अन्य प्रमाणीकरण स्रोत अनुभाग देखें।

उपलब्ध प्रमाणीकरण का समर्थन करता है

निम्नलिखित बैकेंड django.contrib.auth.backends में उपलब्ध हैं:

class ModelBackend

यह Django द्वारा उपयोग किया जाने वाला डिफ़ॉल्ट प्रमाणीकरण बैकएंड है। यह उपयोगकर्ता पहचानकर्ता और पासवर्ड युक्त क्रेडेंशियल्स का उपयोग करके प्रमाणित करता है। Django के डिफ़ॉल्ट उपयोगकर्ता मॉडल के लिए, उपयोगकर्ता पहचानकर्ता उपयोगकर्ता नाम है, कस्टम उपयोगकर्ता मॉडल के लिए यह USERNAME_FIELD द्वारा निर्दिष्ट फ़ील्ड है ( उपयोगकर्ताओं को अनुकूलित और प्रमाणीकरण देखें )।

यह डिफ़ॉल्ट अनुमतियाँ मॉडल को भी संभालता है जैसा कि User और PermissionsMixin लिए परिभाषित किया गया है।

has_perm() , get_all_permissions() , get_user_permissions() , और get_group_permissions() ऑब्जेक्ट-विशिष्ट अनुमतियों के लिए एक पैरामीटर के रूप में पारित होने की अनुमति देते हैं, लेकिन यह get_group_permissions() अनुमतियों के एक खाली सेट को वापस करने के अलावा उन्हें लागू नहीं करता है यदि obj is not None ।

authenticate(request, username=None, password=None, **kwargs)

check_password() कॉल करके password साथ username प्रमाणित करने की कोशिश check_password() । यदि कोई username प्रदान नहीं किया गया है, तो यह कुंजी CustomUser.USERNAME_FIELD का उपयोग करके kwargs से उपयोगकर्ता नाम प्राप्त करने का प्रयास करता है। एक प्रमाणित उपयोगकर्ता या None लौटाता है।

request एक HttpRequest और ऐसा None हो सकता है यदि इसे authenticate() करने के लिए प्रदान नहीं किया गया था authenticate() (जो इसे बैकएंड पर पास करता है)।

get_user_permissions(user_obj, obj=None)

अनुमति का सेट लौटाता है जो user_obj पास अपनी स्वयं की उपयोगकर्ता अनुमतियों से होता है। एक खाली सेट लौटाता है अगर is_anonymous या is_active False ।

get_group_permissions(user_obj, obj=None)

उपयोगकर्ता के पास उन समूहों की अनुमतियों से उपयोगकर्ता स्ट्रिंग की अनुमति स्ट्रिंग सेट देता है। एक खाली सेट लौटाता है अगर is_anonymous या is_active False ।

get_all_permissions(user_obj, obj=None)

उपयोगकर्ता के पास और समूह की अनुमति दोनों सहित user_obj पास अनुमति स्ट्रिंग का सेट लौटाता है। एक खाली सेट लौटाता है अगर is_anonymous या is_active False ।

has_perm(user_obj, perm, obj=None)

अगर user_obj पास अनुमति स्ट्रिंग perm है, तो यह जांचने के लिए get_all_permissions() का उपयोग करता है। यदि उपयोगकर्ता is_active नहीं है तो False रिटर्न देता है।

has_module_perms(user_obj, app_label)

यह app_label कि क्या user_obj पास app app_label पर कोई अनुमति है app_label ।

user_can_authenticate()

लौटाता है कि क्या उपयोगकर्ता को प्रमाणित करने की अनुमति है। AuthenticationForm के व्यवहार से मेल खाने के लिए जो prohibits inactive users from logging in , यह विधि is_active साथ उपयोगकर्ताओं के लिए False लौटाती है। कस्टम उपयोगकर्ता मॉडल जिनके पास is_active फ़ील्ड नहीं है उन्हें अनुमति दी जाती है।

class AllowAllUsersModelBackend

ModelBackend रूप में समान है सिवाय इसके कि यह निष्क्रिय उपयोगकर्ताओं को अस्वीकार नहीं करता है क्योंकि user_can_authenticate() हमेशा True लौटाता है।

इस बैकएंड का उपयोग करते समय, आप इसकी LoginView करना LoginView कि LoginView द्वारा उपयोग किए गए confirm_login_allowed() विधि को ओवरराइड करके यह निष्क्रिय उपयोगकर्ताओं को अस्वीकार कर देता है।

class RemoteUserBackend

एक्सटर्नल-टू-Django- हैंडेड ऑथेंटिकेशन का फायदा उठाने के लिए इस बैकेंड का इस्तेमाल करें। यह request.META['REMOTE_USER'] में पारित उपयोगकर्ता नाम का उपयोग करके प्रमाणित करता है। request.META['REMOTE_USER'] । REMOTE_USER प्रलेखन के विरुद्ध प्रमाणीकरण देखें।

यदि आपको अधिक नियंत्रण की आवश्यकता है, तो आप अपना स्वयं का प्रमाणीकरण बैकएंड बना सकते हैं जो इस वर्ग से प्राप्त होता है और इन विशेषताओं या विधियों को ओवरराइड करता है:

RemoteUserBackend.create_unknown_user

True या False । निर्धारित करता है कि डेटाबेस ऑब्जेक्ट पहले से ही True नहीं है, तो उपयोगकर्ता ऑब्जेक्ट बनाया गया है या नहीं।

RemoteUserBackend.authenticate(request, remote_user)

remote_user रूप में पारित उपयोगकर्ता नाम विश्वसनीय माना जाता है। यह विधि केवल दिए गए उपयोगकर्ता नाम के साथ उपयोगकर्ता ऑब्जेक्ट create_unknown_user है, यदि create_unknown_user True है तो एक नया उपयोगकर्ता ऑब्जेक्ट create_unknown_user है।

रिटर्न None अगर create_unknown_user False और दिए गए उपयोगकर्ता नाम के साथ User ऑब्जेक्ट डेटाबेस में नहीं मिला है।

request एक HttpRequest और ऐसा None हो सकता है यदि इसे authenticate() करने के लिए प्रदान नहीं किया गया था authenticate() (जो इसे बैकएंड पर पास करता है)।

RemoteUserBackend.clean_username(username)

उपयोगकर्ता ऑब्जेक्ट प्राप्त करने या बनाने के लिए उपयोग करने से पहले username (जैसे कि LDAP DN सूचना को अलग करना) पर कोई भी सफाई करता है। साफ किया गया उपयोगकर्ता नाम लौटाता है।

RemoteUserBackend.configure_user(user)

एक नए बनाए गए उपयोगकर्ता को कॉन्फ़िगर करता है। नया उपयोगकर्ता बनने के तुरंत बाद इस विधि को कहा जाता है, और इसका उपयोग कस्टम सेटअप क्रियाओं को करने के लिए किया जा सकता है, जैसे कि LDAP निर्देशिका में विशेषताओं के आधार पर उपयोगकर्ता के समूह सेट करना। उपयोगकर्ता ऑब्जेक्ट लौटाता है।

RemoteUserBackend.user_can_authenticate()

लौटाता है कि क्या उपयोगकर्ता को प्रमाणित करने की अनुमति है। यह विधि is_active उपयोगकर्ताओं के लिए False लौटाती है। कस्टम उपयोगकर्ता मॉडल जिनके पास is_active फ़ील्ड नहीं है उन्हें अनुमति दी जाती है।

class AllowAllUsersRemoteUserBackend

RemoteUserBackend रूप में भी इसे छोड़कर यह निष्क्रिय उपयोगकर्ताओं को अस्वीकार नहीं करता है क्योंकि user_can_authenticate हमेशा True लौटाता है।

उपयोगिता कार्य

get_user(request) [source]

दिए गए request के सत्र से जुड़े उपयोगकर्ता मॉडल का उदाहरण देता है।

यह जाँचता है कि क्या प्रमाणीकरण बैकेंड सत्र में संग्रहीत AUTHENTICATION_BACKENDS में मौजूद है। यदि ऐसा है, तो यह उपयोगकर्ता मॉडल का उदाहरण प्राप्त करने के लिए बैकएंड के get_user() विधि का उपयोग करता है और फिर उपयोगकर्ता मॉडल के get_session_auth_hash() विधि को कॉल करके सत्र की पुष्टि करता है।

यदि कोई उपयोगकर्ता बैकएंड के get_user() विधि से लौटा नहीं है, या यदि सत्र get_user() मान्य नहीं करता है, तो AnonymousUser का एक उदाहरण लौटाता है, जो सत्र में संग्रहीत प्रमाणीकरण get_user() नहीं है।