Django 2.1 - How to use sessions
सत्र का उपयोग कैसे करें

सत्र का उपयोग कैसे करें
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 के कैश सिस्टम का उपयोग करके सत्र डेटा संग्रहीत करने के लिए, आपको पहले यह सुनिश्चित करना होगा कि आपने अपना कैश कॉन्फ़िगर किया है; विवरण के लिए कैश प्रलेखन देखें।
चेतावनी
यदि आप Memcached cache backend का उपयोग कर रहे हैं तो आपको केवल कैश-आधारित सत्रों का उपयोग करना चाहिए। स्थानीय-मेमोरी कैश बैकएंड एक अच्छा विकल्प होने के लिए डेटा को लंबे समय तक बनाए नहीं रखता है, और यह फ़ाइल या डेटाबेस कैश बैकेंड के माध्यम से सब कुछ भेजने के बजाय सीधे फ़ाइल या डेटाबेस सत्रों का उपयोग करने के लिए तेज़ होगा। इसके अतिरिक्त, स्थानीय मेमोरी कैश बैकएंड मल्टी-प्रोसेस सुरक्षित नहीं है, इसलिए शायद उत्पादन वातावरण के लिए एक अच्छा विकल्प नहीं है।
यदि आपके पास
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_COOKIE_HTTPONLY
सेटिंग
True
पर छोड़ने की सिफारिश की गई है।
चेतावनी
यदि SECRET_KEY को गुप्त नहीं रखा गया है और आप
PickleSerializer
का उपयोग कर रहे हैं
, तो
इससे दूरस्थ रूप से दूरस्थ निष्पादन निष्पादन हो सकता है।
SECRET_KEY
कब्जे में एक हमलावर न केवल गलत सत्र डेटा उत्पन्न कर सकता है, जिस पर आपकी साइट भरोसा करेगी, बल्कि दूरस्थ रूप से मनमाने कोड को भी निष्पादित करेगी, क्योंकि अचार का उपयोग करके डेटा को सीरियल किया जाता है।
यदि आप कुकी-आधारित सत्रों का उपयोग करते हैं, तो अतिरिक्त ध्यान दें कि आपकी गुप्त कुंजी हमेशा पूरी तरह से गुप्त रखी जाए, किसी भी प्रणाली के लिए जो दूर से सुलभ हो सकती है।
सत्र डेटा पर हस्ताक्षर किए गए हैं लेकिन एन्क्रिप्ट नहीं किए गए हैं
कुकीज़ का उपयोग करते समय सत्र डेटा क्लाइंट द्वारा पढ़ा जा सकता है।
एक MAC (मैसेज ऑथेंटिकेशन कोड) का उपयोग क्लाइंट द्वारा परिवर्तनों के खिलाफ डेटा की सुरक्षा के लिए किया जाता है, ताकि छेड़छाड़ होने पर सत्र डेटा अमान्य हो जाए। यदि ग्राहक कुकी (जैसे आपके उपयोगकर्ता का ब्राउज़र) संग्रहीत करता है, तो वही अमान्यता होती है, जो सभी सत्र कुकी को संग्रहीत नहीं करता है और डेटा को छोड़ देता है। भले ही Django डेटा को संपीड़ित करता है, यह अभी भी कुकी के प्रति 4096 बाइट्स की सामान्य सीमा को पार करने के लिए पूरी तरह से संभव है।
कोई ताजगी की गारंटी नहीं
यह भी ध्यान दें कि जबकि MAC डेटा की प्रामाणिकता की गारंटी दे सकता है (कि यह आपकी साइट द्वारा उत्पन्न किया गया था, और किसी और ने नहीं), और डेटा की अखंडता (कि यह सब वहाँ है और सही है), यह ताजगी की गारंटी नहीं दे सकता है अर्थात आपको ग्राहक को भेजी गई अंतिम चीज़ वापस भेजी जा रही है।
इसका मतलब है कि सत्र डेटा के कुछ उपयोगों के लिए, कुकी बैकएंड आपको
हमलों
को
फिर से
खोलने के लिए खोल सकती है।
अन्य सत्रों के विपरीत, जो प्रत्येक सत्र का सर्वर-साइड रिकॉर्ड रखते हैं और उपयोगकर्ता द्वारा लॉग आउट होने पर इसे अमान्य कर देते हैं, उपयोगकर्ता द्वारा लॉग आउट करने पर कुकी-आधारित सत्र अमान्य नहीं होते हैं।
इस प्रकार अगर कोई हमलावर किसी उपयोगकर्ता की कुकी चुराता है, तो वे उस कुकी का उपयोग उस उपयोगकर्ता के रूप में लॉग इन करने के लिए कर सकते हैं, भले ही उपयोगकर्ता लॉग आउट करता हो।
यदि आपके
SESSION_COOKIE_AGE
से पुराने हैं, तो कुकीज़ को केवल 'बासी' के रूप में पहचाना जाएगा।
प्रदर्शन
अंत में, कुकी के आकार का आपकी साइट की गति पर प्रभाव पड़ सकता है।
विचारों में सत्र का उपयोग करना
जब
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()
फ़ंक्शन इसे कॉल करता है)।
-
उपयोगकर्ता के ब्राउज़र कुकीज़ का समर्थन करता है या नहीं यह निर्धारित करने के लिए एक परीक्षण कुकी सेट करता है। कुकीज़ के काम करने के तरीके के कारण, आप उपयोगकर्ता के अगले पृष्ठ के अनुरोध तक इसका परीक्षण नहीं कर पाएंगे। अधिक जानकारी के लिए नीचे परीक्षण कुकी सेट करना देखें।
-
उपयोगकर्ता के ब्राउज़र ने परीक्षण कुकी को स्वीकार किया या नहीं, इस पर निर्भर करते हुए, या तो
True
याFalse
रिटर्न देता है। कुकीज़ के काम करने के तरीके के कारण, आपकोset_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()
कार्यान्वयन के रूप में।
परीक्षण कुकीज़ सेट करना
कुकीज़ के काम करने के तरीके के कारण
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')
सत्रों का उपयोग करना
ध्यान दें
इस खंड में उदाहरण सीधे
django.contrib.sessions.backends.db
बैकएंड से
SessionStore
ऑब्जेक्ट आयात करते हैं।
अपने स्वयं के कोड में, आपको
SESSION_ENGINE
द्वारा निर्दिष्ट सत्र इंजन से
SessionStore
को आयात करने पर विचार करना चाहिए:
>>> 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()
विधि को स्पष्ट रूप से कॉल करके प्रति-सत्र स्तर पर ओवरराइट किया जा सकता है।
ध्यान दें
कुछ ब्राउज़र (उदाहरण के लिए Chrome) ऐसी सेटिंग्स प्रदान करते हैं जो उपयोगकर्ताओं को ब्राउज़र को बंद करने और फिर से खोलने के बाद ब्राउज़िंग सत्र जारी रखने की अनुमति देती हैं।
कुछ मामलों में, यह
SESSION_EXPIRE_AT_BROWSER_CLOSE
सेटिंग के साथ हस्तक्षेप कर सकता है और सत्रों को ब्राउज़र के पास समाप्त होने से रोक सकता है।
Django अनुप्रयोगों का परीक्षण करते समय कृपया इसके बारे में जानकारी रखें जिसमें
SESSION_EXPIRE_AT_BROWSER_CLOSE
सेटिंग सक्षम है।
सत्र संग्रह साफ़ करना
जैसे ही उपयोगकर्ता आपकी वेबसाइट पर नए सत्र बनाते हैं, सत्र डेटा आपके सत्र स्टोर में जमा हो सकता है।
यदि आप डेटाबेस बैकएंड का उपयोग कर रहे हैं, तो
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 को बदसूरत बनाता है, यह आपकी साइट को "रेफर" हेडर के माध्यम से सत्र-आईडी चोरी के लिए असुरक्षित बनाता है।