🕰️ 🌔 👨🏻‍💻 एक्स-एक्ल एक्सेस कंट्रोल लिस्ट (एसीएल) लाइटवेट यूटिलिटी 👩‍🎤 ⚜️ 🖨️

अभिवादन, हाबरा समुदाय!

प्रत्येक परियोजना (वेब प्रोजेक्ट) में एक्सेस अधिकारों के आयोजन के बारे में प्रश्न हैं। इस क्षेत्र में कुछ तैयार किए गए उपकरण हैं जो विभिन्न फ्रेमवर्क Zend, Symfony, Yii, आदि के लिए हैं। संभवत: कोई व्यक्ति किसी चीज के पार आया है और सामान्य रूप से कल्पना करता है कि यह क्या है। उन लोगों के लिए जो पूरे नहीं आए हैं - मैं आपको सलाह देता हूं कि आप इनमें से किसी भी फ्रेमवर्क के दस्तावेज़ खोलें और खुद को परिचित करें। विशेष रूप से, पोस्ट के लेखक ने Zend_Acl के साथ मिलकर काम किया। लेकिन अपेक्षाकृत हाल ही में मैंने C ++ के क्षेत्र में ACL के मुद्दे का अध्ययन करने का निर्णय लिया

तो यह सब कहां से शुरू हुआ ...

यह सब बहुत सरलता से शुरू हुआ, एक अच्छा भार के साथ एक स्व-लिखित परियोजना है (नैतिक कारणों के लिए, इसका नाम नहीं कहा जाता है, ऐतिहासिक कारणों के लिए स्व-लिखित, 200K अद्वितीय)। परियोजना, जैसा कि ज्यादातर मामलों में "परंपरा तय करती है", php में लिखी गई है। इसमें पहुंच सूची का संगठन, जैसे कि, अनुपस्थित है - क्या "भूमिका", क्या करना है के मामले में सामान्य सशर्त ऑपरेटर हैं। ये बैसाखी समाधान, सिद्धांत रूप में, काम करते हैं, लेकिन बहुत खुश नहीं हैं। खोज और सामान्य ज्ञान के साथ सशस्त्र, एक छोटी, हल्की सी ++ उपयोगिता बनाने का निर्णय लिया गया, जिसे मैं समुदाय के साथ साझा करना चाहूंगा।

विशेषाधिकार कॉन्फ़िगर करें

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

[guest]
view:news
view:comments

जहां [अतिथि] उपयोगकर्ता की भूमिका है, और देखें: समाचार और दृश्य: टिप्पणियां संबंधित संसाधन हैं। कई लोगों में रुचि हो सकती है, उदाहरण के लिए, एक संसाधन को टिप्पणी नहीं कहा जाता है: दृश्य, लेकिन इसके विपरीत दृश्य: टिप्पणियां - जवाब सरल है, यदि आप सीआरयूडी के अनुसार सशर्त रूप से संसाधनों को विभाजित करते हैं, तो आप समझेंगे कि आप इतने सारे विकल्पों के बारे में नहीं सोच सकते हैं, इसलिए आप तुरंत नेत्रहीन द्वारा भूमिकाओं को देख सकते हैं। यह देखने के लिए कि कौन देख रहा है, कौन अपडेट कर रहा है, आदि इसके अलावा, इस प्रारूप में ऐसा करना संभव हो जाता है:

[guest]
view:*

जिसका अर्थ है कि मेहमानों को सब कुछ देखने की अनुमति है।
सरल, सही?

चौकस पाठक, जाहिर है, पहले से ही यह नोटिस करने में कामयाब रहा है कि संसाधन के नाम पर कोलन प्रतीक मौजूद है। यह एक सशर्त अनिवार्य विभाजक है जिसके साथ आप ये चीजें कर सकते हैं:

[moderator]
edit:*:comments

#
edit:news:comments
edit:wall:comments

उपयोगिता संसाधनों के एक समूह को लागू नहीं करती है और आप समूह को फिट कर सकते हैं जैसा कि आप फिट देखते हैं और आपकी परियोजना के लिए सबसे उपयुक्त है। लेकिन उपसमूहों के बीच एक बृहदान्त्र की उपस्थिति आपको संसाधन के घटकों को अधिक तार्किक रूप से अलग करने की अनुमति देती है।

एक सरल संकल्प दिलचस्प नहीं है, जाहिर है हम कुछ संसाधनों तक पहुंच से भी इनकार कर सकते हैं:

[user]
view:news:28 = deny

इस नियम के साथ, हमने उपयोगकर्ता को ID 28 के साथ समाचार देखने से रोका
प्रत्येक व्यक्तिगत भूमिका के लिए नियमों का वर्णन करना बहुत थकाऊ है, इसलिए एक विरासत तंत्र है:

[user : guest]

इस मामले में, उपयोगकर्ता की भूमिका, इसके नियमों के अलावा, अतिथि भूमिका से भी नियम शामिल होंगे

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

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

[user]
edit:comment:^

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

यह कैसे काम करता है

जैसा कि ऊपर उल्लेख किया गया है, यह एक उपयोगिता है। तदनुसार, इसके सफल संकलन के बाद, आप इसे कंसोल में चला सकते हैं:

./x-acl --config x-acl.conf --group guest --resource view:news

हम पूछते हैं कि क्या अतिथि उपयोगकर्ता के पास दृश्य: समाचार संसाधन है

./x-acl --config x-acl.conf --group user --resource edit:comment:28 \
--user-id 4 --owner-id 4

हम पूछते हैं कि क्या उपयोगकर्ता की भूमिका संपादित करने के लिए उपयोग की गई है: टिप्पणी: 28 संसाधन, यदि कोई भूल गया, तो हम नियम को संपादित करते हैं: टिप्पणी: ^, - इस मामले में, ^ प्रतीक है, इसलिए उपयोगकर्ता-आईडी और स्वामी-आईडी तर्क समानता की जांच कर रहे हैं, और यदि वे हैं बराबर (और वे इस उदाहरण में समान हैं) - पहुंच की अनुमति होगी।

डाउनलोड करने और खेलने के लिए कहाँ

github.com/AlexeyParhomenko/x-acl

संदिग्ध मुद्दों की सूची :)

- अगर आपके पास तैयार उपकरण हैं तो अपनी बाइक को क्यों मजबूत करें?

लेखक कुछ से परिचित है। एक नया उपकरण बनाएँ
1. हमारी जरूरतों के लिए और अधिक लचीला बनाओ;
2. मेमोरी खपत पर लाभ उठाएं, क्योंकि इस मामले में, php के विपरीत, भारी Zval संरचनाओं का निर्माण नहीं होता है;
3. गति में लाभ उठाना। जब हम परीक्षण कर रहे हैं, लेकिन अगर यह हर बार कॉन्फ़िगरेशन को पार्स करने के लिए तनावपूर्ण हो जाता है, तो हम सॉकेट समाधान पर स्विच करने में सक्षम होंगे;

- क्या आप आगे समर्थन की योजना बनाते हैं और बग को ठीक करते हैं?

स्वाभाविक रूप से।

- किस ओएस के लिए यह काम करता है?

हमारे सर्वर पर डेबियन का उपयोग किया जाता है, जैसा कि लेखक काम के माहौल के रूप में उपयोग करता है, इसलिए मैं यह सुनिश्चित करने के लिए कहता हूं कि डेबियन ठीक काम करता है। अन्य * निक्स वितरण पर, यह भी महत्वपूर्ण रूप से काम करना चाहिए।

टिप्पणियां बहुत स्वागत योग्य हैं, क्योंकि मैं यह समझना चाहूंगा कि यह उपकरण भविष्य में कितना उपयोगी हो सकता है। या, यदि मैंने खराब तरीके से खोजा और पहले से वर्णित कार्यक्षमता उपलब्ध है - तो इसे Google को भेजें!

मुझे पाठ या स्रोत कोड में पीएम, या, शायद, कुछ आगे की इच्छाओं में देखी गई त्रुटियों / अशुद्धियों को सुनने में खुशी होगी।

एक्स-एक्ल एक्सेस कंट्रोल लिस्ट (एसीएल) लाइटवेट यूटिलिटी