😶 🦌 🏂 बहु-उपयोगकर्ता सेवाओं में अनुक्रमण अधिकार। 🤶 🍠 💞

यह पाठ बहु-उपयोगकर्ता परियोजनाओं में निजी डेटा के चयन को गति देने के बारे में है।

शुरुआत में चर्चा की गई कुछ चीजें पहले से ही आपको अच्छी तरह से ज्ञात हो सकती हैं, लेकिन यह देखते हुए कि एक्सेस अधिकारों के परिसीमन के बारे में प्रश्न नियमित रूप से पूछे जाते हैं, मैंने उन्हें और अधिक विस्तार से विचार करना आवश्यक पाया।

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

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

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

पहुँच स्तर के आधार पर अधिकारों का पृथक्करण।

इस तरह के अलगाव का एक उदाहरण राज्य के संस्थानों में गोपनीयता की प्रणाली है, अर्थात्, हर किसी के पास एक निश्चित स्तर की पहुंच वाला विषय है, और प्रत्येक वस्तु में गोपनीयता का एक निश्चित स्तर है; एक वस्तु को पढ़ने के लिए, गोपनीयता के स्तर से कम नहीं पहुंच स्तर की आवश्यकता होती है।

इंटरनेट साइटों के लिए, एक नियम के रूप में, स्तर से अलग किया जाता है: "परिचितों", "दोस्त", "रिश्तेदार"। इसके अलावा, एक ही सिद्धांत (केवल कार्यों के लिए) के अनुसार, साइट habrahabr.ru पर "कर्म" का तंत्र

इस प्रकार, चयन दो तालिकाओं के अनुसार किया जाता है:

रिकॉर्ड - रिकॉर्ड
आईडी	पूर्णांक	रिकॉर्ड आईडी
us_id	पूर्णांक	मालिक
स्तर	पूर्णांक	गोपनीयता का स्तर

user_levels - पहुंच स्तर
us_id	पूर्णांक	उपयोगकर्ता
cor_id	पूर्णांक	लिंक किया गया उपयोगकर्ता
स्तर	पूर्णांक	पहुंच का स्तर

इस प्रकार, आप अनुमत प्रविष्टियों का चयन इस प्रकार कर सकते हैं:

SELECT `records`.`id` 
      

        
        
        
      

     FROM `records`, `level` 
      

        
        
        
      

     WHERE `records`.`us_id`=`user_levels`.`us_id` 
      

        
        
        
      

     AND `records`.`level`<=`users`.`level` 
      

        
        
        
      

     AND `user_levels`.`cor_id`=$us_id;

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

एसीएल

एसीएल पहुंच सूचियों की एक प्रणाली है जिसमें भूमिकाओं (समूहों) को एक मनमाना वस्तु पर कुछ कार्रवाई की अनुमति या इनकार किया जा सकता है। इस स्थिति में, एक वस्तु दूसरे से अभिगम अधिकार प्राप्त कर सकती है।

इसके अलावा, भूमिका सदस्यता की गणना ऑब्जेक्ट के संबंध में मक्खी पर की जा सकती है।

इसे "वर्चुअल समूह" कहा जाता है, उदाहरण के लिए, आभासी समूह "स्वामी" हो सकता है, जिसकी गणना user_id = object.owner_id के रूप में की जाती है। डिस्क कोटा को एक आभासी समूह के रूप में भी लागू किया जा सकता है: जिन उपयोगकर्ताओं ने एन मेगाबाइट से कम डाउनलोड किया है।

ACL अधिकारों के साथ काम करने के दौरान एक अविश्वसनीय रूप से लचीला और सुविधाजनक उपकरण है। आप "प्रोटेक्ट कोड" पुस्तक में ACL के बारे में अधिक पढ़ सकते हैं, जो विंडोज में एक्सेस लिस्ट के तंत्र का विस्तार से वर्णन करता है, अगर सब कुछ जो Microsoft से जुड़ा है, तो आपको अस्वीकार कर देता है या आप यदि आप तुरंत अपनी साइट पर इस तंत्र का उपयोग करना चाहते हैं, तो आपको zend_acl लाइब्रेरी के प्रलेखन का उल्लेख करना चाहिए।

सभी लाभों के बावजूद, ACL के महत्वपूर्ण नुकसान हैं:

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

यह मुख्य अड़चन है, पहुंच तालिकाओं की संरचना काफी nontrivial है और भंडारण के लिए सामान्य करने में काफी कठिन है, अर्थात। वे आमतौर पर क्रमबद्ध रूप में संग्रहीत होते हैं।

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

यानी तत्वों की संख्या के लिए एक सूची, या (ओए) प्राप्त करने के लिए, हमें और अधिक रिकॉर्ड चुनने की आवश्यकता है, जिसे हमें प्रदर्शित करने की आवश्यकता है, और यहां तक कि अपरिभाषित सीमा स्थितियों से भी।

नमूना स्तर पर ऐसा करने के लिए, अनुरोध में सीधे व्यावहारिक रूप से असंभव है।

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

इसलिए, मेरा मानना है कि एसीएल तंत्र बेमानी है, ज्यादातर जरूरतों के लिए, इसलिए उन्हें ऐसा होना चाहिए जहां यह वास्तव में आवश्यक हो, और लगातार सरल मामलों के लिए (बस प्रतिबंध पढ़ना) सरल उपकरणों का उपयोग करें।

उपयोगकर्ता समूह।

इसलिए, एक नियम के रूप में, उपयोगकर्ता के कई समूह हैं, उदाहरण के लिए, "दोस्त", "सहकर्मी" और "रिश्तेदार", जिन्हें वह कुछ रिकॉर्ड पढ़ने की अनुमति देना चाहता है।

इस मामले में:

एक ही उपयोगकर्ता एक ही समय में कई समूहों का सदस्य हो सकता है (एक "दोस्त" और "सहयोगी" होने के नाते, हालांकि यह अलग है)
रिकॉर्ड एक या कई समूहों के लिए खुला हो सकता है (उदाहरण के लिए, दोस्तों और रिश्तेदारों को नौकरी बदलने की आपकी इच्छा के बारे में पता होना चाहिए, लेकिन सहकर्मियों को इस बारे में जानने की आवश्यकता नहीं है)।

इस प्रकार, हमारे पास निम्नलिखित संरचना है:

रिकॉर्ड - रिकॉर्ड
आईडी	पूर्णांक	रिकॉर्ड आईडी
us_id	पूर्णांक	मालिक

record_permissions - जो पढ़ सकता है
record_id	पूर्णांक	रिकॉर्ड आईडी
समूह	पूर्णांक	समूह आईडी

group_members - समूह के सदस्य
us_id	पूर्णांक	उपयोगकर्ता
समूह	पूर्णांक	समूह आईडी

इस प्रकार, निम्नलिखित क्वेरी का उपयोग करके रिकॉर्ड चुने गए हैं:

SELECT DISTINCT `records`.`id` , `records`.`name` 
      

        
        
        
      

     FROM `records` , `record_permissions` , `group_members` 
      

        
        
        
      

     WHERE `records`.`public` =0 
      

        
        
        
      

     
      

        
        
        
      

     AND `records`.`id` = `record_permissions`.`record_id` 
      

        
        
        
      

     AND `record_permissions`.`group_id` = `group_members`.`group_id` 
      

        
        
        
      

     AND `group_members`.`us_id` =$us_id

सिद्धांत रूप में, पूरी तस्वीर इस रूप में सही है, लेकिन यह करने योग्य नहीं है।

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

समाधान की सादगी और लालित्य के बावजूद, इसमें महत्वपूर्ण कमियां हैं, जिनके बारे में नीचे चर्चा की जाएगी, उसी स्थान पर मैं समाधान दिखाने की कोशिश करूंगा।

सार्वजनिक रिकॉर्ड।

एक शौकीन चावला पाठक ने पहले ही हमारे तर्क में एक अंतर देखा है: केवल उस उपयोगकर्ता को जिसे रिकॉर्ड पढ़ने की अनुमति है।

डिफ़ॉल्ट रूप से, ज्यादातर मामलों में, रिकॉर्ड खुले होते हैं, और कोई भी उन्हें पढ़ सकता है।

आप इसे लेफ्टिनेंट जॉइन के साथ एक कठिन क्वेरी के साथ हल कर सकते हैं, लेकिन अंत में हमारे पास जॉइन टेबल पर एक शर्त है, जो सार्वभौमिक बुराई है।

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

इसलिए, हम रिकॉर्ड के लिए एक नई संपत्ति पेश करते हैं: जनता, यह हमें अनुमति देगा:

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

बाइनरी मास्क।

यहां तक कि अंतिम प्रश्न में, खराब शब्द DISTINCT का उपयोग किया जाता है, और चयन तीन तालिकाओं पर जाता है, और यहां तक कि एक से कई रिश्तों के साथ, यह परेशान नहीं कर सकता है।

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

उपयोगकर्ता केवल अपने समूहों के लिए प्रविष्टियाँ खोल सकता है।

कुछ लोगों को "वास्या के दोस्तों" के लिए अपने रिकॉर्ड खोलने की आवश्यकता हो सकती है, और इस मामले में इंटरफ़ेस स्तर पर ऐसा करना आसान नहीं होगा।
उपयोगकर्ता के पास सीमित संख्या में समूह हो सकते हैं।

एक व्यक्ति 5 objects 2 वस्तुओं को याद कर सकता है, बड़ी संख्या में समूहों में कुछ भी समझने की तुलना में भ्रमित होना आसान है।

इसके आधार पर, हम तालिकाओं की संख्या घटाकर दो कर देते हैं:

रिकॉर्ड - रिकॉर्ड
आईडी	पूर्णांक	अभिलेख
us_id	पूर्णांक	उपयोगकर्ता
पहुंच	पूर्णांक	एक्सेस मास्क
सार्वजनिक	bool	सार्वजनिक रिकॉर्ड ध्वज

user_references- उपयोगकर्ता संबंध
us_id	पूर्णांक	उपयोगकर्ता
cor_id	पूर्णांक	लिंक किया गया उपयोगकर्ता
मुखौटा	पूर्णांक	रिश्ते का मुखौटा

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

यानी एक समूह मुखौटा के प्रत्येक बिट से मेल खाता है, इंट में हमारे 32 बिट्स हैं, इसलिए समूहों की संख्या 32 तक सीमित है (कई बिट्स आरक्षित हो सकते हैं)।

एक उदाहरण है।

उपयोगकर्ता संबंध :

मित्र	परिवार	सहयोगियों	उपयोगकर्ता	कुल मिलाकर
1	0	0	मित्र	1
0	1	0	मां	2
0	0	1	सहयोगी	4
1	0	1	साथी मित्र	5

रिकॉर्ड तक पहुंच :

मित्र	परिवार	सहयोगियों	अभिलेख	कुल मिलाकर
0	0	0	केवल मैं	0
0	1	0	नमस्कार माँ!	2
0	0	1	काम कर रहे	4
1	1	0	मैं छोड़ना चाहता हूँ!	3

इस प्रकार, यह पता लगाना संभव है कि क्या किसी उपयोगकर्ता के पास बिटकॉइन "और" मास्क पर प्रदर्शन करके रिकॉर्ड पढ़ने का अधिकार है या नहीं। बिटवाइज़ ऑपरेशन तेज़ हैं क्योंकि सब कुछ उन पर आधारित है।

इस प्रकार, अनुरोध इस तरह दिखता है:

SELECT `records`.`id` , `records`.`name` 
      

        
        
        
      

     FROM `records` , `user_references` 
      

        
        
        
      

     WHERE `records`.`public` =0 
      

        
        
        
      

     AND `records`.`us_id` = `user_references`.`us_id` 
      

        
        
        
      

     
      

        
        
        
      

     AND `records`.`access` & `user_references`.`mask` 
      

        
        
        
      

     AND `user_references`.`cor_id` =$us_id

या सार्वजनिक क्षेत्र पर विचार करना:

SELECT `records`.`id` , `records`.`name` 
      

        
        
        
      

     FROM `records` , `user_references` 
      

        
        
        
      

     WHERE `records`.`public` =0 
      

        
        
        
      

     AND `records`.`us_id` = `user_references`.`us_id` 
      

        
        
        
      

     
      

        
        
        
      

     AND `records`.`access` & `user_references`.`mask` 
      

        
        
        
      

     AND `user_references`.`cor_id` =$us_id 
      

        
        
        
      

     UNION 
      

        
        
        
      

     SELECT `records`.`id` , `records`.`name` 
      

        
        
        
      

     FROM `records` 
      

        
        
        
      

     
      

        
        
        
      

     WHERE `public` =1

परीक्षण।

परीक्षण के दौरान, समाधान के प्रदर्शन की तुलना उपयोगकर्ता समूहों और बिट मास्क के साथ समाधान के साथ की गई थी।

जैसा कि हम देखते हैं कि लाभ बहुत पर्याप्त है, जो कि उत्तरार्द्ध विधि द्वारा लगाए गए प्रतिबंधों को सही ठहराता है।

अलग से, मैं कहूंगा कि एक वास्तविक परियोजना पर, एक एसीएल (इन-हाउस डेवलपमेंट) का उपयोग किया जाता है, जो उचित मात्रा में संसाधनों को खाता है और डेवलपर्स के लिए महत्वपूर्ण कठिनाइयों का निर्माण करता है।

स्थिति	नकाब (सेक) द्वारा	समूहों (सेकंड) द्वारा	समय पर गति
MySql 4, 30,000 रिकॉर्ड, 100 उपयोगकर्ता, 1000 लिंक, UNION	.००,२१५	0.0107	4.98
MySql 4, 500,000 रिकॉर्ड, 10,000 उपयोगकर्ता, 100,000 लिंक	.००,१८५	0.1346	72.76
MySql 4, 500,000 रिकॉर्ड, 10,000 उपयोगकर्ता, 100,000 यूनिअन लिंक	.००,२१५	0.1383	64.33
MySql 5, 500,000 रिकॉर्ड, 10,000 उपयोगकर्ता, 100,000 लिंक	.००,१३५	0.169	125.19

नमूनाकरण समय 4 से अधिक मैन्युअल रूप से बनाए गए उपयोगकर्ताओं के लिए औसत है। अन्य सभी उपयोगकर्ता स्वचालित रूप से बनाए गए थे, ऐसे प्रत्येक उपयोगकर्ता के पास 10 दोस्त और 10 "दोस्तों के लिए" प्रविष्टियां थीं

जैसा कि परिणामों से देखा जा सकता है, नमूने की दर परिमाण के 2 आदेशों से भिन्न होती है, जबकि तालिकाओं के साथ समाधान विस्तार योग्य है, नमूना दर रिकॉर्ड की संख्या पर बहुत कम निर्भर है

यह ध्यान दिया जाना चाहिए कि यदि उपयोगकर्ता दो समूहों ("मित्र" और "सहकर्मियों") में है, तो यह मुखौटा के साथ नमूना गति को प्रभावित नहीं करता है। और समूहों द्वारा चयन (DISTINCT सक्रिय है) कई सेकंड (डरावनी डरावनी) लेता है, मैंने इसे पिवट टेबल में भी इस्तेमाल नहीं किया था।

परिणाम।

यह पता चला है कि अधिकार प्रणाली के प्रदर्शन को बेहतर बनाने के लिए, आप अतिरिक्त आसानी से अनुक्रमित उपकरण बना सकते हैं।

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

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

बहु-उपयोगकर्ता सेवाओं में अनुक्रमण अधिकार।