संकलन-समय/पोस्ट-बिल्ड निर्भरता इंजेक्शन आईओसी?

Question

मैं वर्तमान में NInject का उपयोग ठोस प्रकारों में इंटरफेस को बांधने और अपनी कक्षाओं में इंजेक्ट करने के लिए करता हूं। हालांकि, यह मेरी समझ है कि यह एक रन-टाइम संबंध है। मेरे लिए, यह हमले के एक बिंदु की तरह लगता है अगर कोई मेरे आवेदन के व्यवहार को बदलना चाहता था।

क्या कोई ऐसी चीज है जो मुझे मेरे निर्भरता इंजेक्शन आईओसी को समय संकलित करने के लिए माइग्रेट करने की अनुमति देगी (पढ़ें: पोस्ट-बिल्ड आईएल बुनाई/प्रतिस्थापन)?

---

विस्तृत करने के

मेरे कोड मैं सेटअप में एक बाध्यकारी

Bind<IFoo>().To<Foo>() 
Bind<Bar>().ToSelf().InSingletonScope(); 

ctor Foo(Bar dependency)

साथ अपने आवेदन की जड़ में (स्टार्ट-अप पर) मैं ग्राफ़

0 को हल करें

मान लें कि मेरे पास कोई सेवा लोकेटर (anti-pattern anyway right?) है। तो अब मेरे पास kernel के लिए कोई उपयोग नहीं है।

अब मैं "पोस्ट-बिल्ड रिलीज-कंपाइल" रखना चाहता हूं जो कर्नेल के रिज़ॉल्यूशन इंजन को इंस्टेंसिएटर, या निरंतर/सिंगलटन के संदर्भों के साथ प्रतिस्थापित करता है, जैसे कि मेरा कोड इस तरह दिखता है;

var foo = kernel.Get<IFoo>(); 

हकीकत में, मेरा अंतिम निर्माण के चरण में आईएल प्रतिस्थापन के बाद, यह इस तरह दिखता है:

var bar = new Bar(); 
var foo = new Foo(bar); 

और Ninject के लिए कोई संदर्भ अब और नहीं है।

इस प्रश्न के लिए मेरा तर्कसंगत यह है कि मैं आईएल वीव के लिए Fody का उपयोग कर रहा हूं, मेरी सारी संपत्ति बदलकर raisers और मैं सोच रहा हूं कि निर्भरता इंजेक्शन के लिए कुछ ऐसा करना संभव होगा।

Answer 1

जैसा कि चर्चा की गई है, ऐसा करने के आपके उद्धृत कारण जोड़े नहीं गए हैं। हालांकि, फिलिप लॉरानो (लिनफू लेखक) ने कुछ समय पहले Hiro project किया था जो पूर्व-तैनाती DI करता है। कोई विचार नहीं कि यह कहीं भी चला गया ...

Answer 2

सामान्य रूप से एक सुरक्षा परिप्रेक्ष्य से, एक डी कंटेनर का उपयोग आपके आवेदन के लिए कोई अतिरिक्त खतरा उत्पन्न नहीं करता है।

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

दूसरी ओर उपयोगकर्ता की मशीन पर चलने वाले एप्लिकेशन के लिए, आपको हमेशा उस एप्लिकेशन को समझौता करने पर विचार करना चाहिए, क्योंकि एक हमलावर आपके कोड को विघटित कर सकता है, रनटाइम पर व्यवहार बदल सकता है। फिर, DI नहीं करता इससे भी बदतर, क्योंकि आप केवल सेवा सीमा पर हमलों के खिलाफ खुद को बचा सकते हैं। उस क्लाइंट ऐप को सर्वर के साथ संवाद करना चाहिए और अपनी मूल्यवान संपत्तियों को स्टोर करने के लिए स्थान सेवा सीमाओं के भीतर है। उदाहरण के लिए, आपको क्लाइंट पर डीएलएल के अंदर कभी भी खाता पासवर्ड स्टोर नहीं करना चाहिए। इससे कोई फर्क नहीं पड़ता कि यह एन्क्रिप्ट किया गया है या नहीं।

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

यह हमले के एक बिंदु की तरह लगता है अगर किसी को अपने आवेदन की व्यवहार बदलने के लिए चाहते थे

कृपया ध्यान दें कि किसी भी आवेदन, decompiled बदला जा सकता है, और फिर कंपाइल। इससे कोई फर्क नहीं पड़ता कि यह प्रबंधित है (.NET, जावा) या नहीं (सी ++), या obfuscated या नहीं। तो फिर, एक सुरक्षा परिप्रेक्ष्य से इससे कोई फ़र्क नहीं पड़ता कि आप रनटाइम डी या संकलन-समय DI करते हैं या नहीं। यदि यह कोई समस्या है, तो उन कोडों पर उस कोड को तैनात न करें जिन पर आपका कोई नियंत्रण नहीं है।