क्या आपको अपने प्राधिकरण को लागू करने के लिए वास्तव में सौंपने या लार्वा-अनुमति की आवश्यकता है?

"तो" मुझे एक साधारण प्राधिकरण की आवश्यकता है। किसी प्रकार की व्यवस्थापक भूमिका, और शायद संपादक / मॉडरेटर की भूमिका। अब इसे google करें। ओह! लार्वा के लिए पहले से तैयार पैकेज हैं! zizaco / सौंपना , स्पाटी / लार्वा-अनुमति और अन्य! चलो कुछ चुनें! ”

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

मैं उन कुछ परियोजनाओं से मिला जहाँ उत्पादन डेटाबेस में नियमों की एक मुख्य प्रति थी और बाकी सब कुछ वहाँ से कॉपी किया था।

सीडर वर्ग ( उदाहरण ) का उपयोग करने का विचार बहुत बेहतर है। आपको बस चलाने की जरूरत है

php artisan db:seed AuthSeeder

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

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

 ['middleware' => ['permission:edit posts']] 

डेवलपर्स को मानक लार्वा प्राधिकरण का उपयोग करना चाहिए:

 class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } } 

तो शायद सबसे आसान तरीका सबसे अच्छा नहीं है?

यह सिर्फ सरल दिखता है: पैकेज रखो, समाप्त प्रवास चलाएं और जाएं। दीर्घकालिक परियोजना समर्थन के दृष्टिकोण से, यह सबसे अच्छा विकल्प नहीं है।

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

 class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} } 

अब परमीशन। लारवेल उन्हें वर्णन करने के लिए दो बुनियादी तरीके प्रदान करता है: गेट्स और नीतियां । मैं गेट्स का उपयोग करूँगा (एक चर में एक फ़ंक्शन के साथ अभी भी एक छोटी सी चाल है, लेकिन कार्यात्मक प्रोग्रामिंग के प्रेमियों के लिए यह बिल्कुल भी चाल नहीं है):

  $isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin); // Complex permission Gate::define('edit-post', function(User $user, Post $post) { return $user->id == $post->owner_id || $user->isAdmin(); }); 

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

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

डेल्फी के लिए पैकेज के साथ स्थिति डेल्फी के लिए घटकों के साथ स्थिति के समान हो जाती है (पुराने लोगों को याद है)। उन्होंने बिना किसी हिचकिचाहट के पैकेज लगाए - वास्तव में जरूरत है या नहीं।

इसलिए, मुझे अपने प्रोजेक्ट में $ + $ b की गणना यहाँ करनी होगी। क्या कोई लार्वा-सम पैकेज है?

PS मैं अनुमतियों के लिए माफी माँगता हूँ, लेकिन मुझे एक अच्छा सटीक अनुवाद नहीं मिला।