सत्र का उपयोग कैसे करें

Django गुमनाम सत्रों के लिए पूर्ण समर्थन प्रदान करता है। सत्र की रूपरेखा आपको प्रति-साइट-विज़िटर के आधार पर मनमाने डेटा को संग्रहीत करने और पुनः प्राप्त करने देती है। यह सर्वर साइड पर डेटा स्टोर करता है और कुकीज़ भेजने और प्राप्त करने का सार करता है। कुकीज़ में एक सत्र ID होती है - स्वयं डेटा नहीं (जब तक आप कुकी आधारित बैकएंड का उपयोग नहीं कर रहे हैं)।

सत्र को सक्षम करना

सत्र middleware एक टुकड़े के माध्यम से कार्यान्वित किए जाते हैं।

सत्र कार्यक्षमता को सक्षम करने के लिए, निम्न कार्य करें:

• MIDDLEWARE सेटिंग को संपादित करें और सुनिश्चित करें कि इसमें 'django.contrib.sessions.middleware.SessionMiddleware' । django-admin startproject द्वारा बनाई गई डिफ़ॉल्ट django-admin startproject में SessionMiddleware सक्रिय है।

यदि आप सत्र का उपयोग नहीं करना चाहते हैं, तो आप अपने INSTALLED_APPS से MIDDLEWARE से SessionMiddleware लाइन और 'django.contrib.sessions' हटा सकते हैं। यह आपको ओवरहेड का एक छोटा सा बचा लेगा।

सत्र इंजन को कॉन्फ़िगर करना

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

डेटाबेस समर्थित सत्रों का उपयोग करना

यदि आप डेटाबेस-समर्थित सत्र का उपयोग करना चाहते हैं, तो आपको अपनी INSTALLED_APPS सेटिंग में 'django.contrib.sessions' जोड़ना होगा।

एक बार जब आप अपनी स्थापना को कॉन्फ़िगर कर लेते हैं, तो सत्र डेटा संग्रहीत करने वाली एकल डेटाबेस तालिका को स्थापित करने के लिए manage.py migrate चलाएँ।

कैश्ड सत्रों का उपयोग करना

बेहतर प्रदर्शन के लिए, आप कैश-आधारित सत्र बैकएंड का उपयोग करना चाह सकते हैं।

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

यदि आपके पास CACHES में एकाधिक कैश परिभाषित हैं, तो Django डिफ़ॉल्ट कैश का उपयोग करेगा। किसी अन्य कैश का उपयोग करने के लिए, SESSION_CACHE_ALIAS को उस कैश के नाम पर सेट करें।

एक बार जब आपका कैश कॉन्फ़िगर हो जाता है, तो आपके पास कैश में डेटा को स्टोर करने के दो विकल्प हैं:

• एक साधारण कैशिंग सत्र स्टोर के लिए "django.contrib.sessions.backends.cache" SESSION_ENGINE सेट करें। सत्र डेटा सीधे आपके कैश में संग्रहीत किया जाएगा। हालाँकि, सत्र डेटा लगातार नहीं हो सकता है: कैश्ड डेटा को निकाला जा सकता है यदि कैश भरता है या यदि कैश सर्वर पुनरारंभ होता है।
• लगातार, कैश्ड डेटा के लिए, SESSION_ENGINE को "django.contrib.sessions.backends.cached_db" सेट करें। यह राइट-थ्रू कैश का उपयोग करता है - हर राइट टू कैश भी डेटाबेस को लिखा जाएगा। यदि डेटा पहले से कैश में नहीं है, तो सत्र केवल डेटाबेस का उपयोग करता है।

दोनों सत्र स्टोर काफी तेज हैं, लेकिन सरल कैश तेज है क्योंकि यह दृढ़ता की अवहेलना करता है। ज्यादातर मामलों में, cached_db बैकएंड काफी तेजी से होगा, लेकिन यदि आपको उस अंतिम प्रदर्शन की आवश्यकता है, और सत्र डेटा को समय-समय पर बाहर निकालने की इच्छा है, तो cache बैक आपके लिए है।

यदि आप cached_db सत्र बैकएंड का उपयोग करते हैं, तो आपको डेटाबेस-समर्थित सत्रों का उपयोग करने के लिए कॉन्फ़िगरेशन निर्देशों का पालन करना होगा।

फ़ाइल-आधारित सत्रों का उपयोग करना

फ़ाइल-आधारित सत्रों का उपयोग करने के लिए, SESSION_ENGINE सेटिंग को "django.contrib.sessions.backends.file" सेट करें।

तुम भी SESSION_FILE_PATH सेटिंग (जो tempfile.gettempdir() , सबसे अधिक संभावना /tmp ) को नियंत्रित करने के लिए जहां Django स्टोर सत्र फ़ाइलों को आउटपुट करने के लिए डिफ़ॉल्ट सेट करना चाहते हैं। यह जांचना सुनिश्चित करें कि आपके वेब सर्वर को इस स्थान पर पढ़ने और लिखने की अनुमति है।

कुकी-आधारित सत्रों का उपयोग करना

कुकीज़-आधारित सत्रों का उपयोग करने के लिए, SESSION_ENGINE सेटिंग को "django.contrib.sessions.backends.signed_cookies" सेट करें। क्रिप्टोग्राफिक हस्ताक्षर और SECRET_KEY सेटिंग के लिए Django के टूल का उपयोग करके सत्र डेटा संग्रहीत किया जाएगा।

विचारों में सत्र का उपयोग करना

जब SessionMiddleware सक्रिय होता है, प्रत्येक HttpRequest ऑब्जेक्ट - किसी भी Django दृश्य फ़ंक्शन के लिए पहला तर्क - एक session विशेषता होगी, जो एक शब्दकोश जैसी वस्तु है।

आप इसे पढ़ सकते हैं और अपने विचार में किसी भी बिंदु पर request.session को लिख सकते हैं। आप इसे कई बार संपादित कर सकते हैं।

class backends.base.SessionBase

यह सभी सत्र वस्तुओं के लिए आधार वर्ग है। इसकी निम्नलिखित मानक शब्दकोश विधियाँ हैं:

__getitem__(key)

उदाहरण: fav_color = request.session['fav_color']

__setitem__(key, value)

उदाहरण: request.session['fav_color'] = 'blue'

__delitem__(key)

उदाहरण: del request.session['fav_color'] । यदि key पहले ही सत्र में नहीं है, तो यह KeyError बढ़ाता है।

__contains__(key)

उदाहरण: 'fav_color' in request.session

get(key, default=None)

उदाहरण: fav_color = request.session.get('fav_color', 'red')

pop(key, default=__not_given)

उदाहरण: fav_color = request.session.pop('fav_color', 'blue')

keys()

items()

setdefault()

clear()

इसकी ये विधियाँ भी हैं:

flush()

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

set_test_cookie()

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

test_cookie_worked()

उपयोगकर्ता के ब्राउज़र ने परीक्षण कुकी को स्वीकार किया या नहीं, इस पर निर्भर करते हुए, या तो True या False रिटर्न देता है। कुकीज़ के काम करने के तरीके के कारण, आपको set_test_cookie() को पिछले, अलग पेज के अनुरोध पर कॉल करना होगा। अधिक जानकारी के लिए नीचे परीक्षण कुकी सेट करना देखें।

delete_test_cookie()

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

set_expiry(value)

सत्र के लिए समाप्ति समय निर्धारित करता है। आप विभिन्न मूल्यों को पास कर सकते हैं:

• यदि value एक पूर्णांक है, तो सत्र कई सेकंड की निष्क्रियता के बाद समाप्त हो जाएगा। उदाहरण के लिए, कॉलिंग request.session.set_expiry(300) सत्र को 5 मिनट में समाप्त कर देगा।
• यदि value timedelta या timedelta ऑब्जेक्ट है, तो सत्र उस विशिष्ट तिथि / समय पर समाप्त हो जाएगा। ध्यान दें कि यदि आप PickleSerializer का उपयोग कर रहे हैं, तो PickleSerializer और PickleSerializer मान केवल क्रमिक हैं।
• यदि value 0 , तो उपयोगकर्ता का वेब ब्राउज़र बंद होने पर उपयोगकर्ता की सत्र कुकी समाप्त हो जाएगी।
• यदि value None , तो सत्र वैश्विक सत्र समाप्ति की नीति का उपयोग करने के लिए बदल जाता है।

एक सत्र पढ़ना समाप्ति उद्देश्यों के लिए गतिविधि नहीं माना जाता है। सत्र समाप्ति के अंतिम समय से सत्र समाप्ति की गणना की जाती है।

get_expiry_age()

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

यह फ़ंक्शन दो वैकल्पिक कीवर्ड तर्क स्वीकार करता है:

• modification : सत्र का अंतिम संशोधन, एक datetime ऑब्जेक्ट के रूप में। मौजूदा समय में चूक।
• expiry : सत्र के लिए समाप्ति की सूचना, एक datetime ऑब्जेक्ट के रूप में, एक int (सेकंड में), या None । सत्र में संग्रहीत मान के लिए डिफ़ॉल्ट set_expiry() , यदि कोई है, या None ।

get_expiry_date()

यह सत्र समाप्त होने की तारीख लौटाता है। बिना कस्टम समाप्ति वाले सत्रों के लिए (या ब्राउज़र के पास समाप्त होने वाले सेट), यह अब से SESSION_COOKIE_AGE सेकंड की तारीख के बराबर हो जाएगा।

यह फ़ंक्शन get_expiry_age() के समान कीवर्ड तर्क स्वीकार करता है।

get_expire_at_browser_close()

उपयोगकर्ता का वेब ब्राउज़र बंद होने पर उपयोगकर्ता का सत्र कुकी समाप्त हो जाएगा या नहीं, इस पर निर्भर करते हुए, या तो True या False होता है।

clear_expired()

सत्र संग्रह से समाप्त सत्र निकालता है। इस वर्ग विधि को clearsessions से कहा जाता है।

cycle_key()

वर्तमान सत्र डेटा को बनाए रखते हुए एक नया सत्र कुंजी बनाता है। django.contrib.auth.login() सत्र निर्धारण के विरुद्ध शमन करने के लिए इस विधि को कहता है।

सत्र क्रमांकन

डिफ़ॉल्ट रूप से, Django JSON का उपयोग करके सत्र डेटा को क्रमबद्ध करता है। सत्र क्रमांकन प्रारूप को अनुकूलित करने के लिए आप SESSION_SERIALIZER सेटिंग का उपयोग कर सकते हैं। यहां तक ​​कि अपने स्वयं के क्रमांक लिखने वाले केवेट के साथ भी, हम JSON क्रमांकन के साथ विशेष रूप से चिपकाने की सलाह देते हैं, खासकर यदि आप कुकर बैकेंड का उपयोग कर रहे हैं ।

उदाहरण के लिए, यदि आप सत्र डेटा को pickle करने के लिए pickle का उपयोग करते हैं, तो यहां एक आक्रमण परिदृश्य है। यदि आप हस्ताक्षरित कुकी सत्र बैकएंड का उपयोग कर रहे हैं और SECRET_KEY एक हमलावर द्वारा जाना जाता है (Django में एक अंतर्निहित भेद्यता नहीं है जो इसे लीक करने का कारण बनेगा), हमलावर अपने सत्र में एक स्ट्रिंग सम्मिलित कर सकता है, जो अनियंत्रित होने पर निष्पादित होता है सर्वर पर मनमाना कोड। ऐसा करने की तकनीक सरल और इंटरनेट पर आसानी से उपलब्ध है। यद्यपि कुकी सत्र भंडारण छेड़छाड़ को रोकने के लिए कुकी संग्रहीत डेटा पर हस्ताक्षर करता है, एक SECRET_KEY रिसाव तुरंत एक दूरस्थ कोड निष्पादन भेद्यता के लिए आगे बढ़ता है।

बँधे हुए धारावाहिक

class serializers.JSONSerializer

django.core.signing से JSON धारावाहिक के चारों ओर एक आवरण। केवल बुनियादी डेटा प्रकारों को क्रमबद्ध कर सकते हैं।

इसके अलावा, जब JSON केवल स्ट्रिंग कुंजियों का समर्थन करता है, तो ध्यान दें कि request.session में गैर-स्ट्रिंग कुंजी का उपयोग करना अपेक्षित के रूप में काम नहीं करेगा:

>>> # initial assignment
>>> request.session[0] = 'bar'
>>> # subsequent requests following serialization & deserialization
>>> # of session data
>>> request.session[0]  # KeyError
>>> request.session['0']
'bar'

इसी तरह, डेटा जो JSON में एनकोड नहीं किया जा सकता है, जैसे गैर-UTF8 बाइट्स जैसे '\xd9' (जो UnicodeDecodeError उठाता है), संग्रहीत नहीं किया जा सकता है।

JSON क्रमांकन की सीमाओं के बारे में अधिक जानकारी के लिए अपना स्वयं का क्रमबद्ध अनुभाग लिखें ।

class serializers.PickleSerializer

मनमानी अजगर वस्तुओं का समर्थन करता है, लेकिन, जैसा कि ऊपर वर्णित है, एक दूरस्थ कोड निष्पादन भेद्यता को जन्म दे सकता है अगर SECRET_KEY एक हमलावर द्वारा ज्ञात हो जाता है।

अपना खुद का क्रमांक लिखें

ध्यान दें कि PickleSerializer विपरीत, JSONSerializer मनमाने ढंग से Python डेटा प्रकारों को संभाल नहीं सकता है। जैसा कि अक्सर होता है, सुविधा और सुरक्षा के बीच व्यापार होता है। यदि आप JSON समर्थित सत्रों में datetime और Decimal सहित अधिक उन्नत डेटा प्रकारों को संग्रहीत करना चाहते हैं, तो आपको एक कस्टम धारावाहिक लिखना होगा (या request.session में संग्रहीत करने से पहले ऐसे मानों को JSON अनुक्रमिक वस्तु में बदलना होगा)। इन मूल्यों को क्रमबद्ध करते समय काफी सीधा है ( DjangoJSONEncoder सहायक हो सकता है), एक डिकोडर लिख रहा है जो मज़बूती से वापस उसी चीज़ को प्राप्त कर सकता है जिसे आपने डाला है और अधिक नाजुक है। उदाहरण के लिए, आप एक datetime को वापस करने का जोखिम चलाते हैं जो वास्तव में एक स्ट्रिंग था जो कि datetime लिए चुने गए एक ही प्रारूप में होना था)।

क्रमबद्ध रूप से सत्र डेटा के शब्दकोश को क्रमबद्ध और डिस्क्रिअलाइज़ करने के लिए आपके सीरियल क्लास को दो विधियाँ, dumps(self, obj) और loads(self, data) लागू करनी चाहिए।

सत्र वस्तु दिशानिर्देश

• request.session पर सामान्य कुंजी के रूप में पायथन स्ट्रिंग्स का उपयोग करें। request.session । यह एक कठिन-व्रत नियम से अधिक एक सम्मेलन है।
• सत्र डिक्शनरी कुंजियाँ जो एक अंडरस्कोर से शुरू होती हैं, वे Django द्वारा आंतरिक उपयोग के लिए आरक्षित हैं।
• नई ऑब्जेक्ट के साथ request.session को ओवरराइड न करें, और इसकी विशेषताओं तक पहुंच या सेट न करें। इसे पायथन डिक्शनरी की तरह इस्तेमाल करें।

उदाहरण

उपयोगकर्ता द्वारा एक टिप्पणी पोस्ट करने के बाद यह सरलीकृत दृश्य True has_commented चर सेट करता है। यह एक उपयोगकर्ता को एक से अधिक बार पोस्ट करने की अनुमति नहीं देता है:

def post_comment(request, new_comment):
    if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")
    c = comments.Comment(comment=new_comment)
    c.save()
    request.session['has_commented'] = True
    return HttpResponse('Thanks for your comment!')

यह सरल दृश्य साइट के "सदस्य" में लॉग होता है:

def login(request):
    m = Member.objects.get(username=request.POST['username'])
    if m.password == request.POST['password']:
        request.session['member_id'] = m.id
        return HttpResponse("You're logged in.")
    else:
        return HttpResponse("Your username and password didn't match.")

... और यह एक सदस्य लॉग के अनुसार बाहर लॉग करता है login() ऊपर:

def logout(request):
    try:
        del request.session['member_id']
    except KeyError:
        pass
    return HttpResponse("You're logged out.")

मानक django.contrib.auth.logout() फ़ंक्शन वास्तव में अनजाने में रिसाव को रोकने के लिए इससे थोड़ा अधिक करता है। यह flush() request.session तरीका कहता है। request.session हम इस उदाहरण का उपयोग सत्र वस्तुओं के साथ काम करने के प्रदर्शन के रूप में कर रहे हैं, न कि पूर्ण logout() कार्यान्वयन के रूप में।

परीक्षण कुकीज़ सेट करना

एक सुविधा के रूप में, Django परीक्षण करने का एक आसान तरीका प्रदान करता है कि उपयोगकर्ता का ब्राउज़र कुकीज़ स्वीकार करता है या नहीं। बस एक दृश्य में set_test_cookie() request.session विधि और बाद के दृश्य में test_cookie_worked() कॉल करें - एक ही दृश्य कॉल में नहीं।

कुकीज़ के काम करने के तरीके के कारण set_test_cookie() और test_cookie_worked() बीच यह अजीब विभाजन आवश्यक है। जब आप कुकी सेट करते हैं, तो आप वास्तव में यह नहीं बता सकते हैं कि क्या ब्राउज़र ने ब्राउज़र के अगले अनुरोध तक इसे स्वीकार कर लिया है।

अपने आप को साफ करने के लिए delete_test_cookie() का उपयोग करना अच्छा अभ्यास है। आपके द्वारा सत्यापित किए जाने के बाद कि परीक्षण कुकी ने काम किया है।

यहां एक विशिष्ट उपयोग उदाहरण दिया गया है:

from django.http import HttpResponse
from django.shortcuts import render

def login(request):
    if request.method == 'POST':
        if request.session.test_cookie_worked():
            request.session.delete_test_cookie()
            return HttpResponse("You're logged in.")
        else:
            return HttpResponse("Please enable cookies and try again.")
    request.session.set_test_cookie()
    return render(request, 'foo/login_form.html')

सत्रों का उपयोग करना

>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore

एक दृश्य के बाहर सत्र डेटा में हेरफेर करने के लिए एक एपीआई उपलब्ध है:

>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore()
>>> # stored as seconds since epoch since datetimes are not serializable in JSON.
>>> s['last_login'] = 1376587691
>>> s.create()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
>>> s['last_login']
1376587691

SessionStore.create() को एक नया सत्र बनाने के लिए डिज़ाइन किया गया है (यानी सत्र सत्र से लोड नहीं किया गया है और session_key=None )। save() को मौजूदा सत्र को बचाने के लिए डिज़ाइन किया गया है (यानी सत्र स्टोर से लोड किया गया)। नए सत्र पर कॉलिंग save() भी काम कर सकता है, लेकिन session_key उत्पन्न करने का एक छोटा सा मौका है जो किसी मौजूदा के साथ टकराता है। create() कॉल save() और लूप्स का उपयोग अप्रयुक्त session_key उत्पन्न होने तक होता है।

यदि आप django.contrib.sessions.backends.db बैकएंड का उपयोग कर रहे हैं, तो प्रत्येक सत्र केवल एक सामान्य Django मॉडल है। Session मॉडल django/contrib/sessions/models.py में परिभाषित किया गया है। क्योंकि यह एक सामान्य मॉडल है, आप सामान्य Django डेटाबेस API का उपयोग करके सत्र तक पहुँच सकते हैं:

>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get(pk='2b1189a188b44ad18c35e113ac6ceead')
>>> s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)

ध्यान दें कि आपको सत्र शब्दकोश प्राप्त करने के लिए get_decoded() को कॉल करना होगा। यह आवश्यक है क्योंकि शब्दकोश एक एन्कोडेड प्रारूप में संग्रहीत है:

>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}

जब सत्र बच जाते हैं

डिफ़ॉल्ट रूप से, Django केवल सत्र डेटाबेस को बचाता है, जब सत्र को संशोधित किया गया है - यदि इसके किसी भी शब्दकोश मान को असाइन किया गया है या हटाया गया है:

# Session is modified.
request.session['foo'] = 'bar'

# Session is modified.
del request.session['foo']

# Session is modified.
request.session['foo'] = {}

# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session['foo']['bar'] = 'baz'

उपर्युक्त उदाहरण के अंतिम मामले में, हम सत्र वस्तु को स्पष्ट रूप से बता सकते हैं कि सत्रांक पर modified विशेषता सेट करके इसे संशोधित किया गया है:

request.session.modified = True

इस डिफ़ॉल्ट व्यवहार को बदलने के लिए, SESSION_SAVE_EVERY_REQUEST सेटिंग को True सेट करें। True सेट होने पर, Django हर एक अनुरोध पर सत्र को डेटाबेस में बचाएगा।

ध्यान दें कि सत्र कुकी तभी भेजी जाती है जब कोई सत्र बनाया या संशोधित किया गया हो। यदि SESSION_SAVE_EVERY_REQUEST True , तो सत्र कुकी को हर अनुरोध पर भेजा जाएगा।

इसी तरह, एक सत्र कुकी के expires हिस्से को हर बार सत्र कुकी भेजे जाने के बाद अपडेट किया जाता है।

यदि प्रतिक्रिया की स्थिति कोड 500 है तो सत्र को बचाया नहीं गया है।

ब्राउज़र-लंबाई सत्र बनाम लगातार सत्र

आप यह नियंत्रित कर सकते हैं कि सत्र रूपरेखा ब्राउज़र-लंबाई सत्र बनाम लगातार सत्रों का उपयोग करती है SESSION_EXPIRE_AT_BROWSER_CLOSE सेटिंग के साथ।

डिफ़ॉल्ट रूप से, SESSION_EXPIRE_AT_BROWSER_CLOSE False सेट है, जिसका अर्थ है कि सत्र कुकीज़ उपयोगकर्ताओं के ब्राउज़रों में SESSION_COOKIE_AGE लिए लंबे समय तक संग्रहीत की जाएंगी। इसका उपयोग करें यदि आप नहीं चाहते हैं कि लोग हर बार एक ब्राउज़र खोलने के लिए लॉग इन करें।

यदि SESSION_EXPIRE_AT_BROWSER_CLOSE सही पर सेट है, तो Django ब्राउज़र-लंबाई कुकीज़ का उपयोग करेगा - उपयोगकर्ता द्वारा अपना ब्राउज़र बंद करते ही समाप्त होने वाली कुकीज़। इसका उपयोग करें यदि आप चाहते हैं कि लोग हर बार एक ब्राउज़र खोलने के लिए लॉग इन करें।

यह सेटिंग एक वैश्विक डिफ़ॉल्ट है और विचारों में सत्र का उपयोग करते हुए ऊपर वर्णित के रूप में request.session के set_expiry() विधि को स्पष्ट रूप से कॉल करके प्रति-सत्र स्तर पर ओवरराइट किया जा सकता है।

सत्र संग्रह साफ़ करना

जैसे ही उपयोगकर्ता आपकी वेबसाइट पर नए सत्र बनाते हैं, सत्र डेटा आपके सत्र स्टोर में जमा हो सकता है। यदि आप डेटाबेस बैकएंड का उपयोग कर रहे हैं, तो django_session डेटाबेस तालिका विकसित होगी। यदि आप फ़ाइल बैकएंड का उपयोग कर रहे हैं, तो आपकी अस्थायी निर्देशिका में फ़ाइलों की बढ़ती संख्या होगी।

इस समस्या को समझने के लिए, डेटाबेस बैकएंड के साथ क्या होता है, इस पर विचार करें। जब कोई उपयोगकर्ता लॉग इन करता है, तो Django django_session डेटाबेस तालिका में एक पंक्ति जोड़ता है। Django हर बार सत्र डेटा में बदलाव के लिए इस पंक्ति को अपडेट करता है। यदि उपयोगकर्ता मैन्युअल रूप से लॉग आउट करता है, तो Django पंक्ति को हटा देता है। लेकिन अगर उपयोगकर्ता लॉग आउट नहीं करता है, तो पंक्ति कभी भी डिलीट नहीं होती है। इसी तरह की प्रक्रिया फ़ाइल बैकएंड के साथ होती है।

Django समाप्त सत्रों के स्वत: शुद्धिकरण प्रदान नहीं करता है। इसलिए, नियमित आधार पर समाप्त सत्रों को शुद्ध करना आपका काम है। Django इस उद्देश्य के लिए एक क्लीन-अप प्रबंधन आदेश प्रदान करता है: clearsessions । इस आदेश को नियमित रूप से कॉल करने की सिफारिश की जाती है, उदाहरण के लिए दैनिक क्रोन नौकरी के रूप में।

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

सेटिंग्स

कुछ Django सेटिंग्स आपको सत्र व्यवहार पर नियंत्रण देती हैं:

• SESSION_CACHE_ALIAS
• SESSION_COOKIE_AGE
• SESSION_COOKIE_DOMAIN
• SESSION_COOKIE_HTTPONLY
• SESSION_COOKIE_NAME
• SESSION_COOKIE_PATH
• SESSION_COOKIE_SAMESITE
• SESSION_COOKIE_SECURE
• SESSION_ENGINE
• SESSION_EXPIRE_AT_BROWSER_CLOSE
• SESSION_FILE_PATH
• SESSION_SAVE_EVERY_REQUEST
• SESSION_SERIALIZER

सत्र सुरक्षा

एक साइट के भीतर उप डोमेन पूरे डोमेन के लिए क्लाइंट पर कुकीज़ सेट करने में सक्षम हैं। यह सत्र निर्धारण को संभव बनाता है अगर कुकीज़ को विश्वसनीय उपयोगकर्ताओं द्वारा नियंत्रित नहीं उप-डोमेन से अनुमति दी जाती है।

उदाहरण के लिए, एक हमलावर good.example.com में लॉग इन कर सकता है और अपने खाते के लिए एक वैध सत्र प्राप्त कर सकता है। यदि हमलावर का bad.example.com पर नियंत्रण है, तो वे इसका उपयोग आपकी सत्र कुंजी को भेजने के लिए कर सकते हैं क्योंकि उप डोमेन को *.example.com पर कुकीज़ सेट करने की अनुमति है। जब आप good.example.com पर good.example.com , तो आप हमलावर के रूप में लॉग इन होंगे और अनजाने में अपने संवेदनशील व्यक्तिगत डेटा (जैसे क्रेडिट कार्ड की जानकारी) को हमलावरों के खाते में दर्ज कर सकते हैं।

एक और संभावित हमला होगा यदि good.example.com अपने SESSION_COOKIE_DOMAIN को "example.com" सेट करता है, जिससे उस साइट से सत्र कुकीज़ bad.example.com हो bad.example.com ।

तकनीकी जानकारी

• सत्र डिक्शनरी किसी भी json क्रमिक मूल्य को स्वीकार करता है जब JSONSerializer का उपयोग करते समय JSONSerializer या किसी picklable पायथन ऑब्जेक्ट का उपयोग किया PickleSerializer । अधिक जानकारी के लिए pickle मॉड्यूल देखें।
• सत्र डेटा को django_session नामक डेटाबेस तालिका में संग्रहीत किया जाता है।
• Django केवल एक कुकी भेजता है अगर यह करने की जरूरत है। यदि आप कोई सत्र डेटा सेट नहीं करते हैं, तो यह सत्र कुकी नहीं भेजेगा।

SessionStore ऑब्जेक्ट

आंतरिक रूप से सत्र के साथ काम करते समय, Django संगत सत्र इंजन से सत्र संग्रह ऑब्जेक्ट का उपयोग करता है। अधिवेशन द्वारा, सत्र स्टोर ऑब्जेक्ट क्लास को SessionStore नाम दिया गया है और SESSION_ENGINE द्वारा नामित मॉड्यूल में स्थित है।

Django में उपलब्ध सभी SessionStore कक्षाएं SessionBase से विरासत में SessionBase और डेटा हेरफेर विधियों को लागू करती हैं, अर्थात्:

• exists()
• create()
• save()
• delete()
• load()
• clear_expired()

कस्टम सत्र इंजन बनाने या किसी मौजूदा को अनुकूलित करने के लिए, आप SessionBase या किसी अन्य मौजूदा SessionStore वर्ग से विरासत में एक नया वर्ग बना सकते हैं।

अधिकांश सत्र इंजनों का विस्तार करना काफी सरल है, लेकिन डेटाबेस-समर्थित सत्र इंजनों के साथ ऐसा करने के लिए आम तौर पर कुछ अतिरिक्त प्रयासों की आवश्यकता होती है (विवरण के लिए अगला अनुभाग देखें)।

डेटाबेस समर्थित सत्र इंजन का विस्तार

Django (अर्थात db और cached_db ) में शामिल लोगों पर निर्मित एक कस्टम डेटाबेस-समर्थित सत्र इंजन बनाना, AbstractBaseSession और या तो SessionStore वर्ग की विरासत द्वारा किया जा सकता है।

AbstractBaseSession और BaseSessionManager से आयात करने योग्य हैं ताकि वे INSTALLED_APPS में django.contrib.sessions को शामिल किए बिना आयात किए जा django.contrib.sessions ।

class base_session.AbstractBaseSession

सार आधार सत्र मॉडल।

session_key

प्राथमिक कुंजी। फ़ील्ड में अधिकतम 40 वर्ण हो सकते हैं। वर्तमान कार्यान्वयन एक 32-वर्ण स्ट्रिंग (अंकों का एक यादृच्छिक अनुक्रम और ASCII अक्षर कम करता है) उत्पन्न करता है।

session_data

एक स्ट्रिंग जिसमें एक एन्कोडेड और क्रमबद्ध सत्र शब्दकोश होता है।

expire_date

जब सत्र समाप्त हो रहा हो, तो एक डेटाइम पदनाम।

निष्कासित सत्र किसी उपयोगकर्ता के लिए उपलब्ध नहीं हैं, हालांकि, तब भी उन्हें डेटाबेस में संग्रहीत किया जा सकता है जब तक कि clearsessions प्रबंधन कमांड नहीं चलती है।

classmethod get_session_store_class()

इस सत्र मॉडल के साथ एक सेशन स्टोर क्लास का उपयोग करता है।

get_decoded()

रिटर्न डीकोड सत्र डेटा।

डिकोडिंग सत्र दुकान वर्ग द्वारा किया जाता है।

आप BaseSessionManager करके मॉडल प्रबंधक को भी अनुकूलित कर सकते हैं:

class base_session.BaseSessionManager

encode(session_dict)

दिए गए सत्र डिक्शनरी को क्रमबद्ध और एक स्ट्रिंग के रूप में एन्कोड किया गया है।

एन्कोडिंग एक मॉडल वर्ग से बंधा सत्र दुकान वर्ग द्वारा किया जाता है।

save(session_key, session_dict, expire_date)

किसी दिए गए सत्र कुंजी के लिए सत्र डेटा सहेजता है, या डेटा खाली होने पर सत्र को हटा देता है।

SessionStore कक्षाओं का अनुकूलन नीचे वर्णित तरीकों और गुणों को ओवरराइड करके प्राप्त किया जाता है:

class backends.db.SessionStore

डेटाबेस डेटाबेस समर्थित सत्र संग्रह लागू करता है।

classmethod get_model_class()

यदि आपको एक की आवश्यकता है तो कस्टम सत्र मॉडल वापस करने के लिए इस विधि को ओवरराइड करें।

create_model_instance(data)

सत्र मॉडल ऑब्जेक्ट का एक नया उदाहरण देता है, जो वर्तमान सत्र स्थिति का प्रतिनिधित्व करता है।

इस पद्धति को ओवरराइड करने से डेटाबेस को सहेजने से पहले सत्र मॉडल डेटा को संशोधित करने की क्षमता मिलती है।

class backends.cached_db.SessionStore

लागू डेटाबेस-समर्थित सत्र संग्रह कैश किया गया।

cache_key_prefix

कैश कुंजी स्ट्रिंग बनाने के लिए सत्र कुंजी में एक उपसर्ग जोड़ा गया।

उदाहरण

नीचे दिया गया उदाहरण एक कस्टम डेटाबेस-समर्थित सत्र इंजन दिखाता है जिसमें एक खाता आईडी स्टोर करने के लिए एक अतिरिक्त डेटाबेस कॉलम शामिल है (इस प्रकार एक खाते के लिए सभी सक्रिय सत्रों के लिए डेटाबेस को क्वेरी करने का विकल्प प्रदान करता है):

from django.contrib.sessions.backends.db import SessionStore as DBStore
from django.contrib.sessions.base_session import AbstractBaseSession
from django.db import models

class CustomSession(AbstractBaseSession):
    account_id = models.IntegerField(null=True, db_index=True)

    @classmethod
    def get_session_store_class(cls):
        return SessionStore

class SessionStore(DBStore):
    @classmethod
    def get_model_class(cls):
        return CustomSession

    def create_model_instance(self, data):
        obj = super().create_model_instance(data)
        try:
            account_id = int(data.get('_auth_user_id'))
        except (ValueError, TypeError):
            account_id = None
        obj.account_id = account_id
        return obj

यदि आप Django के निर्मित cached_db सेशन स्टोर में से एक कस्टम cached_db पर आधारित माइग्रेट कर रहे हैं, तो आपको नेमस्पेस क्लैश को रोकने के लिए कैश की उपसर्ग को ओवरराइड करना चाहिए:

class SessionStore(CachedDBStore):
    cache_key_prefix = 'mysessions.custom_cached_db_backend'

    # ...

URL में सत्र आईडी

Django सत्र की रूपरेखा पूरी तरह से और पूरी तरह से कुकी आधारित है। यह URL में सत्र आईडी को अंतिम उपाय के रूप में डालने से पीछे नहीं हटता, जैसा कि PHP करता है। यह एक जानबूझकर डिजाइन निर्णय है। इतना ही नहीं व्यवहार URLs को बदसूरत बनाता है, यह आपकी साइट को "रेफर" हेडर के माध्यम से सत्र-आईडी चोरी के लिए असुरक्षित बनाता है।