उपयोगकर्ता अनुमतियों को स्टोर करने का सबसे अच्छा तरीका?

Question

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

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

इसके अलावा, सत्र स्पष्ट रूप से उपयोगकर्ता द्वारा संपादित किया जा सकता है ... क्या कोई सुरक्षित तरीका है?

मैंने प्रत्येक चेक के लिए एक क्वेरी चलाने का विचार किया है, लेकिन यह एक साधारण AJAX अनुरोध के लिए लोड समय में काफी वृद्धि कर सकता है।

मैं किसी भी और सभी विचारों के लिए खुला हूं। धन्यवाद।

Answer 1

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

दूसरा, मैं डेटाबेस कनेक्शन पर बहुत अधिक चिंता नहीं करता। खुद को दोहराने से बचें, लेकिन पहले कनेक्शन के बारे में ज्यादा चिंता न करें।

अंत में, रोल बनाने के बिना कई अनुमतियों को करने का मेरा पसंदीदा तरीका बाइनरी गणित का उपयोग करना है। कुछ लोग इसे पसंद करते हैं, कुछ लोग नहीं करते हैं, लेकिन मुझे यह उपयोगी लगता है।

इस विधि, इमेजिंग है कि हमें निम्न मान निर्धारित करने का उपयोग करें:

CAN_EDIT_SOMETHING  = 1  // Powers of 2 
CAN_SEE_SOMETHING_ELSE = 2 
CAN_DO_ADMIN_STUFF  = 4 
...      = 8 

लोगों के पास अनेक अनुमतियाँ देने के लिए

PERMISSIONS = CAN_EDIT_SOMETHING | CAN_DO_ADMIN_STUFF 

, द्विआधारी का उपयोग करें या यह कैसे काम करता समझाने के लिए, हम देख सकते हैं बिट्स: अगर कोई एक की अनुमति है

0b0001 
OR 0b0100 
--------- 
    0b0101 

जाँच करने के लिए, द्विआधारी का उपयोग और

if(PERMISSIONS & CAN_EDIT_SOMETHING != 0) { 
} 

यह कैसे काम करता है, हम फिर से बिट्स पर देखने को देखने के लिए

0b0101 
AND 0b0001 
---------- 
    0b0001 // Not equal to 0. They must have that permission! 

इस विधि के अंतिम लाभ यह है कि यह आप आसानी से "मेटा अनुमतियाँ"

में एकाधिक अनुमतियाँ गठबंधन करने के लिए अनुमति देता है

// If both EDIT_SOMETHING and ADMIN_STUFF are tasks that an admin 
// can perform, we can combine them easily 
// 
IS_FULL_ADMIN  = CAN_EDIT_SOMETHING | CAN_DO_ADMIN_STUFF 


// We can then use this value exactly as we do any other permission 
// 
PERMISSIONS  = IS_FULL_ADMIN | CAN_SEE_SOMETHING ELSE 

यदि आप चाहें तो इसका इस्तेमाल करें, लेकिन यह आपके शस्त्रागार में एक अच्छी चाल है।

Answer 2

मेरे लिए ठीक लगता है! आप अपने सत्र chache peformance को बढ़ाने के लिए कुछ सॉफ्टवेयर देख सकते हैं।

हर बार डीबी पूछना उतना बुरा नहीं है जितना लगता है! सबसे पहले आपको शायद डीबी से कनेक्ट करने की ज़रूरत है, दूसरी बात यह है कि यदि आपने साइन इन करते समय उपयोगकर्ता अनुमतियों की पूछताछ की तो संभावना है कि सभी रिलीज पंक्तियां बफर में बैठी हैं और आईओ की आवश्यकता नहीं है, तीसरी बार एक ही अनुमति के लिए एक क्वेरी एक उपयोगकर्ता एक उपयोगकर्ता के लिए सभी अनुमतियों के लिए एक क्वेरी से बहुत हल्का होने जा रहा है।

Answer 3

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

इसके अलावा, सत्र जाहिरा तौर पर उपयोगकर्ता द्वारा संपादित किया जा सकता

WTF ????? !!!!

सत्र डेटा केवल आपके कोड में परिभाषित विधियों द्वारा बदला जाना चाहिए - यदि उपयोगकर्ता किसी भी तरह से सत्र डेटा के किसी भी हिस्से को संशोधित करने में सक्षम होते हैं तो यह पहली समस्या है जिसे आपको संबोधित करने की आवश्यकता है - जब तक आप ऐसा करें, जब तक आप अपने एप्लिकेशन कोड के डोमेन से प्रमाणीकरण को पूरी तरह से स्थानांतरित नहीं करते हैं, तब तक यह आपके प्रमाणीकरण/प्राधिकरण विधि के किसी भी हिस्से पर भरोसा करना लगभग असंभव होगा (बीटीडब्ल्यू: समस्या को ठीक करने का यह सही तरीका नहीं है)।

निश्चित रूप से एक बहुत बड़ी सरणी (वास्तविक ब्रेकपॉइंट के बारे में सुनिश्चित नहीं है - लेकिन एन = 1000 के क्षेत्र में - लेकिन इस पर असर डालने वाले बहुत सारे चर) डेटाबेस से परिणामों को लाने से काफी धीमे हो सकते हैं।

यह कहना मुश्किल है कि आप यह समझने में कितना गलत कर रहे हैं कि आपकी वर्तमान प्रणाली कैसे काम करती है। क्या यह one of these है?