Django-guardian: user.has_perm("perm", obj) अनपेक्षित रूप से व्यवहार करता है

मैंने थोड़ा और पता लगाया और पाया कि प्रत्येक अनुमति बैकएंड को स्वतंत्र रूप से काम करना चाहिए, इसलिए जैसा कि मैंने ऊपर वर्णित किया है, कोई स्थिति नहीं होनी चाहिए। लेकिन किसी कारण से user.has_perm ऑब्जेक्ट इंस्टेंस प्रदान करना, केवल ऑब्जेक्ट स्तर अनुमतियों की जांच करना चाहता है, और वैश्विक अनुमति जांच को छोड़ देता है। मुझे नहीं पता, उस व्यवहार का कारण क्या है। मैं Django 1.2.5 का उपयोग कर रहा हूँ।

अरे, क्या आप अपनी _AUTHENTICATION_BACKENDS_ सेटिंग पेस्ट कर सकते हैं?

जैसा कि आप पहले ही Django दस्तावेज़ पढ़ चुके हैं, आप जानते हैं कि निर्दिष्ट बैकएंड का क्रम महत्वपूर्ण है ।

मुझे लगता है कि आपके पास अपने आवेदन में निम्नलिखित जैसा कुछ है:

AUTHENTICATION_BACKENDS = (
    'guardian.backends.ObjectPermissionBackend',
    'django.contrib.auth.backends.ModelBackend',
)

या यह:

from django.conf import global_settings
AUTHENTICATION_BACKENDS = (
    'guardian.backends.ObjectPermissionBackend',
) + global_settings.AUTHENTICATION_BACKENDS

बस सुनिश्चित करें कि डिफ़ॉल्ट बैकएंड पहले निर्दिष्ट किया गया है।

क्या आप पुष्टि कर सकते हैं कि यह मुद्दा है? यदि नहीं, तो कृपया कुछ और जानकारी जोड़ें (हो सकता है कि आप कुछ अन्य बैकएंड का भी उपयोग करें, या कुछ अन्य ऐप बंदर पैच जो _User.has_perm_ विधि?)

ठीक है, लगता है मैं बहुत थक गया हूँ। आदेश _has_perm_ परिणाम को प्रभावित नहीं करना चाहिए। इसलिए कृपया आपके द्वारा उपयोग की जा रही एप्लिकेशन सेटिंग के बारे में अधिक जानकारी जोड़ें। इसके अतिरिक्त, आप परीक्षण सूट (_python manage.py test Guardian_) चलाकर सुनिश्चित कर सकते हैं कि अभिभावक ठीक से काम करता है।

ओह, ठीक है, मैंने आपकी समस्या को एक बार और पढ़ा है। डिफ़ॉल्ट _auth.ModelBackend_ _supports_object_permissions_ का समर्थन नहीं करता (वह विशेषता _False_ है)। Django दस्तावेज़ों के मुताबिक, वे 1.4 से डिफ़ॉल्ट बैकएंड के लिए उस समर्थन को जोड़ देंगे।

तो, आपकी स्थिति के लिए, व्यवहार बिल्कुल सही और अपेक्षित है। डिफ़ॉल्ट बैकएंड को बस छोड़ दिया जाता है।

अपने ऐप में ऑब्जेक्ट स्तर की अनुमतियों की जांच करने से पहले आपको वैश्विक अनुमतियों की जांच करनी चाहिए। यह सबसे आसान उपाय है जिसके बारे में मैं सोच सकता हूं।

_invalid_ के रूप में बंद, हालांकि यदि आप इसे नई टिप्पणी के साथ फिर से खोलना चाहते हैं - ऐसा करने के लिए स्वतंत्र महसूस करें!

ठीक है, लगता है आप सही कह रहे हैं। लेकिन वैश्विक अनुमतियों की जाँच नहीं करना मेरे लिए कुछ गंभीर कठिनाइयाँ लाता है। उदाहरण के लिए guardian.decorators.permission_required में, जैसा कि मैंने माना, अतिरिक्त ऑब्जेक्ट स्तर अनुमति जांच के साथ सामान्य django.contrib.auth.decorators.permission_required की कार्यक्षमता का विस्तार करना चाहिए।
समस्या यह है कि मेरे पास एक कामकाजी अनुप्रयोग है जो वैश्विक अनुमतियों का उपयोग करता है, और मैं इसमें कुछ अतिरिक्त ऑब्जेक्ट स्तर अनुमतियां जोड़ना चाहता था, इसलिए मैंने डिफ़ॉल्ट permission_required डेकोरेटर्स को django-guardian से ऑब्जेक्ट स्तर वाले में बदल दिया है, लेकिन तब उपयोगकर्ताओं ने वैश्विक अनुमतियों के आधार पर अपने एक्सेस अधिकार खो दिए थे।

मेरे लिए एक अप्रत्याशित व्यवहार की तरह लगता है, क्या आप कम से कम इस मामले को दस्तावेज़ीकरण में जोड़ सकते हैं, क्योंकि यह कोड को देखे बिना स्पष्ट नहीं है।

मेरे लिए, यह एक डिज़ाइन दोष है, जिसके परिणामस्वरूप पूरे कोड में अतिरिक्त जाँच होती है जहाँ मुझे विश्व स्तर पर और प्रति-वस्तु दोनों की अनुमति को सत्यापित करने की आवश्यकता होती है।

@ कौयगुलांट : यह वास्तव में Django के लेख से _extend_ सज्जाकारों के लिए लचीला नहीं होगा। यह ऐप _ऑब्जेक्ट अनुमतियों_ को लागू करने का इरादा रखता है, न कि मूल को विस्तारित करने के लिए। यानी क्या होगा यदि आप किसी अन्य ऐप का उपयोग करना चाहते हैं जो केवल अभिभावक और ऑब्जेक्ट स्तर अनुमतियों का उपयोग करता है? क्या होगा यदि आप केवल व्यवस्थापक पर वैश्विक अनुमतियों का उपयोग करना चाहते हैं, और नियमित उपयोगकर्ताओं को दिए गए ऐप्स में ऑब्जेक्ट स्तर की अनुमतियों का उपयोग करना चाहते हैं? क्या होगा यदि उपयोगकर्ता को ऑब्जेक्ट पर कुछ कार्रवाई करने में सक्षम होने के लिए ऐप को वैश्विक अनुमति और ऑब्जेक्ट स्तर की अनुमति दोनों की आवश्यकता होगी? ऐसे कई मामले हैं, अभिभावक उन सभी को कवर नहीं करेंगे।

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

यह मेरे लिए उपयोगी होगा, अगर केवल एक और अनुमति_आवश्यक डेकोरेटर जोड़ा गया था, जो ऑब्जेक्ट स्तर अनुमतियों और वैश्विक दोनों की जांच करता है। वह मेरे मुद्दे को कवर करेगा।

@Dzejkob , क्या आप कृपया अंतिम प्रतिबद्धता देख सकते हैं और कह सकते हैं कि यह पर्याप्त होगा (मैंने वैश्विक अनुमति स्वीकार करने के लिए ध्वज जोड़ा है)। साथ ही, मुझे बताएं कि सजावटी पर डॉकस्ट्रिंग का विस्तार करना पर्याप्त है, या क्या मुझे और उदाहरण/अधिक वर्णनात्मक दस्तावेज़ जोड़ना चाहिए?

नोट: प्रतिबद्धता नई शाखा में है: _feature/add-accept_global_perms-flag-for-decorators_

@lukaszb हां, मैंने अपने प्रोजेक्ट में गार्जियन का नया शाखा संस्करण स्थापित किया है, permission_required डेकोरेटर्स accept_global_perms=True में जोड़ा गया पैरामीटर, और ऐसा लगता है कि इसे काम करना चाहिए। तो इस सुविधा को बनाने के लिए धन्यवाद। मुझे लगता है कि इसे ट्रंक में विलय करना अच्छा विचार है।
दस्तावेज़ों के बारे में, वे मेरे लिए बिल्कुल स्पष्ट हैं, इसलिए मुझे लगता है कि यह पर्याप्त है।

यह बहुत समय पहले तय किया गया था।

हैलो, मुझे यह समस्या मिली क्योंकि मैं जांगो-अभिभावक की कोशिश कर रहा हूं और मुझे यह व्यवहार छोटा/बहुत भ्रमित करने वाला लगा।

मैंने एक उपयोगकर्ता के लिए एक वैश्विक अनुमति (चलिए इसे view_user कहते हैं) जोड़ा (चलिए इसे joe कहते हैं) और फिर जाँच की कि क्या जो एक विशिष्ट उपयोगकर्ता को देख सकता है (चलिए इसे other_user कहते हैं) ) और आश्चर्यजनक रूप से यह False लौटा।

joe = User.objects.get(username="joe")
other_user = User.objects.get(username="other_user")
assign_perm("myapp.view_user", joe)
joe.has_perm("myapp.view_user") # True as expected
joe.has_perm("myapp.view_user", other_user) # False, whaaaat?

अब, मैं स्पष्ट रूप से permission_required डेकोरेटर का उपयोग नहीं कर रहा हूं क्योंकि मेरे व्यू सेट "स्वचालित रूप से" मेरे REST_FRAMEWORK/DEFAULT_PERMISSION_CLASSES और AUTHENTICATION_BACKENDS settings.py में अनुमतियों की जांच कर रहे हैं। . मैं अभिभावक से अपेक्षा के अनुरूप व्यवहार करने के लिए कैसे कहूं?

(क्षमा करें अगर मुझे वास्तव में बेवकूफ कुछ याद आ रहा है, तो यह djangoland में दिन 2/3 है)

आज के शोर के लिए क्षमा करें, इससे भी अधिक दिलचस्प/भ्रमित करने वाला कि guardian.shortcuts.get_objects_for_user() डिफ़ॉल्ट रूप से प्रामाणिक/वैश्विक अनुमतियों का सम्मान करता है ( accept_global_perms )।

accept_global_perms: if True takes global permissions into account. 
[...]
Default is True.

हालाँकि, इस मुद्दे को दूसरे के पक्ष में बंद कर दिया गया था, यहाँ बहुत सारी अंतर्दृष्टि हैं, इसलिए मैं यहाँ बातचीत को फिर से उत्तेजित करने के लिए लिख रहा हूँ। अजगर के ज़ेन कहते हैं:

इसे करने का एक स्पष्ट तरीका होना चाहिए - और अधिमानतः केवल एक -।

और मेरे लिए यह है कि जब स्थानीय (ऑब्जेक्ट स्तर) निर्दिष्ट नहीं है तो वैश्विक पर _फॉलबैक करें। आदेश परिणाम नहीं बदलता है (चूंकि Django returns False if obj is not None ), लेकिन प्रदर्शन बदल सकता है।

मैं इस बात से सहमत हूं कि पूरे कोड पर दोहरी जांच करना एक अच्छा डिज़ाइन नहीं है, और कुछ अर्थों में DRY सिद्धांत के विरुद्ध भी है। हालांकि, Django डिफ़ॉल्ट बैकएंड के भीतर उपलब्ध अभिभावक कार्यान्वयन कार्यक्षमता DRY भी नहीं है। वह Django कई बैकएंड की अनुमति देता है, और क्रम में एक-एक करके जांचना इंगित करता है कि बैकएंड को एक साथ खेलना चाहिए, एक दूसरे को प्रतिस्थापित नहीं करना चाहिए। अगर यह सही है, तो Django जब obj is not None _गलत_ है तो ग्लोबल्स की जांच करने से इनकार कर रहा है। यदि Django ने obj को अनदेखा कर दिया, तो यह ऑब्जेक्ट चेकर्स के लिए वैश्विक फ़ॉलबैक हो सकता है।

मुझे लगता है कि हमें Django के साथ एक टिकट खोलना चाहिए, यह पूछते हुए कि क्या और कैसे, प्राधिकरण बैकएंड एक दूसरे के साथ खेलते हैं, और फिर वहां से चले जाते हैं।

ऐसा कहा जा रहा है, मुझे लगता है कि Django अपने व्यवहार को बदलना काफी असंभव है (हालांकि मुझे अभी भी लगता है कि हमें पूछना चाहिए), इसलिए यथास्थिति इंगित करती है कि अभिभावक को दोनों को प्रदान करने में सक्षम होने के लिए विकसित होना चाहिए (जो कि वांछित है) सेटिंग्स या फ़ंक्शन के तर्क के माध्यम से या तो सेट किया जा सकता है)। लेकिन मुझे लगता है कि डिफ़ॉल्ट व्यवहार _स्थानीय फ़ॉलबैक से वैश्विक होना चाहिए जब बोर्ड भर में false_ हो।

अगर Django एक त्रि-राज्य अनुमति प्रणाली पसंद करता है तो मैं इसे पसंद करूंगा: सच, गलत, और कोई नहीं। उस स्थिति में, स्थानीय चेकर्स False के माध्यम से ग्लोबल्स को _override_ कर सकते हैं; और None के माध्यम से प्रत्येक बैकएंड कह सकता है: "मुझे यह नहीं पता, अगली पंक्ति में पूछें"। उस स्थिति में, Django बैकएंड में से एक में True or False प्राप्त करने के बाद जाँच करना बंद कर देगा, और प्रसंस्करण शक्ति को बर्बाद करना बंद कर देगा।

यह प्रत्येक बैकएंड को अधिक शक्ति देगा: एक निश्चित उत्तर दे सकता है, या दूसरों को संदर्भित कर सकता है।

@doganmeh Django एक त्रि-राज्य अनुमति प्रणाली लागू करता है (कम से कम 1.10 के रूप में)। विकल्प सही हैं, कोई नहीं, और अनुमति अस्वीकार कर रहे हैं। बाद में ऐसा करने से Django जांच करना बंद कर देगा और झूठी वापसी करेगा।

जहां तक ​​इस मुद्दे की बात है, मेरा मानना ​​है कि यह एक Contrib.Auth मुद्दा है। वह बैकएंड है जो 'वैश्विक अनुमतियों' से संबंधित है। समस्या यह है कि उन्होंने एक अप्रत्यक्ष सम्मेलन स्थापित किया है जिसमें obj के साथ has_perm = कोई भी केवल 'तालिका अनुमतियों' की जांच नहीं करता है और obj के साथ has_perm केवल 'पंक्ति अनुमतियां' की जांच करता है। वे इसे बदलने की संभावना नहीं रखते हैं, लेकिन दोनों की जांच का समर्थन करने के लिए अपने एपीआई को विस्तारित करने के लिए खुले रहें।

(कम से कम मुझे उम्मीद है कि वे दोनों को जांचने के लिए व्यवहार जोड़ने के लिए खुले होंगे। यह उनके सिस्टम में एक स्पष्ट दोष लगता है।)

'दोनों जांचें' एपीआई के लिए आपके क्या सुझाव होंगे? मैं जो सबसे अच्छा सोच सकता हूं वह एक क्वार्ग है।

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

@airstandley मुझे लगता है कि आपका मतलब user.has_perm में kwarg जोड़ना है जैसे कि:

def has_perm(self, perm, obj=None, fallback=False)

मुझे लगता है कि इससे मदद मिलेगी। मामले में जब fallback=True , अभिभावक Django बैकएंड को कॉल करेगा और वैश्विक लौटाएगा। अगर मेरे पास कोई विकल्प था, हालांकि, मैं पसंद करूंगा कि Django को स्वाभाविक रूप से ढांचे द्वारा नियंत्रित किया जाए, न कि उसके आंतरिक को अपहरण करके।

@doganmeh क्षमा करें मैं गलत बोल रहा हूँ। इसे "सत्य, गलत , और अनुमति देने से इनकार करना चाहिए" पढ़ना चाहिए था। नहीं:

विकल्प सही हैं, कोई नहीं, और अनुमति नहीं दी गई है

बाद में मैं अपने सिर में रिटर्न के बारे में सोचता हूं ...

मुझे लगता है कि मैंने भी गलत समझा होगा कि आपका क्या मतलब है

अगर Django एक त्रि-राज्य अनुमति प्रणाली को प्राथमिकता देता है तो मैं इसे पसंद करूंगा

स्पष्ट करने के लिए, आप विशेष रूप से अनुमति मॉडल कार्यान्वयन के बारे में बात कर रहे थे, न कि पूरे सिस्टम के बारे में?

मेरा कहना था कि ऑथ बैकएंड सिस्टम आपके द्वारा वर्णित सटीक शॉर्ट-कटिंग की अनुमति देता है (कम से कम has_perm , has_module_perms api के लिए)। यह स्पष्ट है, यदि सीधा नहीं है:
कोई भी बैकएंड या तो स्वयं निर्णय ले सकता है (रिटर्न ट्रू या परमिशन अस्वीकृत), या निर्णय को श्रृंखला में अगले समर्थित (रिटर्न गलत) को सौंप सकता है। यह एक कार्यान्वयन विशिष्ट निर्णय है, न कि सिस्टम की गुणवत्ता।

एक स्पष्ट ObjectPermissionBackend मेरी परियोजना के लिए एक मुद्दा होगा, इसलिए मैं स्पष्ट नहीं होना चुनूंगा। ("स्पष्टता" अन्य अनुमति जाँच बैकएंड के साथ एकीकरण को बोझिल बना देती है।) मुझे संदेह है कि, आप की तरह, अन्य लोग इसे स्पष्ट करना पसंद करेंगे। तो सेटिंग के रूप में 'स्पष्टता' होने से मुझे समझ में आता है।

@doganmeh
तो क्वार्ग के बारे में।

सबसे पहले मैं चिंता करता रहता हूं कि हम एक ही पृष्ठ पर नहीं हैं कि कैसे ऑथ के बैकएंड सिस्टम के व्यवहार का उद्देश्य काम करना था। तो स्पष्ट होना:
मेरी समझ यह है कि इरादा यह था कि बैकएंड एक साथ काम करें। यदि कोई ऐप ऑथ की अनुमति प्रणाली (यानी 'वैश्विक अनुमतियां' का उपयोग करना चाहता है, हालांकि तकनीकी रूप से वे 'टेबल अनुमतियां' होंगे लेकिन आलू, आलू) यह AUTH_BACKENDS में ऑथ मॉडलबैकएंड स्थापित करेगा। यदि वह ऐप अभिभावक की ऑब्जेक्ट अनुमति प्रणाली (यानी 'पंक्ति अनुमति') का उपयोग करना चाहता है, तो यह AUTH_BACKENDS में अभिभावक का ऑब्जेक्ट अनुमति बैकएंड नहीं होगा।
ModelBackend वैश्विक अनुमति को संभालेगा।
ऑब्जेक्टप्रमिशनबैकएंड ऑब्जेक्ट अनुमतियों को संभालेगा।
यदि किसी उपयोगकर्ता के पास केवल ऑब्जेक्ट अनुमति होती है, तो ModelBackend has_perm के लिए कभी भी True नहीं लौटाएगा। यदि किसी उपयोगकर्ता के पास केवल वैश्विक अनुमति थी ObjectPermissionBackend has_perm के लिए कभी भी True नहीं लौटाएगा। दोनों ही मामलों में user.has_perm(perm, obj) को कॉल अभी भी सही होनी चाहिए, क्योंकि उपयोगकर्ता के पास स्थापित बैकएंड के _one_ के लिए अनुमति है। (यही कारण है कि हम एक समस्या का सामना कर रहे थे क्योंकि मॉडलबैकएंड इस खाते पर विफल रहता है)

ठीक है तो वह सब दिया।

एक आदर्श दुनिया में जहां संगतता कोई मुद्दा नहीं था, मैं भी contrib.auth के ModelBackend में एक साधारण बदलाव पसंद करूंगा। ModelBackend.has_perm(user_obj, perm, obj=None) अगर उपयोगकर्ता के पास परमिट द्वारा निर्दिष्ट 'वैश्विक अनुमति' है तो सही वापस आना चाहिए; भले ही obj कोई नहीं है या नहीं।

हालांकि संगतता एक मुद्दा है, इसलिए मैं पूछता हूं कि क्या आपके पास इस मुद्दे का समाधान है।

केवल _backwardsसंगत_ समाधान जिनके बारे में मैं सोच सकता हूं, वे या तो API में kwarg जोड़ सकते हैं या AUTH सेटिंग जोड़ सकते हैं।

तो kwargs:
आइए इसे obj_shortcut कहते हैं क्योंकि यह सबसे अच्छा है जो मैं अपने सिर के ऊपर से लेकर आ सकता हूं। object_shortcut डिफ़ॉल्ट रूप से सही होगा। यदि object_shortcut सत्य है तो बैकएंड को वैसा ही व्यवहार करना चाहिए जैसा अब मॉडलबैकएंड करता है: उन्हें _only_ 'टेबल/ग्लोबल' अनुमतियों की जांच करनी चाहिए यदि obj कोई नहीं है, अन्यथा उन्हें _only_ 'पंक्ति/ऑब्जेक्ट' अनुमतियों की जांच करनी चाहिए। हालांकि अगर object_shortcut गलत है तो बैकएंड को वैसा ही व्यवहार करना चाहिए जैसा हम दोनों पसंद करेंगे: वे _both_ वैश्विक और ऑब्जेक्ट अनुमतियों की जांच करेंगे जब ऑब्जेक्ट कोई नहीं था। फिर गार्जियन जैसे ऐड-ऑन हमेशा has_perm विधि के साथ object_shortcut=False के साथ डिफ़ॉल्ट के रूप में एक मिश्रण की आपूर्ति कर सकते हैं। user.has_perm(perm, obj, object_shortcut=False) सही ढंग से वापस आ जाएगा यदि अनुमति द्वारा प्रतिनिधित्व किया गया अनुमति उपयोगकर्ता को असाइन किया गया था, जबकि लीगेसी कॉल user.has_perm(perm, obj) झूठी वापसी करना जारी रखेगी।

एक सेटिंग का एक ही परिणाम होगा लेकिन मूल रूप से एक स्विच में परिणाम होगा ModelBackend._get_permissions ।

if not user_obj.is_active or user_obj.is_anonymous or obj is not None:
    return set()

कुछ ऐसा बन जाएगा:

if not user_obj.is_active or user_obj.is_anonymous or (obj is not None and legacy_behaviour_setting_is _on):
    return set()

सुनिश्चित नहीं है कि कौन सा बेहतर है। मुझे लगता है कि एक सेटिंग क्लीनर है, लेकिन मुझे यकीन है कि Django देव इसे निर्धारित करने के लिए अधिक योग्य होंगे।

मुद्दा यह है कि इस मुद्दे को ठीक करना संभव है, और मुझे दृढ़ता से विश्वास है कि यह मुद्दा एक Django बग है, अभिभावक नहीं।

@airstandley आप सही कह रहे हैं, False या None कोई फर्क नहीं पड़ता। उन दोनों का मतलब है कि मैं नहीं जानता । आखिरकार अगर कोई नहीं जानता है, तो अनुमति नहीं दी जाती है।

मैं आम तौर पर आपके साथ एक ही पृष्ठ पर हूं, हालांकि django बैकएंड को एक तरह से व्यवहार करने के लिए मजबूर करता है या कोई अन्य कमजोर युग्मितता को कम करता है। मुझे लगता है कि इसमें तंत्र होना चाहिए ताकि प्रत्येक बैकएंड को अपना काम पूरा करने के लिए आवश्यक जानकारी मिल सके। मैं कीवर्ड तर्क (ओं) पर आपके साथ हूं, लेकिन सिर्फ एक तरह से या किसी अन्य को मजबूर नहीं कर रहा हूं।

यह बातचीत समय की बर्बादी की तरह लगती है, लेकिन इससे मुझे खुद को स्पष्ट करने में मदद मिली कि अभिभावक में अनुमति नहीं दी गई है, यह इनकार नहीं है, यह सिर्फ जानकारी की कमी है।

वैसे भी, मैंने एक पुल अनुरोध #546 किया है। कृपया इसे देखें और मुझे बताएं कि आप क्या सोचते हैं।

मैंने django के साथ एक टिकट बनाया: https://code.djangoproject.com/ticket/29012 , और आश्चर्य है कि वे क्या कहेंगे।

ऐसा लगता है कि django के साथ कुछ अन्य टिकट थे: https://code.djangoproject.com/ticket/0218

मैंने अपना बंद कर दिया।

@doganmeh
मुझे वह दिशा पसंद है जिस पर आप #546 जा रहे हैं। अगर यह मदद करेगा, तो मेरे पास बाकी इकाइयों को देखने और इस सप्ताह के अंत में इन कमियों के लिए कुछ परीक्षण लिखने का समय होना चाहिए।

एक स्पर्शरेखा पर। एक विशिष्ट तरीके से व्यवहार करने के लिए "Django मजबूर बैकएंड" के बारे में आपकी टिप्पणी मुझे भ्रमित करती है, लेकिन इसने मुझे एक विचार भी दिया। बैकएंड जैसा चाहें वैसा व्यवहार कर सकते हैं; गार्जियन के ऑब्जेक्टप्रमिशनबैकएंड के बारे में मेरी प्रारंभिक चिंता दस्तावेज़ीकरण से उत्पन्न होती है, यह सुझाव देती है कि इसे ऑथ के मॉडलबैकएंड के साथ चलाने के लिए डिज़ाइन किया गया था। गार्जियन कई बैकएंड की पेशकश कर सकता है, एक को मॉडलबैकएंड के साथ काम करने के लिए डिज़ाइन किया गया है, और एक को अकेले काम करने के लिए डिज़ाइन किया गया है। (आईई एक जो सिर्फ अभिभावक के UserObjectPermission/GroupObjectPermission टेबल की जांच करता है, दूसरा UserObjectPermission/GroupObjectPermission टेबल और ऑथ की अनुमति तालिका दोनों की जांच करता है।)
व्यक्तिगत रूप से मैं एक सेटिंग और kwargs के साथ वर्तमान दृष्टिकोण पसंद करता हूं। मुझे लगता है कि कई बैकएंड दृष्टिकोण के लिए प्रमुख नकारात्मक पक्ष यह होगा कि यह स्पष्ट नहीं हो जाता है कि शॉर्ट-कट और सुविधा कार्यों को कैसे व्यवहार करना चाहिए।

पोस्ट को Django देव मेलिंग सूची में देखा। मुझे आशा है कि वे इसे स्वीकार करेंगे, या असंगत तरीके से व्यवहार को बदलने के लिए सहमत होंगे। एपीआई पर वर्तमान सीमा सिर्फ क्लंकी है।

क्या आप वहां इसका समर्थन कर सकते हैं? मैं

Windows 10 के लिए मेल से भेजा गया

से: एयरस्टैंडली
भेजा गया: शुक्रवार, जनवरी 12, 2018 दोपहर 12:06 बजे
प्रति: django-अभिभावक/django-अभिभावक
सीसी: मेहमत डोगन; उल्लेख
विषय: पुन: [django-guardian/django-guardian] user.has_perm("perm", obj)अप्रत्याशित व्यवहार करता है (#49)

पोस्ट को Django देव मेलिंग सूची में देखा। मुझे आशा है कि वे इसे स्वीकार करेंगे, या असंगत तरीके से व्यवहार को बदलने के लिए सहमत होंगे। एपीआई पर वर्तमान सीमा सिर्फ क्लंकी है।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

लगभग एक सप्ताह तक इस मुद्दे से निपटने के बाद, मुझे और अधिक दृढ़ता से विश्वास हो गया कि प्रत्येक बैकएंड को केवल एक काम करने की आवश्यकता है, जो कि गार्जियन के लिए ऑब्जेक्ट अनुमतियाँ हैं। ऐसा होने के लिए Django को obj s अधिक अच्छी तरह से व्यवहार करना चाहिए।

इसके लिए मैंने Django को एक पैच भेजा है: https://github.com/django/django/pull/9581 (यदि आप कर सकते हैं तो कृपया टिप्पणी करें)। जो इसे बनाते हैं, हम गार्जियन में जहां कहीं भी मॉडल अनुमतियों की पुनर्प्राप्ति को साफ कर सकते हैं, और बस डिफ़ॉल्ट बैकएंड पर कॉल कर सकते हैं।