हम कोर हैक क्यों नहीं करते?


17

मुझे विश्वास नहीं हो रहा था कि इस साइट पर पहले से ही इस सवाल का जवाब नहीं दिया गया है, लेकिन जब मैंने खोजा तो मुझे यह नहीं मिला, इसलिए ...

कोर को हैक करना प्रकृति के खिलाफ इतना बुरा विचार अपराध क्यों है ?

  • क्या यह वास्तव में आपके मुख्य संस्करण को अपग्रेड करने में सक्षम होना चाहिए? मेरी अधिकांश साइटें वैसे भी ख़राब हो चुकी हैं, इसलिए परेशान क्यों हैं?
  • भले ही यह साइट मालिकों के लिए इतना बुरा है, फिर भी समुदाय इतना ध्यान क्यों रखता है? इसे "बिल्ली के बच्चे को मारना" क्यों कहा जाता है? नहीं है कि बल्कि अतिशयोक्तिपूर्ण?
  • हैकिंग कोर इतना आसान है, क्या हम समस्याओं के समाधान का आसान रास्ता नहीं पसंद करते?
  • ऐसी समस्याएं नहीं हैं जो केवल कोर को हैक करके हल की जा सकती हैं? फिर क्या?

मुझे लगता है कि यदि आप टीम के बिना अपने आप से छोटी वेब साइट बना रहे हैं, तो हो सकता है कि आप यू को ज़रूरत पड़ने पर कोर हैक कर सकते हैं, लेकिन आपको इसकी आवश्यकता क्यों है? मुझे विश्वास है कि आप हैकिंग कोर के बिना किसी भी समस्या को हल कर सकते हैं
पेट्रो पोप्लीशको

4
@ बीथ मैं वास्तव में इस बारे में बहुत गंभीर हूं। D7 में सुरक्षित पृष्ठों के लिए आवश्यक पैच अब साल भर के लिए लटका दिए गए हैं क्योंकि यूनिट परीक्षणों में समस्याएं हैं। जहाँ तक मुझे याद है कि मेनू मशीन नाम की लंबाई के साथ D6 में अभी भी एक बग है। इनमें से किसी ने भी वास्तव में प्रतिबद्ध होने का कोई संकेत नहीं दिखाया है।
mpdonadio

3
@MPD यह वास्तव में एक महान उदाहरण है, मैं कुछ लोगों को जानता हूं जो उन पैच के लिए रो रहे हैं जो इसे बनाने में शामिल हैं (मुझे शामिल किया गया)। एक तरफ बिल्ली के बच्चे, जाहिर है कि कभी-कभी आपको पूरी तरह से पैच करना पड़ता है और इसके साथ कुछ भी गलत नहीं होता है जब तक कि उन पैच को अच्छी तरह से प्रलेखित किया जाता है और टीम पर सभी के लिए उपलब्ध होता है। यह एक ठोस परिनियोजन प्रक्रिया के महत्व के बारे में भी बोलता है, एक जो हाथ से पहले होने वाले अर्ध-मैनुअल चेक के बिना नेत्रहीन अपडेट नहीं करता है। मेरी (छोटे) टीम पर हम सिर्फ दस्तावेज़ क्या परिवर्तन हुए हैं और सुनिश्चित करें कि हर किसी को अद्यतन करने से पहले यह जांच करने के लिए जानता है
क्लाइव

3
पैच लागू करें और इसे एक पाठ फ़ाइल में नोट करें जो आपके रिपॉजिटरी की जड़ में है।
चार्ली श्लिसेर

1
मैं इसे "कभी हैक कोर नहीं, जब तक कि आपके पास अभी भी आपके अपडेट के लिए एक तंत्र नहीं है" फिर से लिखना होगा। इसके लिए कुछ सोच की आवश्यकता है, और आपके विकास वर्कफ़्लो पर निहितार्थ हैं। यदि आप या आपकी टीम इस अतिरिक्त बच्चा सम्भालने के लिए तैयार नहीं हैं, तो ऐसा न करें।
23

जवाबों:


9

सामान्यतया, Drupal कोर कोड में परिवर्तन नहीं करने के तीन कारण हैं:

  • यदि आप कोई आवश्यक कदम नहीं उठाते हैं, तो आपके द्वारा Drupal को अपडेट करने पर हर बार आपके परिवर्तन समाप्त हो जाएंगे। यहां तक ​​कि अगर आप वर्तमान ड्रुपल संस्करण का उपयोग कर रहे हैं, तो पैच नए संस्करण में लागू नहीं हो सकता है, और आपको नए संस्करण के लिए भी एक पैच बनाने की आवश्यकता होगी।

  • Drupal.org पर बनाए रखा के रूप में Drupal कोर पर सुरक्षा सुधार लागू होते हैं, लेकिन आपके हैक किए गए संस्करण पर लागू नहीं हो सकते। इसका मतलब है कि आपको जांचना चाहिए कि आपका संस्करण द्रुपाल कोर के खिलाफ उठाए गए सुरक्षा मुद्दे से प्रभावित नहीं है।
    उस स्थिति में जब आपका हैक किया गया संस्करण एक अलग सुरक्षा समस्या पेश करता है, आप एकमात्र व्यक्ति हैं जिसे आप इसे पा सकते हैं, क्योंकि आपके पास सुरक्षा टीम का समर्थन नहीं है जो ड्रुपल कोर कोड में मौजूद सुरक्षा खामियों की जांच करते हैं, और तीसरे पक्ष में Drupal.org पर होस्ट किए गए मॉड्यूल।

  • आपके द्वारा शुरू किए गए परिवर्तन ड्रुपल के साथ असंगत हो सकते हैं, लेकिन तीसरे पक्ष के मॉड्यूल के साथ भी, जिन्हें ड्रूपल कोर के साथ काम करने की आवश्यकता होती है, न कि किसी भी हैक किए गए संस्करण के साथ।
    हर बार Drupal एक नई सुविधा (जो अभी भी Drupal 7 में होती है, और Drupal 6 में होती है, हालाँकि कम आवृत्ति के साथ), या एक नया API परिवर्तन प्रस्तुत करता है, मौका है हैक किया गया संस्करण हाल के परिवर्तनों के साथ असंगत है।

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

ऐसी समस्याएं नहीं हैं जो केवल कोर को हैक करके हल की जा सकती हैं? फिर क्या?

अधिकतर बार, Drupal core कोड को एडिट किए बिना फीचर्स / व्यवहार में बदलाव करना संभव है। वहाँ हमेशा एक हुक होता है जो सुविधाओं / व्यवहार को बदलने की अनुमति देता है Drupal है, और यह पसंदीदा तरीका है।


4
मैं उन दो वास्तविक विश्व समस्याओं को पोस्ट कर सकता हूं जो मैंने चलाए हैं जो कि पिछले पैराग्राफ में कथनों को चुनौती दे सकते हैं।
18

3
In the case your hacked version introduces a different security issue...मैं इसे एक विशेष रूप से मजबूत तर्क के रूप में नहीं देखता हूँ, जो किसी भी चीज़ की तरह कोर फाइल को संशोधित करता है। यदि मैं कोर हैकिंग नहीं कर रहा हूं, और इसके बजाय मैं एक मॉड्यूल के माध्यम से एक सुरक्षा मुद्दे को पेश करता हूं तो मेरी प्रणाली से अभी भी समझौता किया जाएगा। समझौता किया जाता है, यह वास्तव में कोई बात नहीं है अगर वह मेरे पास किसी मौजूदा फ़ाइल को संपादित करने, या एक नया जोड़ने से आया है।
Zoredache

@Zoredache यदि सुरक्षा समस्या आपके मॉड्यूल में मौजूद है, तो आप इसे हमेशा अक्षम कर सकते हैं, और बाकी साइट बिना सुरक्षा समस्या के, यहां तक ​​कि सुविधाओं के बिना भी काम करेगी। यदि आप Drupal core कोड में एक सुरक्षा समस्या का परिचय देते हैं, और मूल फ़ाइलों को वापस कॉपी करना संभव नहीं है क्योंकि आपने Drupal द्वारा उपयोग की गई कुछ तालिकाओं के स्कीमा को भी बदल दिया है, तो यह एक बड़ी समस्या है।
kiamlaluno

2
यह कथन कि "हमेशा हुक है ..." सही नहीं है। यह पूरी तरह से असामान्य नहीं है कि कोई ऐसी चीज है जिसे ड्रूपल कोर में पकाया जाता है जिसे हैकिंग के बिना काम नहीं किया जा सकता है, और यह भी कि पैच के साथ ड्रुपल के लिए खुले मुद्दे हैं जो प्रतिबद्ध नहीं हैं, जिस स्थिति में आपको कोर को पैच करना होगा उन मुद्दों को हल करने के लिए।
रॉबी

2
बिल्कुल, लेकिन यह एक सरल उदाहरण है। ज्यादातर मामलों में हुक होते हैं, लेकिन कई बार आपको कोर को पैच करने की आवश्यकता होती है, जब तक कि आप बहुत सारे कोड को डुप्लिकेट नहीं करना चाहते हैं और कुछ अन्य कस्टम का निर्माण नहीं करते हैं। उदाहरण के लिए, व्यवस्थापक को अप्रकाशित पुस्तकों को अच्छी तरह से प्रबंधित करने की अनुमति देने के लिए आपको drupal.org/node/520786 पर पैच की आवश्यकता होती है या यदि आप चाहते हैं कि ड्रुपल की डिफ़ॉल्ट एसक्यूएल आंशिक शब्दों से मेल खाती हो (विचारों के खोज फ़िल्टर सहित) आपको drupal.org पर पैच की आवश्यकता है / नोड / ४ ९ node node५२ # टिप्पणी -६००१३१० - हैकिंग कोर के बिना इन के आसपास काम करना संभव नहीं है।
13

14

मैं यहाँ एक बड़े पैमाने पर उत्तर लिख सकता था, लेकिन मैं अभी इस लिंक को पोस्ट करने वाला हूँ: कभी भी कोर को हैक न करें !

मुख्य कारण मुझे लगता है कि यदि आप अपनी ज़रूरत के लिए कुछ करने के लिए कोर हैक करते हैं, और फिर इसे अपडेट करते हैं ... बैंग! आपके परिवर्तन हो गए हैं। खो गया। आप तब अपने VCS से कोड को वापस करने का प्रयास कर सकते हैं, लेकिन यह देखते हुए कि आप Drupal core से डेटाबेस अपग्रेड को रोल नहीं कर सकते हैं - आप VCS से सभी कोड को पुनर्स्थापित करने और फिर अपने बैकअप से डेटाबेस को पुनर्स्थापित करने पर विचार कर रहे हैं। हर समय जब आप अपना कोड वापस लेने की कोशिश कर रहे हैं, तो आप शायद यह नोटिस करेंगे कि आपका अंतिम पूर्व-अद्यतन डेटाबेस बैकअप विफल हो गया है, और आप पहले कभी कसम खाने से अधिक शपथ लेंगे।

इसके अलावा - सबसे महत्वपूर्ण बात - अगर आप कोर हैक करते हैं, तो Dries और Webchick दोनों एक बिल्ली का बच्चा मारते हैं: -o


4
क्या, वे बिल्ली के बच्चे को मारते हैं? मुझे लगा कि यह भगवान है। । मेरी दुनिया अपने आप में गिर रही है ...
क्लाइव

1
तुम्हें पता है, मैंने अपनी टिप्पणी ऊपर लिखी थी इससे पहले कि मैं यहां उल्लेखित बिल्ली के बच्चे को देखता हूं।
mpdonadio

13

"हैकिंग कोर मेरे लिए क्या नहीं कर सकता है, डेवलपर?"

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

"मेरे क्लाइंट के लिए हैकिंग कोर क्या नहीं कर सकता है?"

  • आपके ग्राहक को आग लगाने / लॉटरी जीतने / बस के चपेट में आने के बाद आपकी साइट को किसी और द्वारा बनाए रखा जा सकता है

"मेरे समुदाय के लिए हैकिंग कोर क्या नहीं कर सकता है?"

  • आपकी बग रिपोर्ट वास्तव में कोर या कंट्रीब्यूल मॉड्यूल के अनुरक्षक के लिए उपयोगी जानकारी प्रदान करेगी।
  • यदि आपको कोर में एक कानूनी बग दिखाई देता है जिसे पैच किया जाना चाहिए, तो 'हैकिंग कोर' और 'कोर कॉन्ट्रैक्टर बनने' के बीच की रेखा उतनी ही ठीक है जितना कि आपके परिवर्तनों को अलग करना और उन्हें पैच के रूप में एक प्रासंगिक मुद्दे में अपलोड करना। आहा! कोर आपके प्रयासों के लिए बेहतर है, और आपका नाम समुदाय को वापस कोड देने के साथ जुड़ा हुआ है।

जब आप कोर को हैक नहीं करते तो हर कोई विजेता होता है!


3
सभी पैच कोर के लिए प्रतिबद्ध नहीं हैं, यहां तक ​​कि सरल भी।
mpdonadio

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

6

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

यदि आप ड्रुपल में प्रोग्रामिंग की मानक संरचना का पालन नहीं करते हैं, तो कोई और आपके द्वारा प्रस्तुत परिवर्तनों को कैसे खोज और संपादित कर सकता है? यह विशेष रूप से पीड़ादायक है क्योंकि ड्रुपल में हर एक php फ़ाइल एक हुक को लागू कर सकती है। यह जानने की कोशिश करें कि कौन सी समस्या पैदा कर रही है।


4
इस। यदि आपको कोई ऐसी साइट विरासत में मिली है, जो किसी दिए गए ढांचे पर बनाई गई थी, और तब पता चलता है कि फ्रेम को हैक कर लिया गया था और इस तरह उस फ्रेमवर्क के लिए प्रलेखन संभवतः अप्रासंगिक है, तो आप दर्द की दुनिया में हैं। (उपरोक्त सभी अन्य कारणों के अलावा ...)
चार्ली श्लिसेर

5
शर्त लगाते हैं कि आपने पहले drupal.org/project/hacked के बारे में सुना होगा ?
क्रिस बर्गेस

अच्छा क्रिस दिखता है। मैं निश्चित रूप से देखूंगा।
पावेल जी

एक सभ्य स्रोत नियंत्रण प्रणाली आपको यह बताने में सक्षम होना चाहिए कि क्या बदल गया है और कोर में सभी संशोधनों को दिखाएगा। कोडबेस में स्ट्रिंग्स की खोज करना php में आपके डीबगिंग टूलकिट का मानक हिस्सा होना चाहिए।
टॉबी एलन

5

"ऐसी समस्याएं नहीं हैं जो केवल हैकिंग कोर द्वारा हल की जा सकती हैं? फिर क्या?"

इस प्रश्न का उत्तर देने के लिए, हाँ, कभी-कभी ऐसी समस्याएं होती हैं जिनसे आपको उबरना होता है, अर्थात आपको कोर (या एक कंट्राब मॉड्यूल) को हैक करना होगा।

इस मामले में मेरा मानना ​​है कि जब तक आप अपने हैक किए गए कोड में बहुत सारी टिप्पणियां डालते हैं और आप जो कुछ भी बदलते हैं उसे दस्तावेज़ करने के लिए हैक करना ठीक है।

उदाहरण के लिए, किसी भी कोर या कंट्राब परिवर्तन के लिए मैं एक पैच बनाता हूं। यदि यह अन्य लोगों के लिए सामान्य और उपयोगी है, तो मैं इसे एक मुद्दे में drupal.org को प्रस्तुत करता हूं, अन्यथा यह मेरे स्वयं के उपयोग के लिए है।

फिर मैं कोड परिवर्तन के साथ अपने संस्करण नियंत्रण के लिए पैच फ़ाइल करता हूं।

इसका मतलब है कि मैं पैच फ़ाइलों की तलाश करके देख सकता हूं कि क्या कुछ हैक किया गया है।

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

इस हैक डॉक्यूमेंटेशन में, मैं प्रत्येक हैक को हैक और क्या करता है, के साथ सूचीबद्ध करता हूं, मॉड्यूल / फाइलें प्रभावित होती हैं, पैच फाइल का नाम जिसमें हैक कोड होता है, और एक संबंधित drupal.org लिंक का लिंक होता है अगर एक है (लगभग हमेशा मेरे मामले में) है।

फिर आप और जो कोई भी भविष्य में साइट पर काम करता है, उसके पास हैक की पूरी सूची है और उसे अपडेट के साथ गलती से कुछ तोड़ने की चिंता नहीं करनी है।

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

यदि पैच प्रतिबद्ध नहीं था, तो मुझे केवल मॉड्यूल को अपडेट करना होगा और पैच को फिर से लागू करना होगा। बहुत सारे मामलों में पैच अभी भी सफाई से लागू होंगे और प्रक्रिया आसान है, लेकिन कभी-कभी आपको नए संस्करण के लिए पैच को फिर से पढ़ना होगा और फिर पैच के नए संस्करण को अपने स्थानीय भंडार (प्रासंगिक के साथ पोस्ट करने के साथ) करना होगा। drupal.org मुद्दा जहां लागू हो)।

एक और बात मुझे पसंद है अगर मेरे पास बहुत अधिक पैच या पैच हैं जो एक मॉड्यूल के कोर fucntionality के साथ बातचीत करते हैं (या बस कस्टम मॉड्यूल जो एक drupal.org मॉड्यूल के शीर्ष पर विस्तार करते हैं), अद्यतन मॉड्यूल के रिलीज नोटों की जांच करना है ( इसका मतलब है कि आपके वर्तमान संस्करण और आपके द्वारा अपडेट किए जा रहे संस्करण के बीच सभी संस्करण) और सुनिश्चित करें कि वहाँ कुछ भी नहीं है जो आपके कोड को तोड़ने की संभावना है। नोट: संपूर्ण रिलीज़ नोट देने के साथ इन दिनों बहुत सारे मॉड्यूल मेंटेनर अच्छे हैं लेकिन अभी भी बहुत सारे हैं जो जारी नोट्स को बकवास करते हैं। इस मामले में कुछ मामलों में मैं अपने वर्तमान संस्करण के बाद से सभी प्रतिबद्ध संदेशों से गुजरता हूं (यह आमतौर पर केवल उन मामलों में होता है जहां मेरे पास जटिल कोड होता है जो किसी अन्य मॉड्यूल के साथ गहराई से बातचीत करता है)। ध्यान दें:

फिर, अद्यतन करने के बाद (साइट की एक विकास प्रति पर), अच्छी तरह से परीक्षण करें। आप अंततः सीखेंगे कि कुछ बगों के खिसकने के बाद इसका क्या मतलब है।

फिर जब इसका पर्याप्त परीक्षण किया गया है, तो लाइव साइट को अपग्रेड करें या अपने स्थानीय अपडेट को पुश करें या आपकी तैनाती की प्रक्रिया जो भी हो।

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

अगर आपको कभी ऐसी साइट विरासत में मिली है, तो आप पूरी तरह से समझ जाएंगे :)


2

यदि आप Drupal वेबसाइट को स्थापित करने और बनाने से जीविकोपार्जन करते हैं, तो उन्हें अद्यतित रखना आवश्यक है। यदि आपकी अधिकांश साइटें पुरानी हो चुकी हैं, तो आप पेशेवर नहीं हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.