Django-tastypie: बहुत अधिक सुरक्षित डिफ़ॉल्ट की आवश्यकता है: `DjangoAuthorization` को सभी मॉडल ऑब्जेक्ट पर` read` एक्सेस की अनुमति नहीं देनी चाहिए

मैं सराहना करता हूं कि यह पहले ही विलय हो गया है लेकिन मैं अभी भी इसके साथ मुद्दा उठाता हूं। एक नया अनुरोध खोलने से पहले, यहाँ मेरी चिंता है:

यह परिवर्तन दुर्भाग्य से मौजूदा कोड को तोड़ता है और इस तरह पीछे की ओर असंगत है (पहले सभी GET अनुरोध DjangoAuthorization पास होगा)। किसी के कोड को ठीक करने के लिए, केवल दो विकल्प हैं या तो सभी उपयोगकर्ताओं को परिवर्तन की अनुमति (खराब) दें, या रीड एक्शन के संभावित कार्यान्वयन (संभावित रूप से बहुत सारे) के लिए DjangoAuthorization को उप-वर्ग करें। क्या यह इरादा था?

मैं django व्यवस्थापक संदर्भ में इसके पीछे के तर्क की सराहना करता हूं, लेकिन मुझे संदेह है कि 'रीड' को एपीआई संदर्भ में 'परिवर्तन' के समकक्ष स्थापित करना एक समझदार डिफ़ॉल्ट धारणा है क्योंकि यह अपेक्षित व्यवहार नहीं है। आखिरकार, अगर GET DjangoAuthorization के साथ एक अनुमत विधि है, तो यह इस तथ्य के आधार पर पहुंच से इनकार क्यों करेगा कि उपयोगकर्ता के पास change अनुमति नहीं है?

मैं प्रस्ताव करता हूं कि वह वैकल्पिक कार्यान्वयन के बाद:

_for read_detail_

• यदि मॉडल के पास view अनुमति है, तो जाँच करें (= उन लोगों के लिए सुधार जिनकी आवश्यकता है)
• अगर कोई view अनुमति नहीं है, तो हमेशा अनुमति दें (= पीछे संगत)

_for read_list_

• यदि मॉडल के पास list अनुमति है, तो जाँच करें कि (= उन लोगों के लिए सुधार जो इसकी आवश्यकता है)
• यदि कोई list अनुमति नहीं है, तो हमेशा अनुमति दें (= पीछे संगत)

इस तरह से tastypie एक डिफ़ॉल्ट जोड़ता है, जो DjangoAuthorization के एक कस्टम कार्यान्वयन को लिखने की जरूरत है, जो उन लोगों के लिए देखने और सूची अनुमतियों को जोड़ने के द्वारा सुधार करने के लिए एक आसान रास्ता देते हुए Django की अनुमति चूक के साथ संगत है।

कम से कम डिफ़ॉल्ट अनुमति निर्दिष्ट करने का एक तरीका होना चाहिए:

DjangoAuthorization(read_permission='view', # applies to both list, detail if not spec'd
                    read_list_permission='view', # list only
                    read_detail_permission='view') # detail only
# while we're at it, why not add the other permissions too
DjangoAuthorization(change_permission='change',
                    delete_permission='delete',
                    add_permission='add', 
                    # ... add options as per above for each
                    # <action>_<level> permission where 
                    # action is `change,delete,add,read`,  level is `list,detail`)

@ सीनहेस वही होगा जो फैसला करेगा।

यहाँ सिर्फ मेरी राय है, मुझे लगता है कि यह डिफ़ॉल्ट रूप से पढ़ने की अनुमति देने के लिए एक सुरक्षा मुद्दा था। मैं पूरी तरह से इसकी उम्मीद नहीं करता था, जब तक कि मैं उत्पादन के बहुत करीब नहीं था। मुझे लगता है कि इस संदर्भ में पिछड़े-नायकों को तोड़ना आवश्यक है।

अपने सुझाव को देखें कि आपके मौजूदा कोड में बदलते पैरामेट्स को DjangoAuthorization करने की आवश्यकता है, उस स्थिति में मुझे लगता है कि कक्षा को कुछ और कहना अभी स्पष्ट है।

विचार करें, read_permission='view' मामला, यहां ठीक वही हो सकता है जिसकी आपको आवश्यकता है। मैं यह नहीं देखता कि यह कम से कम इष्टतम क्यों है

class ModifiedDjangoAuthorization(DjangoAuthorization):
    READ_PERM_CODE = 'view'

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

class ModifiedDjangoAuthorization(DjangoAuthorization):
    def delete_list(self, object_list, bundle):
        return self.perm_list_checks(bundle.request, 'del', object_list)

    def delete_detail(self, object_list, bundle):
        return self.perm_obj_checks(bundle.request, 'del', bundle.obj)

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

मुझे लगता है कि यह डिफ़ॉल्ट रूप से पढ़ने की अनुमति देने के लिए एक सुरक्षा मुद्दा था।

मैं मूल मुद्दे की मंशा पर सवाल नहीं उठा रहा हूं। केवल यह बताते हुए कि विलय के रूप में कार्यान्वयन लोगों के मौजूदा कोड और मान्यताओं को बिना कहे और बिना किसी प्रभावी विकल्प के वापस करने के लिए तोड़ रहा है।

अपने सुझाव की तरह देखें, अपने मौजूदा कोड को DjangoAuthorization के लिए बदलते पैरामेट्स पास की आवश्यकता होती है,

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

मुझे लगता है कि इस संदर्भ में पिछड़े-नायकों को तोड़ना आवश्यक है।

मैं असहमत हूं। वर्तमान में मिलाया गया परिवर्तन न केवल पश्चगामी-संगतता को तोड़ता है, बल्कि इसमें एक बहुत बड़ा संभावित सुरक्षा मुद्दा भी पेश करता है, जिसमें स्पष्ट तरीका (वर्तमान कार्यान्वयन द्वारा निहित) उन सभी उपयोगकर्ताओं को परिवर्तन की अनुमति देता है जिन्हें GET की अनुमति दी जानी चाहिए।

सच कहूं, तो मैं यह देखने में विफल हूं कि कैसे पढ़ने की क्रियाओं के लिए change अनुमति से सुरक्षा बढ़ जाती है, साथ ही यह अनुमति भी अनुमति देती है। विभिन्न क्रियाओं के लिए अनुमतियाँ मिलाना अच्छा विकल्प नहीं लगता है।

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

बेशक ओवरराइडिंग हमेशा किसी की विशिष्ट आवश्यकताओं को प्राप्त करने का एक विकल्प है, हालांकि मुझे लगता है कि टैस्टीपी में सामान्य विचार समझदार और सुरक्षित चूक प्रदान करना है, जिसे कस्टम कोड जोड़ने की आवश्यकता नहीं है ...

संक्षेप में मुझे लगता है कि इस बदलाव को बेहतर क्रियान्वयन के लिए वापस लाया जाना चाहिए।

change अनुमति Django से ही आ रही है। यह Django का डिफ़ॉल्ट है, यह कैसे Django व्यवस्थापक एप्लिकेशन सेटअप है। विकल्प view नहीं है। मैंने व्यक्तिगत रूप से मेरा नाम read ।

model जाँच करने से आपका क्या मतलब है, यह निश्चित नहीं है। यदि आप का अर्थ है _meta की जाँच करना, तो यह अधूरा हो सकता है। यदि आप db को मारते हैं, तो मुझे यह अप्राप्य महंगा लगा।

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

यहां परिवर्तन को प्रलेखित किया गया था: https://github.com/django-tastypie/django-tastypie/blob/master/docs/release_notes/v0.13.2.rst

सच कहूं, तो मैं यह देखने में विफल हूं कि पढ़ी गई कार्रवाइयों के लिए परिवर्तन की अनुमति सुरक्षा को कैसे बढ़ाती है क्योंकि उसी समय यह अनुमति PUT को भी अनुमति देती है। विभिन्न क्रियाओं के लिए अनुमतियाँ मिलाना अच्छा विकल्प नहीं लगता है।

हम जानते हैं कि यदि कोई उपयोगकर्ता कुछ बदल सकता है, तो वे इसे पढ़ सकते हैं, यही है कि Django एडमिन कैसे काम करता है।

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

यदि आप पुराना व्यवहार चाहते हैं:

1. 0.13.2 पर अपग्रेड न करें।
2. या read_list and read_detail` तरीकों को ओवरराइड करें।

अगर आपको लगता है कि प्रलेखन में सुधार किया जा सकता है, तो बेझिझक पीआर प्रस्तुत करें।

आपकी प्रतिपुष्टि की सराहना। डॉक्टर के लिंक के लिए धन्यवाद, काफी निष्पक्ष, लापता होने के लिए मेरा बुरा (कृपया ध्यान दें कि मुद्दा v0.13.4 को सौंपा गया है जबकि डॉक्स v0.13.2 में हैं)।

मुझे अपने पोव से कुछ अंतिम टिप्पणी करने दें:

हम जानते हैं कि यदि कोई उपयोगकर्ता कुछ बदल सकता है, तो वे इसे पढ़ सकते हैं, यही है कि Django एडमिन कैसे काम करता है।

Django व्यवस्थापक change अनुमति का उपयोग करता है क्योंकि व्यवस्थापन _is_ के बारे में _changing_ ऑब्जेक्ट के बारे में है। यह वहाँ समझ में आता है। परिभाषा द्वारा REST API पर GET अनुरोध _reading / view_ के बारे में है। मुझे लगता है कि अधिकांश देवों को आसानी से बदलने की अनुमति के आधार पर DjangoAuthorization पढ़ने से इनकार करने की उम्मीद नहीं है।

यह संस्करण अधिक सुरक्षित है, क्योंकि यह डेवलपर को यह सोचने के लिए मजबूर करता है कि वे क्या कर रहे हैं।

Tastypie की विज्ञापित सुविधाओं में से एक _reasonable चूक प्रदान करना है। क्या यह मान लेना उचित नहीं होगा कि API का GET (परिभाषा के अनुसार: पढ़ें) और PUT (परिवर्तन) के तरीके, सभी इरादे और उद्देश्य में अलग-अलग ऑपरेशन होने के नाते भी अलग-अलग अनुमतियों की आवश्यकता होती है?

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

परिवर्तन की अनुमति Django से ही आ रही है। (...) विकल्प दृश्य नहीं है।

Django में view permission जोड़ने के लिए एक लंबित पीआर है, यही वजह है कि मैंने दृश्य का उपयोग किया।

हम डिफ़ॉल्ट रूप से सार्वजनिक / वैश्विक रीड ऑपरेशंस की अनुमति नहीं देने जा रहे हैं। वह अंतिम है। और हम यह अनुमान लगाने की कोशिश नहीं करने जा रहे हैं कि डेवलपर्स ने अपनी अनुमति तब दी है जब ऐसा करने के लिए कोई मानक तरीका नहीं है। हमें यह भी पक्का नहीं है कि इसे "रीड" या "व्यू" कहा जा सकता है या नहीं, और मैं नहीं चाहता कि यहाँ आने वाले लोगों का झुंड यह कहे कि "मैं इसे इस तरह से करता हूँ" या "नया Django रिलीज़ इसे कुछ और कहता है" ।

यदि और जब Django बॉक्स से बाहर पढ़ने / देखने की अनुमति का समर्थन करता है तो हम उस पर स्विच करेंगे। अभी के लिए डेवलपर्स को अनुमतियों को संभालने के लिए कस्टम तरीके को संभालने के लिए कुछ कस्टम कोड लिखना होगा।

मुझे पता है कि यह मुद्दा बंद हो गया है, लेकिन मैं सिर्फ इसमें झंकार करना चाहता हूं और कहना चाहता हूं कि इस बदलाव ने मूल रूप से मौजूदा परियोजना को 0.13.x पर स्थानांतरित करने से रोक दिया है।

@ मिराकुलिक्स मुझे लगता है कि आप इस तथ्य के संबंध में पूरी तरह से सही हैं कि डेटा को देखने के लिए केवल परिवर्तन की अनुमति की आवश्यकता है, थोड़ा पागल है। मुझे लगता है कि हम किसी भी तरह के लिए Django को दोष दे सकते हैं, फिर भी, एक दृश्य अनुमति की अवधारणा नहीं है (जो मेरी खान को पूरे अन्य स्तर पर उड़ाता है, मुझे लगता है कि यह पागल है कि एक CRUD व्यवस्थापक घटक सहित एक परियोजना के लिए बस एक अनुमति नहीं है CRUD का हिस्सा)।

जब आप प्रोडक्शन-ब्रेकिंग परिवर्तन करते हैं, तो क्या आप कम से कम उस संस्करण में प्रतिबिंबित कर सकते हैं?
Tastypie का x.y.z संस्करण वैसा ही दिखता है जैसा कि ज्यादातर लोग उम्मीद करते हैं , आमतौर पर यह है:

एक संस्करण संख्या MAJOR.MINOR.PATCH को देखते हुए, वेतन वृद्धि:
।।
जब आप पश्च-संगत बग सुधार करते हैं तो पैटच संस्करण।

मैंने अभी एक नई उत्पादन परिनियोजन के दौरान एक बहुत ही असुविधाजनक घंटे का पता लगाया।