ब्लॉक, नोड्स, व्यू-आर्ग्स आदि में PHP फ़िल्टर कोड का उपयोग करने की डाउनसाइड क्या हैं?

96

मैंने कई बार लोगों को ब्लॉक, नोड्स, व्यू-आर्ग, नियम आदि में कस्टम PHP / PHP फ़िल्टर (Drupal UI से) का उपयोग न करने के लिए कहा है, मैंने थोड़ा बहुत खोज किया है और बहुत कुछ नहीं मिला है, ऐसा लगता है यह एक Drupal सबसे अच्छा अभ्यास है जो सभी "बस जानते हैं"।

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

security

— Laxman13
स्रोत

1

हमेशा की तरह, यह स्थिति पर निर्भर करता है! यदि आपको केवल 'दृश्य पाद' में अपने दृश्य पृष्ठ के निचले भाग में एक मूल प्रिंट $ ब्लॉक की आवश्यकता है, तो यह सिर्फ उस उद्देश्य के लिए एक पूरी संपूर्ण tpl फ़ाइल लिखने की तुलना में सिर्फ गुई के माध्यम से करने के लिए आदर्श हो सकता है। यह निश्चित रूप से साइट और अन्य कारकों की भूमिका पर निर्भर करता है: तंग समय सीमा? उपयोगकर्ता समुदाय साइट? या सिर्फ सूचनात्मक स्थल? क्या यह व्यवसाय संचालन के लिए एक महत्वपूर्ण है? आदि ... निर्भर करता है।

— पडोशी at ト

129

कुछ कारणों से:

आपके डेटाबेस में कोड को नियंत्रित नहीं किया जा सकता है और बाद में सामान्य रूप से ढूंढना भी कठिन है।
किसी फ़ाइल में कुछ हार्डकोड की तुलना में एवल () का डी कोड बहुत धीमा है।
यदि उस कोड में कहीं कोई त्रुटि है, तो आपको एक बहुत ही अनपेक्षित त्रुटि संदेश मिलेगा (लाइन 3 में eval () कोड में त्रुटि) और आप त्रुटि को खोजने और ठीक करने के लिए मैन्युअल रूप से अपने डेटाबेस से गुजर सकते हैं। यदि यह एक ब्लॉक के अंदर है जो सभी पृष्ठों पर प्रदर्शित होता है और उदाहरण के लिए हर समय एक घातक त्रुटि का परिणाम होता है।
Drupal 6 से 7 में अपग्रेड करते समय और आपके द्वारा उपयोग किए गए API के जो भी बदलाव किए गए थे, वह भी सही है। इसलिए आपको माइग्रेट करते समय अपना कोड पोर्ट करना होगा। यदि कोड एक मॉड्यूल में है, तो आप इसे पहले से पोर्ट कर सकते हैं, इसका परीक्षण कर सकते हैं, और केवल इसे नई साइट पर तैनात कर सकते हैं। एक नोड या ब्लॉक के अंदर, यह केवल Drupal 6 या 7 के साथ काम करेगा।
उस कोड को लिखना और उसे मेन्टेन करना भी कठिन है, क्योंकि आप अपने ब्राउज़र के अंदर एक टेक्स्टफील्ड में काम कर रहे हैं। एक मॉड्यूल में होने से आप एक संपादक / आईडीई को सिंटैक्स हाइलाइटिंग, स्वतः पूर्ण और इतने पर उपयोग कर सकते हैं।
हमेशा एक ग़लतफ़हमी की संभावना है जो लोगों को एक पाठ प्रारूप / ब्लॉक / जो भी php निष्पादन सक्षम है, तक पहुंच प्रदान करता है। यदि php.module (D7 में, D6 इतना सख्त नहीं है, उदाहरण के लिए ब्लॉक एक्सेस नियमों के लिए) तो सक्षम भी नहीं है, यह जोखिम पहले से बहुत कम है।
यदि आपका सीएमएस PHP को निष्पादित करने की अनुमति देता है, तो एक हमलावर जो XSS या विशेषाधिकार वृद्धि की सुरक्षा भेद्यता पाता है, वह अब आपके सर्वर का उपयोग अत्यधिक दुर्भावनापूर्ण चीजों के लिए कर सकता है (डीडीओएस के भाग के रूप में, स्पैम भेजना, मैलवेयर की मेजबानी करना, अन्य साइटों / डेटाबेस पर हैक करना) सर्वर, नेटवर्क पर अन्य सर्वरों में हैकिंग जो फ़ायरवॉल के पीछे हो सकता है)। छोटी कमजोरियों को और अधिक दर्दनाक बनाने के अलावा, यह साइट को हमले का अधिक संभावित लक्ष्य बनाता है यदि इसकी ज्ञात है कि इसका उपयोग php निष्पादित करने के लिए किया जा सकता है।

इसके और भी कारण हो सकते हैं, लेकिन यह पर्याप्त होना चाहिए :)

— Berdir
स्रोत

3

अच्छी सूची :) उम्मीद है कि दूसरों के लिए एक संसाधन होगा

— लक्ष्मण 13

3

@ लक्ष्मण 13: "दूसरों के लिए" ... और आपके लिए भी! : D @Berdir: +1, बहुत अच्छे पहलू हैं। वैसे, आपको पूरे कोड को टेक्स्ट फ़ील्ड में लिखने की ज़रूरत नहीं है, क्योंकि आप वहां एक फ़ाइल भी शामिल कर सकते हैं। जैसे आप टेक्स्ट फ़ील्ड में सिर्फ एक लाइन डाल सकते हैं: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';और बाकी कोड अपने IDE / टेक्स्ट एडिटर में लिखें। कभी-कभी यह एक आसान काम नहीं है या एक अच्छा पीएचपी-डेवलपर के रूप में भी अपना खुद का मॉड्यूल बनाने में बहुत लंबा समय लगेगा। एक छोटा उदाहरण: Ubercart Conditional Actions। लेकिन यह सच है कि हमारे कोड को db में रखना अच्छी बात नहीं है।

— Sk8erPeter

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

— Sk8erPeter

1

+1000 - मैंने ऐसा देखा है, इसलिए इस सूची में बहुत से हर बुलेट पॉइंट द्वारा बहुत सारे प्रोजेक्ट जलाए गए हैं। मेरे पूरे जीवन में केवल एक ही समय था कि PHP मॉड्यूल का उपयोग करना कुछ ही तरीके से किया गया था, और वह केवल D6 के साथ एक समस्या के कारण था जो D7 में तय किया गया था।

— geerlingguy

इस प्रश्न के लिए आपके विवरण उत्तर के लिए धन्यवाद। द्रुपाल में काम करते हुए मुझे एक स्थिति मिली, कि जब हमें 'टेक्स्ट एडिटर ’में लिंक जोड़ने की आवश्यकता होती है, तो हमें code टेक्स्ट फ़िल्टर’ में php कोड का उपयोग करने की आवश्यकता होती है अन्यथा यह अपेक्षा के अनुरूप काम नहीं करेगा।

— जयेन्द्र किनथोला

17

यह कोड डीबग करना और बनाए रखना मुश्किल है। मैं इस तरह के php कोड के लिए संस्करण नियंत्रण का उपयोग करने का कोई तरीका नहीं जानता।

और यह वास्तव में Drupal या PHP के लिए नए लोगों के लिए एक संभावित सुरक्षा जोखिम है,

— ya.teck
स्रोत

1

ठीक है, अगर ब्लॉक कॉन्फ़िगरेशन को फीचर मॉड्यूल के साथ कोड में निर्यात किया जाता है, तो यह संस्करण नियंत्रण के तहत php स्निपेट्स लगाने की समस्या नहीं है।

— येट।

14

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

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

एक विकास या एक परीक्षण साइट के अलावा, मैं PHP फ़िल्टर को सक्षम नहीं करूंगा, या उस PHP कोड का उपयोग नहीं करूंगा जो पास है eval()।

PHP फ़िल्टर को Drupal 8 से हटा दिया गया है। यह अब एक तृतीय-पक्ष मॉड्यूल है , जिसे सुरक्षा सलाहकार नीति से कवर नहीं किया गया है । यह संभवतः उत्पादन सर्वरों में इसका उपयोग न करने का एक कारण है (यदि पहले से दिए गए कारणों ने आपको मना नहीं किया है)।

— kiamlaluno
स्रोत

11

ऊपर बताई गई विभिन्न समस्याओं के लिए एक काम के इर्द-गिर्द - कोड रखरखाव की कठिनाई, संस्करण नियंत्रण, त्रुटि-खोज, आपके पास यह थोड़ा "क्लेगी" संभावना है:

फ़ंक्शंस बनाएं (उन्हें ध्यान से देखें कि वे क्या करते हैं) कुछ फ़ाइल में जो हमेशा शामिल होती हैं - यदि आपके पास एक कस्टम मॉड्यूल है जो आप साइट के लिए लिख रहे हैं, तो यह इन कार्यों को लगाने के लिए एक शानदार जगह है। आपके द्वारा दर्ज किया गया php बस है: return my_specialfunc($somevar);- $somevarयहाँ संभावित रूप से नोड ऑब्जेक्ट पर काम किया जा रहा है, या जो भी अन्य चर यहां प्रासंगिक हैं।

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

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

— जेम्स
स्रोत

11

यदि आप अपने गैर-व्यवस्थापक उपयोगकर्ताओं को सीधे db को संशोधित करने के लिए नहीं चाहते हैं, तो अपने उपयोगकर्ताओं को यह अनुमति देने से बचने के लिए सुरक्षा भेद्यता कारण है।

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Drupal db क्रेडेंशियल्स हैक करना

— lolcode
स्रोत

7

कुछ ऐसा करने के बजाय return functionname($object), जितना संभव हो सके टोकन / फिल्टर सिस्टम इनोफ़र का उपयोग करना बेहतर होगा। इन्सर्ट व्यू और एंबेड नोड जैसे मॉड्यूल हैं जो सामान्य परिस्थितियों में मदद कर सकते हैं जिसमें लोग PHP को नोड या ब्लॉक निकायों में एम्बेड करना चाहते हैं।

— इवान डोनोवन
स्रोत

0

आपको अपने डेटा की पोर्टेबिलिटी की परवाह करनी चाहिए। क्या होगा यदि आप अपने नोड्स को ड्रुपल 7 से ड्रुपल 8 और कुछ नोड के बॉडी टेक्स्ट में माइग्रेट करते हैं <?php whatever_function_that_does_not_exist_anymore(); ?>?

5 महीने के भीतर नहीं बल्कि 5 साल के भीतर अपने प्रोजेक्ट के बारे में सोचें। मेरी राय में अपडेट, अच्छी प्रैक्टिस और पोर्टेबिलिटी किसी भी अच्छे आईटी प्रोजेक्ट के महत्वपूर्ण पहलू हैं।

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

— स्टेफ वान लवरेन
स्रोत