Django प्रमाणीकरण प्रणाली का उपयोग करना

यह दस्तावेज़ अपने डिफ़ॉल्ट कॉन्फ़िगरेशन में Django के प्रमाणीकरण प्रणाली के उपयोग की व्याख्या करता है। यह कॉन्फ़िगरेशन सबसे आम परियोजना की जरूरतों को पूरा करने के लिए विकसित हुआ है, कार्यों की एक विस्तृत श्रृंखला को संभालता है, और पासवर्ड और अनुमतियों का सावधानीपूर्वक कार्यान्वयन करता है। उन परियोजनाओं के लिए जहाँ प्रमाणीकरण की आवश्यकता डिफ़ॉल्ट से भिन्न होती है, Django प्रमाणीकरण के व्यापक विस्तार और अनुकूलन का समर्थन करता है।

Django प्रमाणीकरण प्रमाणीकरण और प्राधिकरण दोनों को एक साथ प्रदान करता है और आमतौर पर प्रमाणीकरण प्रणाली के रूप में संदर्भित किया जाता है, क्योंकि ये विशेषताएं कुछ हद तक युग्मित हैं।

User ऑब्जेक्ट

User ऑब्जेक्ट प्रमाणीकरण प्रणाली का मूल हैं। वे आम तौर पर आपकी साइट के साथ बातचीत करने वाले लोगों का प्रतिनिधित्व करते हैं और इसका उपयोग चीजों को प्रतिबंधित करने, उपयोगकर्ता प्रोफाइल को पंजीकृत करने, रचनाकारों के साथ सामग्री को जोड़ने आदि के लिए किया जाता है। उपयोगकर्ता का केवल एक वर्ग Django के प्रमाणीकरण ढांचे में मौजूद है, अर्थात, 'superusers' या व्यवस्थापक: उपयोगकर्ता केवल विशेष ऑब्जेक्ट सेट के साथ उपयोगकर्ता ऑब्जेक्ट हैं, उपयोगकर्ता ऑब्जेक्ट के विभिन्न वर्ग नहीं।

डिफ़ॉल्ट उपयोगकर्ता की प्राथमिक विशेषताएँ हैं:

• username
• password
• email
• first_name
• last_name

पूर्ण संदर्भ के लिए User देखें, इस प्रकार है कि प्रलेखन अधिक कार्य उन्मुख है।

उपयोगकर्ता बनाना

उपयोगकर्ताओं को बनाने का सबसे सीधा तरीका शामिल create_user() सहायक फ़ंक्शन का उपयोग करना है:

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', '[email protected]', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

यदि आपके पास Django व्यवस्थापक स्थापित है, तो आप उपयोगकर्ताओं को अंतःक्रियात्मक रूप से भी बना सकते हैं ।

सुपरसर्स बनाना

createsuperuser कमांड का उपयोग करके createsuperuser बनाएं:

$ python manage.py createsuperuser --username=joe [email protected]

आपको पासवर्ड के लिए संकेत दिया जाएगा। आपके द्वारा एक दर्ज करने के बाद, उपयोगकर्ता तुरंत बनाया जाएगा। यदि आप --username या --email विकल्प --email हैं, तो यह आपको उन मूल्यों के लिए संकेत देगा।

पासवर्ड बदलना

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

उपयोगकर्ता का पासवर्ड बदलने के लिए, आपके पास कई विकल्प हैं:

manage.py changepassword *username* कमांड लाइन से उपयोगकर्ता का पासवर्ड बदलने का एक तरीका प्रदान करता है। यह आपको दिए गए उपयोगकर्ता के पासवर्ड को बदलने का संकेत देता है जिसे आपको दो बार दर्ज करना होगा। यदि वे दोनों मेल खाते हैं, तो नया पासवर्ड तुरंत बदल दिया जाएगा। यदि आप एक उपयोगकर्ता की आपूर्ति नहीं करते हैं, तो कमांड उस पासवर्ड को बदलने का प्रयास करेगा जिसका उपयोगकर्ता नाम मौजूदा सिस्टम उपयोगकर्ता से मेल खाता है।

आप set_password() का उपयोग करके प्रोग्राम को पासवर्ड भी बदल सकते हैं:

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

यदि आपके पास Django व्यवस्थापक स्थापित है, तो आप प्रमाणीकरण प्रणाली के व्यवस्थापक पृष्ठों पर उपयोगकर्ता के पासवर्ड भी बदल सकते हैं।

Django भी उन views और forms प्रदान करता है जिनका उपयोग उपयोगकर्ताओं को अपने पासवर्ड बदलने की अनुमति देने के लिए किया जा सकता है।

उपयोगकर्ता का पासवर्ड बदलने से उनके सभी सत्र समाप्त हो जाएंगे। विवरण के लिए पासवर्ड परिवर्तन पर सत्र अमान्य देखें।

उपयोगकर्ताओं का प्रमाणीकरण

authenticate(request=None, **credentials) [source]

authenticate() एक समूह को सत्यापित करने के लिए authenticate() का उपयोग करें। यह डिफ़ॉल्ट मामले के लिए कीवर्ड तर्क, username और password रूप में क्रेडेंशियल लेता है, प्रत्येक प्रमाणीकरण बैकएंड के खिलाफ उन्हें जांचता है, और User ऑब्जेक्ट को बैकेंड के लिए मान्य होने पर वापस लौटाता है। यदि क्रेडेंशियल किसी बैकएंड के लिए मान्य नहीं हैं या यदि कोई बैकएंड PermissionDenied उठाता है, तो यह None लौटाता है। उदाहरण के लिए:

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials

request एक वैकल्पिक HttpRequest जो प्रमाणीकरण बैकेंड के authenticate() विधि पर पारित किया गया है।

ध्यान दें

यह क्रेडेंशियल्स के एक सेट को प्रमाणित करने का एक निम्न स्तर का तरीका है; उदाहरण के लिए, इसका उपयोग RemoteUserMiddleware द्वारा किया जाता है। जब तक आप अपना स्वयं का प्रमाणीकरण सिस्टम नहीं लिख रहे हैं, तब तक आप शायद इसका उपयोग नहीं करेंगे। यदि आप किसी उपयोगकर्ता को लॉग इन करने का तरीका ढूंढ रहे हैं, तो लॉगिन LoginView उपयोग करें।

अनुमतियाँ और प्राधिकरण

Django एक सरल अनुमति प्रणाली के साथ आता है। यह विशिष्ट उपयोगकर्ताओं और उपयोगकर्ताओं के समूहों को अनुमति प्रदान करने का एक तरीका प्रदान करता है।

यह Django व्यवस्थापक साइट द्वारा उपयोग किया जाता है, लेकिन आप इसे अपने कोड में उपयोग करने के लिए स्वागत करते हैं।

Django व्यवस्थापक साइट अनुमतियों का उपयोग इस प्रकार करता है:

• ऑब्जेक्ट को देखने के लिए पहुंच "ऑब्जेक्ट" या "परिवर्तन" के साथ उपयोगकर्ताओं तक सीमित है, उस प्रकार की वस्तु के लिए अनुमति है।
• "जोड़ें" फ़ॉर्म को देखने और किसी ऑब्जेक्ट को जोड़ने के लिए एक्सेस उस प्रकार की ऑब्जेक्ट के लिए "ऐड" अनुमति वाले उपयोगकर्ताओं तक सीमित है।
• परिवर्तन सूची देखने के लिए, "परिवर्तन" फ़ॉर्म देखें और किसी ऑब्जेक्ट को बदलने से उस प्रकार की ऑब्जेक्ट के लिए "परिवर्तन" अनुमति वाले उपयोगकर्ताओं तक सीमित हो जाता है।
• किसी ऑब्जेक्ट को हटाने के लिए पहुंच उस प्रकार की ऑब्जेक्ट के लिए "हटाएं" अनुमति वाले उपयोगकर्ताओं तक सीमित है।

अनुमतियाँ न केवल प्रति प्रकार की वस्तु पर, बल्कि विशिष्ट वस्तु उदाहरण के अनुसार भी सेट की जा सकती हैं। ModelAdmin वर्ग द्वारा प्रदान की गई has_view_permission() , has_add_permission() , has_change_permission() और has_delete_permission() विधियों का उपयोग करके, एक ही प्रकार की विभिन्न ऑब्जेक्ट इंस्टेंसेस की अनुमतियों को अनुकूलित करना संभव है।

User ऑब्जेक्ट्स में दो कई-से-कई फ़ील्ड हैं: groups और user_permissions । User ऑब्जेक्ट्स अपने संबंधित ऑब्जेक्ट्स को उसी तरह एक्सेस कर सकते हैं जैसे कोई अन्य Django मॉडल :

myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()

डिफ़ॉल्ट अनुमतियाँ

जब django.contrib.auth को आपके INSTALLED_APPS सेटिंग में सूचीबद्ध किया जाता है, तो यह सुनिश्चित करेगा कि आपके स्थापित अनुप्रयोगों में परिभाषित प्रत्येक Django मॉडल के लिए तीन डिफ़ॉल्ट अनुमतियाँ - जोड़ें, बदलें और हटाएं - बनाई गई हैं।

ये अनुमतियाँ तब बनाई जाएंगी, जब आप manage.py migrate । पहली बार जब आप django.contrib.auth को INSTALLED_APPS जोड़ने के बाद migrate , तो डिफ़ॉल्ट अनुमतियाँ पहले से इंस्टॉल किए गए सभी मॉडलों के लिए बनाई जाएंगी, साथ ही उस समय स्थापित किए जा रहे किसी भी नए मॉडल के लिए भी। बाद में, यह हर बार नए मॉडल के लिए डिफ़ॉल्ट अनुमतियाँ बनाएगा, जब आप post_migrate को चलाते manage.py migrate ( manage.py migrate का कार्य जो फ़ंक्शन post_migrate सिग्नल से जुड़ा है)।

मान लें कि आपके पास एक app_label foo और Bar नाम के एक मॉडल के साथ एक एप्लिकेशन है, जिसका उपयोग करने के लिए आपको मूलभूत अनुमतियों का परीक्षण करना चाहिए:

• जोड़ें: user.has_perm('foo.add_bar')
• परिवर्तन: user.has_perm('foo.change_bar')
• हटाएं: user.has_perm('foo.delete_bar')
• देखें: user.has_perm('foo.view_bar')

Permission मॉडल शायद ही कभी सीधे पहुँचा है।

समूह

django.contrib.auth.models.Group मॉडल उन उपयोगकर्ताओं को वर्गीकृत करने का एक सामान्य तरीका है जिससे आप उन उपयोगकर्ताओं को अनुमतियाँ, या कुछ अन्य लेबल लागू कर सकते हैं। एक उपयोगकर्ता किसी भी समूह से संबंधित हो सकता है।

किसी समूह का उपयोगकर्ता स्वचालित रूप से उस समूह को अनुमतियाँ देता है। उदाहरण के लिए, यदि समूह Site editors पास can_edit_home_page की अनुमति है, तो उस समूह के किसी भी उपयोगकर्ता के पास यह अनुमति होगी।

अनुमतियों से परे, समूह उपयोगकर्ताओं को कुछ लेबल, या विस्तारित कार्यक्षमता देने के लिए वर्गीकृत करने का एक सुविधाजनक तरीका है। उदाहरण के लिए, आप एक समूह 'Special users' बना सकते हैं, और आप ऐसा कोड लिख सकते हैं, जो कह सकते हैं, उन्हें अपनी साइट के केवल एक सदस्य तक पहुँच दे सकते हैं, या उन्हें केवल सदस्य ईमेल संदेश भेज सकते हैं।

प्रोग्रामेटिक रूप से अनुमतियाँ बनाना

जबकि कस्टम अनुमतियां किसी मॉडल के Meta क्लास के भीतर परिभाषित की जा सकती हैं, आप सीधे अनुमति भी बना सकते हैं। उदाहरण के लिए, आप can_publish में can_publish मॉडल के लिए can_publish अनुमति बना सकते हैं:

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename='can_publish',
    name='Can Publish Posts',
    content_type=content_type,
)

अनुमति तब User को उसके user_permissions विशेषता के माध्यम से या किसी django.contrib.auth.models.Group को इसकी permissions विशेषता के द्वारा permissions है।

अनुमति कैशिंग

पहली बार अनुमतियों की जांच के लिए उन्हें लाने की आवश्यकता है, तब ModelBackend उपयोगकर्ता ऑब्जेक्ट पर अनुमतियाँ कैश करता है। यह आमतौर पर अनुरोध-प्रतिक्रिया चक्र के लिए ठीक है क्योंकि अनुमतियों को आम तौर पर जांचने के तुरंत बाद नहीं जोड़ा जाता है (व्यवस्थापक में, उदाहरण के लिए)। यदि आप अनुमतियाँ जोड़ रहे हैं और उन्हें तुरंत बाद में जाँच कर रहे हैं, उदाहरण के लिए एक परीक्षण या दृश्य में, सबसे आसान समाधान उपयोगकर्ता को डेटाबेस से फिर से प्राप्त करना है। उदाहरण के लिए:

from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...

वेब अनुरोधों में प्रमाणीकरण

Django HttpRequest में प्रमाणीकरण प्रणाली को हुक करने के लिए sessions और मिडलवेयर का उपयोग करता है।

ये प्रत्येक अनुरोध पर एक request.user प्रदान करते हैं। वर्तमान उपयोगकर्ता का प्रतिनिधित्व करता है। यदि वर्तमान उपयोगकर्ता ने लॉग इन नहीं किया है, तो यह विशेषता AnonymousUser उदाहरण पर सेट की जाएगी, अन्यथा यह User का एक उदाहरण होगा।

आप उन्हें is_authenticated साथ अलग बता सकते हैं, जैसे:

if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

कैसे एक उपयोगकर्ता में प्रवेश करने के लिए

यदि आपके पास एक प्रमाणित उपयोगकर्ता है जिसे आप वर्तमान सत्र में संलग्न करना चाहते हैं - यह एक login() फ़ंक्शन के साथ किया जाता है।

login(request, user, backend=None) [source]

किसी उपयोगकर्ता को किसी दृश्य से लॉग इन करने के लिए, login() उपयोग करें। यह एक HttpRequest ऑब्जेक्ट और एक User ऑब्जेक्ट लेता है। login() Django के सत्र ढांचे का उपयोग करके सत्र में उपयोगकर्ता की आईडी बचाता है।

ध्यान दें कि उपयोगकर्ता द्वारा लॉग इन करने के बाद अनाम सत्र के दौरान सेट किया गया कोई भी डेटा सत्र में बनाए रखा जाता है।

यह उदाहरण दिखाता है कि आप authenticate() और login() दोनों का उपयोग कैसे कर सकते हैं:

from django.contrib.auth import authenticate, login

def my_view(request):
    username = request.POST['username']
    password = request.POST['password']
    user = authenticate(request, username=username, password=password)
    if user is not None:
        login(request, user)
        # Redirect to a success page.
        ...
    else:
        # Return an 'invalid login' error message.
        ...

प्रमाणीकरण बैकएंड का चयन करना

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

1. यदि उपलब्ध हो तो वैकल्पिक backend तर्क के मूल्य का उपयोग करें।
2. यदि मौजूद हो तो user.backend विशेषता के मान का उपयोग करें। इससे युग्मित authenticate() और login() : authenticate() उपयोगकर्ता ऑब्जेक्ट पर लौटे उपयोगकर्ता ऑब्जेक्ट को सेट करता है।
3. AUTHENTICATION_BACKENDS में backend उपयोग करें, यदि केवल एक ही है।
4. अन्यथा, एक अपवाद बढ़ाएं।

1 और 2 के मामलों में, backend तर्क या user.backend विशेषता का user.backend एक डॉटेड आयात पथ स्ट्रिंग होना चाहिए (जैसे कि AUTHENTICATION_BACKENDS में पाया गया), न कि वास्तविक बैकेंड वर्ग।

उपयोगकर्ता को कैसे लॉग आउट करें

logout(request) [source]

एक उपयोगकर्ता को लॉग आउट करने के लिए जो login() माध्यम से लॉग इन किया गया है, अपने विचार के भीतर django.contrib.auth.logout() उपयोग करें। यह एक HttpRequest ऑब्जेक्ट लेता है और इसका कोई वापसी मूल्य नहीं है। उदाहरण:

from django.contrib.auth import logout

def logout_view(request):
    logout(request)
    # Redirect to a success page.

ध्यान दें कि यदि उपयोगकर्ता लॉग इन नहीं था तो django.contrib.auth.logout() कोई त्रुटि नहीं करता है।

जब आप django.contrib.auth.logout() , तो वर्तमान अनुरोध का सत्र डेटा पूरी तरह से साफ हो जाता है। सभी मौजूदा डेटा हटा दिए गए हैं। यह किसी अन्य व्यक्ति को लॉग इन करने और पिछले उपयोगकर्ता के सत्र डेटा तक पहुंचने के लिए उसी वेब ब्राउज़र का उपयोग करने से रोकना है। यदि आप सत्र में कुछ भी डालना चाहते हैं जो लॉग आउट करने के तुरंत बाद उपयोगकर्ता के लिए उपलब्ध होगा, तो उसे django.contrib.auth.logout() कॉल करने के बाद करें ।

लॉग-इन उपयोगकर्ताओं तक पहुंच सीमित करना

कच्चा रास्ता

पृष्ठों तक पहुंच को सीमित करने का सरल, कच्चा तरीका is_authenticated जाँच करना है is_authenticated और या तो लॉगिन पृष्ठ पर पुनः निर्देशित करें:

from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

… या त्रुटि संदेश प्रदर्शित करें:

from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated:
        return render(request, 'myapp/login_error.html')
    # ...

login_required डेकोरेटर

login_required(redirect_field_name='next', login_url=None) [source]

शॉर्टकट के रूप में, आप सुविधाजनक login_required() डेकोरेटर का उपयोग कर सकते हैं:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() निम्नलिखित कार्य करता है:

• यदि उपयोगकर्ता लॉग इन नहीं है, तो settings.LOGIN_URL रीडायरेक्ट करें। settings.LOGIN_URL , क्वेरी स्ट्रिंग में वर्तमान निरपेक्ष पथ से गुजर रहा है। उदाहरण: /accounts/login/?next=/polls/3/ ।
• यदि उपयोगकर्ता लॉग इन है, तो दृश्य को सामान्य रूप से निष्पादित करें। उपयोगकर्ता को लॉग इन करने के लिए यह देखने के लिए व्यू कोड मुफ़्त है।

डिफ़ॉल्ट रूप से, उपयोगकर्ता को सफल प्रमाणीकरण पर पुनर्निर्देशित किए जाने वाले पथ को "next" नामक एक क्वेरी स्ट्रिंग पैरामीटर में संग्रहीत किया जाता है। यदि आप इस पैरामीटर के लिए किसी भिन्न नाम का उपयोग करना पसंद करेंगे, तो login_required() एक वैकल्पिक redirect_field_name पैरामीटर लेता है:

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

ध्यान दें कि यदि आप redirect_field_name को मान प्रदान करते हैं, तो आपको अपने लॉगिन टेम्प्लेट को भी कस्टमाइज़ करने की आवश्यकता होगी, क्योंकि टेम्प्लेट के संदर्भ चर जो पुनर्निर्देशित पथ को स्टोर करते हैं, वे रीडायरेक्ट_फ़ील्ड_नाम के मान को उसकी कुंजी के बजाय "next" (डिफ़ॉल्ट) )।

login_required() एक वैकल्पिक login_url पैरामीटर भी लेता है। उदाहरण:

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

ध्यान दें कि यदि आप login_url पैरामीटर निर्दिष्ट नहीं करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता होगी कि settings.LOGIN_URL login_url और आपका लॉगिन दृश्य ठीक से जुड़ा हुआ है। उदाहरण के लिए, चूक का उपयोग करते हुए, निम्नलिखित पंक्तियों को अपने URLconf में जोड़ें:

from django.contrib.auth import views as auth_views

path('accounts/login/', auth_views.LoginView.as_view()),

settings.LOGIN_URL भी फ़ंक्शन नाम और URL पैटर्न नाम को स्वीकार करता है। यह आपको सेटिंग को अपडेट किए बिना अपने URLconf के भीतर अपने लॉगिन दृश्य को स्वतंत्र रूप से हटाने की अनुमति देता है।

LoginRequired

क्लास-आधारित विचारों का उपयोग करते समय , आप LoginRequiredMixin का उपयोग करके login_required के समान व्यवहार प्राप्त कर सकते हैं। यह मिश्रण वंशानुक्रम सूची में सबसे बाएं स्थान पर होना चाहिए।

class LoginRequiredMixin

यदि कोई दृश्य इस मिश्रक का उपयोग कर रहा है, तो गैर-प्रमाणित उपयोगकर्ताओं द्वारा सभी अनुरोधों को लॉगिन पृष्ठ पर पुनर्निर्देशित किया जाएगा या एक HTTP 403 निषिद्ध त्रुटि दिखाई जाएगी, जो कि raise_exception पैरामीटर पर निर्भर करता है।

अनधिकृत उपयोगकर्ताओं की हैंडलिंग को अनुकूलित करने के लिए आप AccessMixin किसी भी पैरामीटर को सेट कर सकते हैं:

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

परीक्षण पास करने वाले लॉग-इन करने वालों तक पहुंच सीमित करना

कुछ अनुमतियों या कुछ अन्य परीक्षण के आधार पर पहुंच को सीमित करने के लिए, आप अनिवार्य रूप से वही काम करेंगे जो पिछले अनुभाग में वर्णित है।

सरल तरीका यह है कि सीधे request.user पर अपना परीक्षण चलाएं। सीधे देखने में। उदाहरण के लिए, यह दृश्य यह सुनिश्चित करने के लिए जांचता है कि उपयोगकर्ता के पास इच्छित डोमेन में एक ईमेल है और यदि नहीं, तो लॉगिन पृष्ठ पर रीडायरेक्ट करता है:

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...

user_passes_test(test_func, login_url=None, redirect_field_name='next') [source]

एक शॉर्टकट के रूप में, आप सुविधाजनक user_passes_test डेकोरेटर का उपयोग कर सकते हैं जो user_passes_test करने योग्य रिटर्न के False होने पर पुनर्निर्देशित करता है:

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

user_passes_test() एक आवश्यक तर्क लेता है: एक user_passes_test() करने योग्य जो User ऑब्जेक्ट लेता है और True यदि उपयोगकर्ता को पृष्ठ देखने की अनुमति है। ध्यान दें कि user_passes_test() स्वचालित रूप से यह जांच नहीं करता है कि User अनाम नहीं है।

user_passes_test() दो वैकल्पिक तर्क लेता है:

login_url

आपको वह URL निर्दिष्ट करने देता है जो परीक्षण पास नहीं करने वाले उपयोगकर्ताओं को पुनर्निर्देशित किया जाएगा। यदि आप एक निर्दिष्ट नहीं करते settings.LOGIN_URL तो यह एक लॉगिन पृष्ठ हो सकता है और settings.LOGIN_URL डिफ़ॉल्ट हो सकता है ।OGIN_URL

redirect_field_name

login_required() । इसे किसी पर सेट करने से इसे URL से हटा दिया जाता है, जिसे आप करना चाहते हैं यदि आप उन उपयोगकर्ताओं को पुनर्निर्देशित कर रहे हैं जो परीक्षण को एक गैर-लॉगिन पृष्ठ पर नहीं भेजते हैं जहां "अगला पृष्ठ" नहीं है।

उदाहरण के लिए:

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...

class UserPassesTestMixin

क्लास-आधारित विचारों का उपयोग करते UserPassesTestMixin , आप ऐसा करने के लिए UserPassesTestMixin का उपयोग कर सकते हैं।

test_func()

आपको परीक्षण प्रदान करने के लिए कक्षा के test_func() विधि को ओवरराइड करना test_func() । इसके अलावा, आप अनधिकृत उपयोगकर्ताओं की हैंडलिंग को अनुकूलित करने के लिए AccessMixin किसी भी पैरामीटर को सेट कर सकते हैं:

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')

get_test_func()

आप get_test_func() को अपनी जाँच के लिए ( test_func() बजाय test_func() एक अलग नाम वाले फ़ंक्शन का उपयोग करने के लिए get_test_func() विधि को ओवरराइड भी कर सकते हैं।

Stacking UserPassesTestMixin

UserPassesTestMixin को लागू करने के तरीके के कारण, आप उन्हें अपनी विरासत सूची में ढेर नहीं कर सकते। निम्नलिखित काम नहीं करता है:

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...

अगर TestMixin1 super() कॉल करेगा super() और उस परिणाम को ध्यान में TestMixin1 , तो TestMixin1 अब स्टैंडअलोन काम नहीं करेगा।

अनुमति_श्रेणी डेकोरेटर

permission_required(perm, login_url=None, raise_exception=False) [source]

यह जांचना एक सामान्य कार्य है कि उपयोगकर्ता की कोई विशेष अनुमति है या नहीं। उस कारण से, Django उस मामले के लिए एक शॉर्टकट प्रदान करता है: permission_required() सज्जाकार:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote')
def my_view(request):
    ...

has_perm() विधि की तरह, अनुमति नाम "<app label>.<permission codename>" (यानी polls आवेदन में एक मॉडल पर अनुमति के लिए polls.can_vote ।

डेकोरेटर अनुमतियों की पुनरावृत्ति भी ले सकता है, जिस स्थिति में उपयोगकर्ता के पास दृश्य को एक्सेस करने के लिए सभी अनुमतियाँ होनी चाहिए।

ध्यान दें कि login_url permission_required() भी एक वैकल्पिक login_url पैरामीटर लेता है:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', login_url='/loginpage/')
def my_view(request):
    ...

जैसे कि login_required() सज्जाकार, login_url settings.LOGIN_URL चूक करता है। login_url ।

यदि raise_exception पैरामीटर दिया गया है, तो सज्जाकार लॉगिन पृष्ठ पर पुनर्निर्देशित करने के बजाय 403 (HTTP निषिद्ध) दृश्य को प्रेरित करते हुए PermissionDenied को बढ़ाएगा।

यदि आप raise_exception का उपयोग करना चाहते हैं, लेकिन अपने उपयोगकर्ताओं को पहले लॉगिन करने का मौका देते हैं, तो आप login_required() डेकोरेटर को जोड़ सकते हैं:

from django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required('polls.can_vote', raise_exception=True)
def my_view(request):
    ...

यह तब भी रीडायरेक्ट लूप से बचा जाता है जब LoginView का redirect_authenticated_user=True और लॉग-इन उपयोगकर्ता के पास सभी आवश्यक अनुमतियां नहीं हैं।

PermissionRequiredMixin मिक्सिन

कक्षा-आधारित विचारों के लिए अनुमति जाँच लागू करने के लिए, आप PermissionRequiredMixin उपयोग कर सकते हैं:

class PermissionRequiredMixin

यह मिक्सचर, अनुमति_प्रकाशित डेकोरेटर की तरह, यह देखता है कि क्या किसी उपयोगकर्ता तक पहुँचने के लिए सभी ने अनुमति दी है। आपको अनुमति_ या permission_required पैरामीटर का उपयोग करके अनुमति (या अनुमतियों का पुनरावृत्ति) निर्दिष्ट करना चाहिए:

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.can_vote'
    # Or multiple of permissions:
    permission_required = ('polls.can_open', 'polls.can_edit')

आप अनधिकृत उपयोगकर्ताओं की हैंडलिंग को अनुकूलित करने के लिए AccessMixin किसी भी पैरामीटर को सेट कर सकते हैं।

आप इन तरीकों को भी ओवरराइड कर सकते हैं:

get_permission_required()

मिक्सर द्वारा उपयोग किए जाने वाले अनुमति नामों का एक पुनरावृत्ति देता है। यदि आवश्यक हो तो अनुमति_अनुरक्षित विशेषता के लिए डिफ़ॉल्ट, एक टपल में परिवर्तित हो जाता है।

has_permission()

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

वर्ग-आधारित विचारों में अनधिकृत अनुरोधों को पुनर्निर्देशित करना

क्लास-आधारित दृश्यों में पहुंच प्रतिबंधों की हैंडलिंग को आसान बनाने के लिए, AccessMixin का उपयोग एक्सेस से वंचित होने पर किसी दृश्य के व्यवहार को कॉन्फ़िगर करने के लिए किया जा सकता है। प्रमाणित उपयोगकर्ताओं को HTTP 403 निषिद्ध प्रतिक्रिया के साथ प्रवेश से वंचित किया जाता है। बेनामी उपयोगकर्ताओं को लॉगिन पृष्ठ पर पुनर्निर्देशित किया जाता है या एक HTTP 403 निषिद्ध प्रतिक्रिया दिखाई जाती है, जो कि raise_exception विशेषता पर निर्भर raise_exception है।

class AccessMixin

login_url

get_login_url() लिए डिफ़ॉल्ट वापसी मान। None मामले में चूक, जिस स्थिति में get_login_url() settings.LOGIN_URL वापस आती है। get_login_url() ।

permission_denied_message

get_permission_denied_message() लिए डिफ़ॉल्ट रिटर्न वैल्यू। एक खाली स्ट्रिंग में चूक।

redirect_field_name

get_redirect_field_name() लिए डिफ़ॉल्ट वापसी मान। "next" लिए चूक।

raise_exception

यदि यह विशेषता True सेट है, तो शर्तों को पूरा नहीं करने पर PermissionDenied अपवाद उठाया जाता है। जब False (डिफ़ॉल्ट), अनाम उपयोगकर्ता लॉगिन पृष्ठ पर पुनः निर्देशित कर दिए जाते हैं।

get_login_url()

वह URL लौटाता है जो परीक्षण पास नहीं करने वाले उपयोगकर्ताओं को पुनर्निर्देशित किया जाएगा। यदि सेट, या settings.LOGIN_URL login_url लौटाता है। अन्यथा login_url ।

get_permission_denied_message()

जब raise_exception True , तो इस विधि का उपयोग उपयोगकर्ता को प्रदर्शन के लिए त्रुटि हैंडलर को दिए गए त्रुटि संदेश को नियंत्रित करने के लिए किया जा सकता है। डिफ़ॉल्ट रूप से permission_denied_message विशेषता देता है।

get_redirect_field_name()

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

handle_no_permission()

raise_exception के मान के आधार पर, विधि या तो एक PermissionDenied अपवाद को उठाती है या उपयोगकर्ता को login_url पर redirect_field_name यदि यह सेट है तो वैकल्पिक रूप से redirect_field_name सहित।

पासवर्ड बदलने पर सत्र अमान्य है

यदि आपका AUTH_USER_MODEL AbstractBaseUser से इनहेरिट करता है या अपने स्वयं के get_session_auth_hash() विधि को लागू करता है, तो प्रमाणित सत्र में इस फ़ंक्शन द्वारा दिए गए हैश शामिल होंगे। AbstractBaseUser मामले में, यह पासवर्ड फ़ील्ड का HMAC है। Django सत्यापित करता है कि प्रत्येक अनुरोध के लिए सत्र में हैश अनुरोध के दौरान गणना की गई है। यह उपयोगकर्ता को अपना पासवर्ड बदलकर अपने सभी सत्रों को लॉग आउट करने की अनुमति देता है।

Django, PasswordChangeView और django.contrib.auth व्यवस्थापक में user_change_password दृश्य के साथ शामिल डिफ़ॉल्ट पासवर्ड परिवर्तन दृश्य, नए पासवर्ड हैश के साथ सत्र को अपडेट करें ताकि अपना पासवर्ड बदलने वाला उपयोगकर्ता लॉग आउट न हो। यदि आपके पास एक कस्टम पासवर्ड परिवर्तन दृश्य है और समान व्यवहार करने की इच्छा है, तो update_session_auth_hash() फ़ंक्शन का उपयोग करें।

update_session_auth_hash(request, user) [source]

यह फ़ंक्शन वर्तमान अनुरोध और अद्यतन उपयोगकर्ता ऑब्जेक्ट लेता है जिसमें से नया सत्र हैश निकाला जाएगा और सत्र हैश को उचित रूप से अपडेट करेगा। यह सत्र कुंजी भी घुमाता है ताकि एक चोरी सत्र कुकी अमान्य हो जाए।

उदाहरण का उपयोग:

from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

प्रमाणीकरण दृश्य

Django कई विचार प्रदान करता है जिनका उपयोग आप लॉगिन, लॉगआउट और पासवर्ड प्रबंधन से निपटने के लिए कर सकते हैं। ये forms का उपयोग करते forms लेकिन आप अपने स्वयं के फॉर्म में भी पास कर सकते हैं।

Django प्रमाणीकरण विचारों के लिए कोई डिफ़ॉल्ट टेम्पलेट प्रदान करता है। आप जिन विचारों का उपयोग करना चाहते हैं, उनके लिए आपको अपने स्वयं के टेम्पलेट बनाने चाहिए। टेम्पलेट संदर्भ प्रत्येक दृश्य में प्रलेखित है, सभी प्रमाणीकरण दृश्य देखें।

विचारों का उपयोग करना

आपकी परियोजना में इन विचारों को लागू करने के लिए अलग-अलग तरीके हैं। सबसे आसान तरीका है, उदाहरण के लिए अपने खुद के URLconf में django.contrib.auth.urls में django.contrib.auth.urls गए URL URL को शामिल करना:

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]

इसमें निम्नलिखित URL पैटर्न शामिल होंगे:

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

विचार आसान संदर्भ के लिए एक URL नाम प्रदान करते हैं। नामित URL पैटर्न का उपयोग करने के विवरण के लिए URL दस्तावेज़ देखें।

यदि आप अपने URL पर अधिक नियंत्रण चाहते हैं, तो आप अपने URLconf में एक विशिष्ट दृश्य का संदर्भ ले सकते हैं:

from django.contrib.auth import views as auth_views

urlpatterns = [
    path('change-password/', auth_views.PasswordChangeView.as_view()),
]

दृश्य में वैकल्पिक तर्क होते हैं जिनका उपयोग आप दृश्य के व्यवहार को बदलने के लिए कर सकते हैं। उदाहरण के लिए, यदि आप किसी उपयोग के लिए टेम्पलेट नाम बदलना चाहते हैं, तो आप template_name तर्क प्रदान कर सकते हैं। ऐसा करने का एक तरीका URLconf में कीवर्ड तर्क देना है, इन्हें व्यू पर पास किया जाएगा। उदाहरण के लिए:

urlpatterns = [
    path(
        'change-password/',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]

सभी दृश्य वर्ग-आधारित हैं , जो आपको उपवर्ग द्वारा आसानी से उन्हें अनुकूलित करने की अनुमति देता है।

सभी प्रमाणीकरण विचार

यह एक सूची है जिसमें सभी विचार django.contrib.auth प्रदान करता है। कार्यान्वयन विवरण के लिए , विचारों का उपयोग करना देखें।

class LoginView

URL नाम: login

नामित URL पैटर्न का उपयोग करने के विवरण के लिए URL दस्तावेज़ देखें।

गुण:

• template_name : उपयोगकर्ता को लॉग इन करने के लिए उपयोग किए जाने वाले दृश्य को प्रदर्शित करने के लिए एक टेम्प्लेट का नाम। registration/login.html लिए डिफ़ॉल्ट।
• redirect_field_name : लॉगिन के बाद रीडायरेक्ट करने के लिए URL वाले GET फ़ील्ड का नाम। next करने के लिए चूक।
• authentication_form : authentication_form लिए उपयोग करने के लिए एक कॉल करने योग्य (आमतौर पर सिर्फ एक फॉर्म क्लास)। AuthenticationForm लिए चूक।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

• redirect_authenticated_user : एक बूलियन जो यह नियंत्रित करता है कि लॉगिन पृष्ठ तक पहुँचने वाले प्रमाणित उपयोगकर्ता हैं या नहीं, उन्हें पुनर्निर्देशित किया जाएगा जैसे कि उन्होंने अभी-अभी सफलतापूर्वक लॉग इन किया था। डिफ़ॉल्ट के लिए False ।

  चेतावनी

  यदि आप redirect_authenticated_user सक्षम करते हैं, तो अन्य वेबसाइट यह निर्धारित कर सकेंगी कि क्या आपके विज़िटर आपकी वेबसाइट पर छवि फ़ाइलों के लिए रीडायरेक्ट URL का अनुरोध करके आपकी साइट पर प्रमाणित हैं। इस " सोशल मीडिया फ़िंगरप्रिंटिंग " सूचना के रिसाव से बचने के लिए, सभी छवियों और अपने फ़ेविकॉन को एक अलग डोमेन पर होस्ट करें।

  raise_exception सक्षम करने से redirect_authenticated_user लूप का उपयोग तब भी redirect_authenticated_user जा सकता है जब raise_exception permission_required() डेकोरेटर का उपयोग किया जाता है जब तक कि raise_exception पैरामीटर का उपयोग नहीं किया जाता है।

• success_url_allowed_hosts : request.get_host() अलावा, होस्ट का एक set , जो लॉगिन के बाद पुनर्निर्देशित करने के लिए सुरक्षित हैं। खाली set लिए चूक।

यहाँ क्या LoginView करता है:

• यदि इसे GET माध्यम से कहा जाता है, तो यह एक लॉगिन फ़ॉर्म प्रदर्शित करता है जो POST के समान URL पर होता है। इस पर थोड़ा और अधिक।
• यदि उपयोगकर्ता द्वारा प्रस्तुत क्रेडेंशियल के साथ POST माध्यम से कॉल किया जाता है, तो यह उपयोगकर्ता को लॉग इन करने की कोशिश करता है। यदि लॉगिन सफल होता है, तो दृश्य next में निर्दिष्ट URL पर रीडायरेक्ट करता है। यदि next प्रदान नहीं किया गया है, तो यह settings.LOGIN_REDIRECT_URL रीडायरेक्ट करता है। settings.LOGIN_REDIRECT_URL (जो कि /accounts/profile/ चूक करता है)। यदि लॉगिन सफल नहीं है, तो यह लॉगिन फ़ॉर्म को फिर से खोल देता है।

डिफ़ॉल्ट रूप से registration/login.html नामक लॉगिन टेम्प्लेट के लिए html प्रदान करना आपकी ज़िम्मेदारी है। यह टेम्प्लेट चार टेम्प्लेट संदर्भ संदर्भ चर पास करता है:

• form : AuthenticationForm प्रतिनिधित्व करने वाला एक Form ऑब्जेक्ट।
• next : सफल लॉगिन के बाद रीडायरेक्ट करने वाला URL। इसमें क्वेरी स्ट्रिंग भी हो सकती है।
• site : वर्तमान Site , SITE_ID सेटिंग के अनुसार । यदि आपके पास साइट फ्रेमवर्क स्थापित नहीं है, तो यह एक उदाहरण के लिए सेट किया जाएगा RequestSite , जो साइट के नाम और डोमेन को वर्तमान से प्राप्त करता है HttpRequest ।
• site_name : के लिए एक उपनाम site.name । यदि आपके पास साइट ढांचा स्थापित नहीं है, तो इसके मूल्य पर सेट किया जाएगा request.META['SERVER_NAME'] । साइटों के बारे में अधिक जानकारी के लिए, "साइटों" की रूपरेखा देखें ।

यदि आप टेम्पलेट को कॉल नहीं करना चाहते हैं registration/login.html , तो आप अपने URLconf में विधि के template_name लिए अतिरिक्त तर्कों के माध्यम से पैरामीटर पास कर सकते हैं as_view । उदाहरण के लिए, यह URLconf लाइन myapp/login.html इसके बजाय उपयोग करेगी :

path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),

आप उस GET क्षेत्र का नाम भी बता सकते हैं जिसमें लॉगिन का उपयोग करने के बाद URL को पुनर्निर्देशित करना शामिल है redirect_field_name । डिफ़ॉल्ट रूप से, फ़ील्ड कहा जाता है next ।

यहां एक नमूना registration/login.html टेम्प्लेट है जिसे आप शुरुआती बिंदु के रूप में उपयोग कर सकते हैं। यह मानता है कि आपके पास एक base.html टेम्पलेट है जो एक content ब्लॉक को परिभाषित करता है :

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

आप प्रमाणीकरण कस्टमाइज़ कर लिया है (देखें अनुकूलित प्रमाणीकरण ) आप की स्थापना करके एक कस्टम प्रमाणीकरण का उपयोग कर सकते authentication_form विशेषता। इस फॉर्म को request अपनी __init__() विधि में एक कीवर्ड तर्क को स्वीकार करना चाहिए और एक get_user() विधि प्रदान करनी चाहिए जो प्रामाणिक उपयोगकर्ता ऑब्जेक्ट लौटाती है (यह विधि केवल कभी सफल फॉर्म सत्यापन के बाद कहा जाता है)।

class LogoutView

किसी उपयोगकर्ता को लॉग आउट करता है।

URL का नाम: logout

गुण:

• next_page : लॉगआउट के बाद रीडायरेक्ट करने वाला URL। के लिए चूक settings.LOGOUT_REDIRECT_URL ।
• template_name : उपयोगकर्ता को लॉग आउट करने के बाद प्रदर्शित करने के लिए टेम्पलेट का पूरा नाम। के लिए चूक registration/logged_out.html ।
• redirect_field_name : GET लॉग आउट के बाद रीडायरेक्ट करने के लिए URL वाले फ़ील्ड का नाम । के लिए चूक next । next_page यदि दिए गए GET पैरामीटर को पारित किया जाता है तो URL को ओवरराइड करता है।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।
• success_url_allowed_hosts : ए set , मेजबानों के अलावा request.get_host() , जो लॉगआउट के बाद पुनर्निर्देशन के लिए सुरक्षित हैं। एक खाली करने के लिए चूक set ।

खाका संदर्भ:

• title : स्ट्रिंग "लॉग आउट", स्थानीयकृत।
• site : वर्तमान Site , SITE_ID सेटिंग के अनुसार । यदि आपके पास साइट फ्रेमवर्क स्थापित नहीं है, तो यह एक उदाहरण के लिए सेट किया जाएगा RequestSite , जो साइट के नाम और डोमेन को वर्तमान से प्राप्त करता है HttpRequest ।
• site_name : के लिए एक उपनाम site.name । यदि आपके पास साइट ढांचा स्थापित नहीं है, तो इसके मूल्य पर सेट किया जाएगा request.META['SERVER_NAME'] । साइटों के बारे में अधिक जानकारी के लिए, "साइटों" की रूपरेखा देखें ।

logout_then_login(request, login_url=None)

किसी उपयोगकर्ता को लॉग आउट करता है, फिर लॉगिन पृष्ठ पर रीडायरेक्ट करता है।

URL का नाम: कोई डिफ़ॉल्ट URL प्रदान नहीं किया गया है

वैकल्पिक तर्क:

• login_url : लॉगिन पृष्ठ का URL पुनर्निर्देशित करने के लिए। settings.LOGIN_URL आपूर्ति न होने पर चूक ।

class PasswordChangeView

URL का नाम: password_change

उपयोगकर्ता को अपना पासवर्ड बदलने की अनुमति देता है।

गुण:

• template_name : पासवर्ड परिवर्तन फ़ॉर्म प्रदर्शित करने के लिए उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_change_form.html आपूर्ति न होने पर चूक ।
• success_url : सफल पासवर्ड बदलने के बाद URL पुनर्निर्देशित करना।
• form_class : एक कस्टम "पासवर्ड बदलें" फ़ॉर्म जिसे एक user कीवर्ड तर्क को स्वीकार करना चाहिए । प्रपत्र वास्तव में उपयोगकर्ता के पासवर्ड को बदलने के लिए जिम्मेदार है। के लिए चूक PasswordChangeForm ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

खाका संदर्भ:

• form : पासवर्ड परिवर्तन फ़ॉर्म ( form_class ऊपर देखें )।

class PasswordChangeDoneView

URL का नाम: password_change_done

किसी उपयोगकर्ता द्वारा अपना पासवर्ड बदलने के बाद दिखाया गया पृष्ठ।

गुण:

• template_name : उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_change_done.html आपूर्ति न होने पर चूक ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

class PasswordResetView

URL का नाम: password_reset

उपयोगकर्ता को पासवर्ड रीसेट करने के लिए उपयोग किए जा सकने वाले वन-टाइम यूज़ लिंक को जनरेट करके अपने पासवर्ड को रीसेट करने की अनुमति देता है और उस लिंक को उपयोगकर्ता के पंजीकृत ईमेल पते पर भेज देता है।

यदि प्रदान किया गया ईमेल पता सिस्टम में मौजूद नहीं है, तो यह दृश्य ईमेल नहीं भेजेगा, लेकिन उपयोगकर्ता को कोई भी त्रुटि संदेश प्राप्त नहीं होगा। यह संभावित हमलावरों को सूचना लीक करने से रोकता है। यदि आप इस मामले में कोई त्रुटि संदेश देना चाहते हैं, तो आप विशेषता को उप-वर्ग PasswordResetForm और उपयोग कर सकते हैं form_class ।

उपयोगकर्ताओं को एक अनुपयोगी पासवर्ड के साथ चिह्नित किया गया (देखें set_unusable_password() कि LDAP जैसे बाहरी प्रमाणीकरण स्रोत का उपयोग करते समय दुरुपयोग को रोकने के लिए पासवर्ड रीसेट का अनुरोध करने की अनुमति नहीं है। ध्यान दें कि उन्हें कोई त्रुटि संदेश प्राप्त नहीं होगा क्योंकि यह उनके खाते के अस्तित्व को उजागर करेगा लेकिन कोई मेल नहीं होगा। या तो भेजा जाए।

गुण:

• template_name : पासवर्ड रीसेट फॉर्म प्रदर्शित करने के लिए उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_reset_form.html आपूर्ति न होने पर चूक ।
• form_class : वह फ़ॉर्म जिसका उपयोग उपयोगकर्ता के ईमेल को पासवर्ड रीसेट करने के लिए प्राप्त करने के लिए किया जाएगा। के लिए चूक PasswordResetForm ।
• email_template_name : रीसेट पासवर्ड लिंक के साथ ईमेल बनाने के लिए उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_reset_email.html आपूर्ति न होने पर चूक ।
• subject_template_name : रीसेट पासवर्ड लिंक के साथ ईमेल के विषय के लिए उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_reset_subject.txt आपूर्ति न होने पर चूक ।
• token_generator : वन टाइम लिंक की जाँच करने के लिए कक्षा का उदाहरण। यह डिफ़ॉल्ट होगा default_token_generator , यह एक उदाहरण है django.contrib.auth.tokens.PasswordResetTokenGenerator ।
• success_url : URL एक सफल पासवर्ड रीसेट अनुरोध के बाद पुनर्निर्देशित करने के लिए।
• from_email : एक मान्य ईमेल पता। डिफ़ॉल्ट रूप से Django का उपयोग करता है DEFAULT_FROM_EMAIL ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।
• html_email_template_name : text/html पासवर्ड रीसेट लिंक के साथ एक मल्टीपार्ट ईमेल बनाने के लिए उपयोग करने के लिए एक टेम्पलेट का पूरा नाम । डिफ़ॉल्ट रूप से, HTML ईमेल नहीं भेजा जाता है।
• extra_email_context : संदर्भ डेटा का एक शब्दकोश जो ईमेल टेम्पलेट में उपलब्ध होगा।

खाका संदर्भ:

• form : form_class उपयोगकर्ता का पासवर्ड रीसेट करने के लिए फ़ॉर्म ( ऊपर देखें )।

ईमेल टेम्प्लेट संदर्भ:

• email : के लिए एक उपनाम user.email
• user : वर्तमान User , email प्रपत्र फ़ील्ड के अनुसार । केवल सक्रिय उपयोगकर्ता ही अपने पासवर्ड को रीसेट करने में सक्षम हैं ( User.is_active is True )।
• site_name : के लिए एक उपनाम site.name । यदि आपके पास साइट ढांचा स्थापित नहीं है, तो इसके मूल्य पर सेट किया जाएगा request.META['SERVER_NAME'] । साइटों के बारे में अधिक जानकारी के लिए, "साइटों" की रूपरेखा देखें ।
• domain : के लिए एक उपनाम site.domain । यदि आपके पास साइट ढांचा स्थापित नहीं है, तो इसके मूल्य पर सेट किया जाएगा request.get_host() ।
• protocol : http या https
• uid : उपयोगकर्ता की प्राथमिक कुंजी 64 बेस में एन्कोडेड है।
• token : यह जांचने के लिए कि रीसेट लिंक वैध है।

नमूना registration/password_reset_email.html (ईमेल शरीर टेम्पलेट):

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

विषय टेम्पलेट के लिए एक ही टेम्पलेट संदर्भ का उपयोग किया जाता है। विषय सिंगल लाइन प्लेन टेक्स्ट स्ट्रिंग होना चाहिए।

class PasswordResetDoneView

URL का नाम: password_reset_done

उपयोगकर्ता द्वारा अपना पासवर्ड रीसेट करने के लिए एक लिंक ईमेल किए जाने के बाद दिखाया गया पृष्ठ। यदि PasswordResetView स्पष्ट success_url URL सेट नहीं है, तो यह दृश्य डिफ़ॉल्ट रूप से कहा जाता है ।

ध्यान दें

यदि प्रदान किया गया ईमेल पता सिस्टम में मौजूद नहीं है, तो उपयोगकर्ता निष्क्रिय है, या उसके पास एक अनुपयोगी पासवर्ड है, फिर भी उपयोगकर्ता को इस दृश्य पर पुनर्निर्देशित किया जाएगा लेकिन कोई ईमेल नहीं भेजा जाएगा

गुण:

• template_name : उपयोग करने के लिए एक टेम्पलेट का पूरा नाम। registration/password_reset_done.html आपूर्ति न होने पर चूक ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

class PasswordResetConfirmView

URL का नाम: password_reset_confirm

एक नया पासवर्ड दर्ज करने के लिए एक फार्म प्रस्तुत करता है।

URL से कीवर्ड तर्क:

• uidb64 : उपयोगकर्ता की आईडी आधार 64 में कूटबद्ध की गई।
• token : यह जाँचने के लिए कि पासवर्ड मान्य है।

गुण:

• template_name : पुष्टिकरण पासवर्ड दृश्य प्रदर्शित करने के लिए एक टेम्पलेट का पूरा नाम। डिफ़ॉल्ट मान है registration/password_reset_confirm.html ।
• token_generator : पासवर्ड जाँचने के लिए कक्षा का उदाहरण। यह डिफ़ॉल्ट होगा default_token_generator , यह एक उदाहरण है django.contrib.auth.tokens.PasswordResetTokenGenerator ।
• post_reset_login : एक बूलियन इंगित करता है कि उपयोगकर्ता को एक सफल पासवर्ड रीसेट के बाद स्वचालित रूप से प्रमाणित किया जाना चाहिए। False करने के लिए चूक।
• post_reset_login_backend : प्रमाणीकरण करने के लिए एक बिंदीदार पथ एक उपयोगकर्ता को प्रमाणित करते समय उपयोग करने के लिए बैकएंड करता post_reset_login है True । यदि आपके पास कई AUTHENTICATION_BACKENDS कॉन्फ़िगर किए गए हैं, केवल आवश्यक है। के लिए चूक None ।
• form_class : वह फ़ॉर्म जिसका उपयोग पासवर्ड सेट करने के लिए किया जाएगा। के लिए चूक SetPasswordForm ।
• success_url : पासवर्ड रीसेट होने के बाद URL पुनर्निर्देशित। के लिए चूक 'password_reset_complete' ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

खाका संदर्भ:

• form : set_password_form नए उपयोगकर्ता का पासवर्ड सेट करने के लिए फ़ॉर्म ( ऊपर देखें )।
• validlink : बूलियन, सच है अगर लिंक (का संयोजन uidb64 और token ) अभी तक वैध या अप्रयुक्त है।

class PasswordResetCompleteView

URL का नाम: password_reset_complete

एक दृश्य प्रस्तुत करता है जो उपयोगकर्ता को सूचित करता है कि पासवर्ड सफलतापूर्वक बदल दिया गया है।

गुण:

• template_name : दृश्य प्रदर्शित करने के लिए एक टेम्पलेट का पूरा नाम। के लिए चूक registration/password_reset_complete.html ।
• extra_context : संदर्भ डेटा का एक शब्दकोश जिसे टेम्पलेट में पारित डिफ़ॉल्ट संदर्भ डेटा में जोड़ा जाएगा।

हेल्पर कार्य करता है

redirect_to_login(next, login_url=None, redirect_field_name='next')

लॉगिन पृष्ठ पर पुनर्निर्देशित करता है, और फिर एक सफल लॉगिन के बाद दूसरे URL पर वापस जाता है।

आवश्यक तर्क:

• next : सफल लॉगिन के बाद URL पुनर्निर्देशित करना।

वैकल्पिक तर्क:

• login_url : लॉगिन पृष्ठ का URL पुनर्निर्देशित करने के लिए। settings.LOGIN_URL आपूर्ति न होने पर चूक ।
• redirect_field_name : GET लॉग आउट के बाद रीडायरेक्ट करने के लिए URL वाले फ़ील्ड का नाम । next यदि दिए गए GET पैरामीटर को पारित किया जाता है तो ओवरराइड करता है।

बिल्ट-इन फॉर्म

यदि आप बिल्ट-इन विचारों का उपयोग नहीं करना चाहते हैं, लेकिन इस कार्यक्षमता के लिए फ़ॉर्म नहीं लिखने की सुविधा चाहते हैं, तो प्रमाणीकरण प्रणाली कई अंतर्निहित रूपों को प्रदान करती है django.contrib.auth.forms :

class AdminPasswordChangeForm

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

user पहले स्थितीय तर्क के रूप में लेता है।

class AuthenticationForm

उपयोगकर्ता को लॉग इन करने के लिए एक फ़ॉर्म।

request अपने पहले स्थितीय तर्क के रूप में लेता है, जिसे उप-वर्गों द्वारा उपयोग के लिए प्रपत्र उदाहरण पर संग्रहीत किया जाता है।

confirm_login_allowed(user)

डिफ़ॉल्ट रूप से, AuthenticationForm उन उपयोगकर्ताओं को अस्वीकार करता है, जिनका is_active झंडा सेट है False । आप यह निर्धारित करने के लिए कस्टम नीति के साथ इस व्यवहार को ओवरराइड कर सकते हैं कि कौन से उपयोगकर्ता लॉग इन कर सकते हैं। कस्टम फॉर्म के साथ ऐसा करें AuthenticationForm जो confirm_login_allowed() विधि को उप-विभाजित करता है और ओवरराइड करता है। ValidationError यदि उपयोगकर्ता दिए गए लॉग इन नहीं कर सकता है तो इस विधि को उठाना चाहिए ।

उदाहरण के लिए, सभी उपयोगकर्ताओं को "सक्रिय" स्थिति की परवाह किए बिना लॉग इन करने की अनुमति देने के लिए:

from django.contrib.auth.forms import AuthenticationForm

class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
    def confirm_login_allowed(self, user):
        pass

(इस मामले में, आपको एक प्रमाणीकरण बैकएंड का उपयोग करने की आवश्यकता होगी जो निष्क्रिय उपयोगकर्ताओं को अनुमति देता है, जैसे कि AllowAllUsersModelBackend ।)

या केवल कुछ सक्रिय उपयोगकर्ताओं को लॉग इन करने की अनुमति देने के लिए:

class PickyAuthenticationForm(AuthenticationForm):
    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise forms.ValidationError(
                _("This account is inactive."),
                code='inactive',
            )
        if user.username.startswith('b'):
            raise forms.ValidationError(
                _("Sorry, accounts starting with 'b' aren't welcome here."),
                code='no_b_users',
            )

class PasswordChangeForm

उपयोगकर्ता को अपना पासवर्ड बदलने की अनुमति देने के लिए एक फ़ॉर्म।

class PasswordResetForm

उपयोगकर्ता के पासवर्ड को रीसेट करने के लिए एक बार उपयोग लिंक बनाने और ईमेल करने के लिए एक फॉर्म।

send_mail(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)

एक भेजने के लिए तर्कों का उपयोग करता है EmailMultiAlternatives । उपयोगकर्ता को ईमेल कैसे भेजा जाता है, इसे कस्टमाइज़ करने के लिए ओवरराइड किया जा सकता है।

पैरामीटर:	subject_template_name - विषय के लिए टेम्पलेट। email_template_name - ईमेल निकाय का खाका। संदर्भ - संदर्भ के लिए पारित किया subject_template , email_template और html_email_template (अगर यह नहीं है None )। from_email - प्रेषक का ईमेल। to_email - अनुरोधकर्ता का ईमेल। HTML_email_template_name - HTML निकाय के लिए टेम्पलेट; चूक None , जिस स्थिति में एक सादा पाठ ईमेल भेजा जाता है।

डिफ़ॉल्ट रूप से, उसी चर save() के context साथ पॉप्युलेट होता है जो PasswordResetView इसके ईमेल संदर्भ में पास होता है।

class SetPasswordForm

ऐसा फ़ॉर्म जो उपयोगकर्ता को पुराने पासवर्ड को दर्ज किए बिना अपना पासवर्ड बदलने देता है।

class UserChangeForm

उपयोगकर्ता की जानकारी और अनुमतियाँ बदलने के लिए व्यवस्थापक इंटरफ़ेस में उपयोग किया जाने वाला फ़ॉर्म।

class UserCreationForm

एक ModelForm नया उपयोगकर्ता बनाने के लिए।

इसके तीन क्षेत्र हैं: username (उपयोगकर्ता मॉडल से) password1 , और password2 । यह सत्यापित करता है कि password1 और password2 मिलान करता है , पासवर्ड का उपयोग करके सत्यापन करता है validate_password() , और उपयोगकर्ता के पासवर्ड का उपयोग करके सेट करता है set_password() ।

टेम्पलेट्स में प्रमाणीकरण डेटा

वर्तमान में लॉग-इन किए गए उपयोगकर्ता और उनकी अनुमतियाँ टेम्पलेट संदर्भ में उपलब्ध हैं जब आप उपयोग करते हैं RequestContext ।

उपयोगकर्ता

किसी टेम्प्लेट को प्रस्तुत करते समय RequestContext , वर्तमान में लॉग-इन उपयोगकर्ता, या तो एक User उदाहरण या एक AnonymousUser उदाहरण, टेम्पलेट चर में संग्रहीत किया जाता है {{ user }} :

{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}

यदि RequestContext इसका उपयोग नहीं किया जा रहा है तो यह टेम्प्लेट संदर्भ संदर्भ चर उपलब्ध नहीं है।

अनुमतियां

वर्तमान में लॉग-इन उपयोगकर्ता की अनुमतियाँ टेम्पलेट चर में संग्रहीत हैं {{ perms }} । यह एक उदाहरण है django.contrib.auth.context_processors.PermWrapper , जो अनुमतियों का टेम्पलेट-फ्रेंडली प्रॉक्सी है।

{{ perms }} एक बूलियन के रूप में एकल-विशेषता लुकअप का मूल्यांकन एक प्रॉक्सी है User.has_module_perms() । उदाहरण के लिए, यह जांचने के लिए कि लॉग-इन उपयोगकर्ता के पास foo ऐप में कोई अनुमति है या नहीं :

{% if perms.foo %}

बूलियन के रूप में दो-स्तरीय-विशेषता लुकअप का मूल्यांकन एक प्रॉक्सी है has_perm() । उदाहरण के लिए, यह जांचने के लिए कि लॉग-इन उपयोगकर्ता के पास अनुमति है foo.can_vote :

{% if perms.foo.can_vote %}

यहां टेम्प्लेट में अनुमतियों की जांच करने का एक और पूरा उदाहरण दिया गया है:

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.can_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.can_drive %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}

{% if in %} बयानों द्वारा अनुमतियों को देखना भी संभव है । उदाहरण के लिए:

{% if 'foo' in perms %}
    {% if 'foo.can_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}

व्यवस्थापक में उपयोगकर्ताओं को प्रबंधित करना

जब आपके पास दोनों स्थापित django.contrib.admin और django.contrib.auth स्थापित होते हैं, तो व्यवस्थापक उपयोगकर्ताओं, समूहों और अनुमतियों को देखने और प्रबंधित करने का एक सुविधाजनक तरीका प्रदान करता है। उपयोगकर्ताओं को किसी भी Django मॉडल की तरह बनाया और हटाया जा सकता है। समूह बनाए जा सकते हैं, और अनुमतियाँ उपयोगकर्ताओं या समूहों को सौंपी जा सकती हैं। व्यवस्थापक के भीतर बनाए गए मॉडल में उपयोगकर्ता के लॉग का संग्रह भी संग्रहीत और प्रदर्शित किया जाता है।

उपयोगकर्ता बनाना

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

यह भी ध्यान दें: यदि आप चाहते हैं कि कोई उपयोगकर्ता खाता Django व्यवस्थापक साइट का उपयोग करके उपयोगकर्ता बना सके, तो आपको उन्हें उपयोगकर्ता जोड़ने और उपयोगकर्ता बदलने की अनुमति देने की आवश्यकता होगी (अर्थात, "उपयोगकर्ता जोड़ें" और "उपयोगकर्ता बदलें" अनुमतियां) । यदि किसी खाते में उपयोगकर्ताओं को जोड़ने की अनुमति है, लेकिन उन्हें बदलने के लिए नहीं, तो वह खाता उपयोगकर्ताओं को जोड़ने में सक्षम नहीं होगा। क्यूं कर? क्योंकि यदि आपके पास उपयोगकर्ताओं को जोड़ने की अनुमति है, तो आपके पास सुपरयूज़र बनाने की शक्ति है, जो तब, अन्य उपयोगकर्ताओं को बदल सकते हैं। इसलिए Django को मामूली सुरक्षा उपाय के रूप में अनुमति और परिवर्तन की आवश्यकता होती है ।

इस बारे में विचारशील रहें कि आप उपयोगकर्ताओं को अनुमतियाँ प्रबंधित करने की अनुमति कैसे देते हैं। यदि आप एक गैर-सुपरयुसर को उपयोगकर्ताओं को संपादित करने की क्षमता देते हैं, तो यह अंततः उन्हें सुपरयुजर का दर्जा देने के समान है क्योंकि वे स्वयं सहित उपयोगकर्ताओं की अनुमतियों को ऊपर उठाने में सक्षम होंगे!

पासवर्ड बदलना

उपयोगकर्ता पासवर्ड व्यवस्थापक में प्रदर्शित नहीं होते हैं (न ही डेटाबेस में संग्रहीत), लेकिन पासवर्ड भंडारण विवरण प्रदर्शित होते हैं। इस जानकारी के प्रदर्शन में शामिल है एक पासवर्ड परिवर्तन फ़ॉर्म का लिंक जो उपयोगकर्ता पासवर्ड को बदलने के लिए अनुमति देता है।