Django 2.1
django.contrib.auth

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_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
, तो DjangoDEFAULT_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
।
-
id
हमेशा
व्यवहार में, आपको शायद अपने दम पर
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
पास appapp_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()
नहीं है।