.NET प्लग इन करने के लिए एक व्यावहारिक दृष्टिकोण की तलाश है




mef sandbox (4)

इस लाइब्रेरी का उपयोग करने के लिए एक विकल्प होगा: https://processdomain.codeplex.com/ यह आपको स्वीकृत उत्तर की तुलना में आउट-ऑफ-प्रोसेस AppDomain में कोई भी .NET कोड चलाने की अनुमति देता है, जो बेहतर अलगाव भी प्रदान करता है। बेशक किसी को अपने कार्य के लिए एक सही उपकरण चुनने की आवश्यकता होती है और कई मामलों में स्वीकृत उत्तर में दिए गए दृष्टिकोण की आवश्यकता होती है।

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

मैं एक .NET एप्लीकेशन से प्लगइन्स एक्सेस करने का एक सरल और सुरक्षित तरीका ढूंढ रहा हूं। यद्यपि मुझे लगता है कि यह एक बहुत ही सामान्य आवश्यकता है, मैं अपनी सभी जरूरतों को पूरा करने के लिए संघर्ष कर रहा हूं:

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

मैंने एमईएफ और एमएएफ दोनों की जांच की है, लेकिन मैं यह देखने के लिए संघर्ष कर रहा हूं कि दोनों में से किसी को बिल फिट करने के लिए कैसे बनाया जा सकता है।

मेरी समझ को सही मानते हुए, MAF अपनी अलगाव सीमा में सामान्य प्रकारों के पारित होने का समर्थन करने में असमर्थ है, जो मेरे आवेदन के लिए आवश्यक है। (MAF भी लागू करने के लिए बहुत जटिल है, लेकिन मैं इसके साथ काम करने के लिए तैयार रहूंगा यदि मैं सामान्य प्रकार की समस्या को हल कर सकता हूं)।

MEF लगभग एक सही समाधान है, लेकिन सुरक्षा की आवश्यकता पर कम पड़ता प्रतीत होता है, क्योंकि यह मेजबान के रूप में एक ही AppDomain में अपने विस्तार असेंबलियों को लोड करता है, और इस प्रकार स्पष्ट रूप से सैंडबॉक्सिंग को रोकता है।

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

मैं अपने असेंबली में .NET 4.0 सुरक्षा विशेषताओं को लागू करने में सफल रहा हूं और वे एमईएफ द्वारा सही ढंग से सम्मानित किए जाते हैं, लेकिन मैं यह नहीं देखता कि यह कैसे मुझे मैलिक कोड को लॉक करने में मदद करता है, क्योंकि सुरक्षा के खतरे के ढांचे के कई तरीके हो सकते हैं ( जैसे कि System.IO.File तरीके को SecuritySafeCritical के रूप में चिह्नित किया जाता है, जिसका अर्थ है कि वे SecurityTransparent विधानसभाओं से सुलभ हैं। क्या मुझसे कोई चूक हो रही है? क्या कुछ एडिटोनल कदम है जो मुझे MEF को बताने के लिए ले सकता है कि उसे प्लगइन असेंबलियों को इंटरनेट विशेषाधिकार प्रदान करना चाहिए?

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

मैं इस प्रश्न की लंबाई के लिए माफी माँगता हूँ; इसका कारण यह था कि मैंने पहले ही जांच कर चुके सभी रास्ते दिखा दिए थे, इस उम्मीद में कि कोई व्यक्ति कुछ नया करने की कोशिश कर सकता है।

आपके विचारों के लिए बहुत धन्यवाद, टिम


क्योंकि आप अलग-अलग AppDomains में हैं, आप उदाहरण भर में पास नहीं कर सकते।

आपको अपना प्लग-इन रिमोटेबल बनाने और अपने मुख्य ऐप में एक प्रॉक्सी बनाने की आवश्यकता होगी। CreateInstanceAndUnWrap लिए डॉक्स पर एक नज़र डालें, जिसका एक उदाहरण है कि यह सब नीचे की ओर कैसे काम कर सकता है।

यह भी जॉन शेमिट्ज द्वारा एक और अधिक व्यापक अवलोकन है जो मुझे लगता है कि एक अच्छा पढ़ा है। सौभाग्य।


यदि आपको अपने ऐप के बाकी हिस्सों की तुलना में कम सुरक्षा विशेषाधिकारों के साथ लोड करने के लिए आपके तीसरे पक्ष के एक्सटेंशन की आवश्यकता है, तो आपको एक नया AppDomain बनाना चाहिए, उस ऐप डोमेन में अपने एक्सटेंशन के लिए MEF कंटेनर बनाएं और फिर अपने एप्लिकेशन से ऑब्जेक्ट्स पर marshall कॉल करें सैंडबॉक्स वाले ऐप डोमेन में। सैंडबॉक्सिंग होता है कि आप ऐप डोमेन कैसे बनाते हैं, इसमें MEF के साथ कुछ भी नहीं है।


हमारे साथ समाधान साझा करने के लिए धन्यवाद। मैं एक महत्वपूर्ण टिप्पणी और एक आत्मसात करना चाहूंगा।

टिप्पणी यह ​​है कि आप होस्ट से अलग AppDomain में लोड करके एक प्लगइन को 100% नहीं कर सकते। यह जानने के लिए, DoSomethingDangerous को निम्न में अपडेट करें:

public override void DoSomethingDangerous()                               
{                               
    new Thread(new ThreadStart(() => File.ReadAllText(@"C:\Test.txt"))).Start();
}

चाइल्ड थ्रेड द्वारा उठाया गया एक अखंड अपवाद पूरे एप्लिकेशन को क्रैश कर सकता है।

अनहेल्ड अपवादों से संबंधित जानकारी के लिए this पढ़ें।

आप इन दो ब्लॉग प्रविष्टियों को System.AddIn टीम से भी पढ़ सकते हैं, जो बताती हैं कि 100% अलगाव केवल तभी हो सकता है जब ऐड-इन एक अलग प्रक्रिया में हो। उनके पास एक उदाहरण यह भी है कि ऐड-इन से सूचनाएं प्राप्त करने के लिए कोई क्या कर सकता है जो उठाए गए अपवादों को संभालने में विफल रहता है।

http://blogs.msdn.com/b/clraddins/archive/2007/05/01/using-appdomain-isolation-to-detect-add-in-failures-jesse-kaplan.aspx

http://blogs.msdn.com/b/clraddins/archive/2007/05/03/more-on-logging-unhandledexeptions-from-managed-add-ins-jesse-kaplan.aspx

अब मैं जो सुसाइड करना चाहता था, उसे प्लगइन्फाइंडर.इंडप्लगिन्स विधि से करना था। प्रत्येक उम्मीदवार असेंबली को एक नए AppDomain में लोड करने के बजाय, यह इस प्रकार और AppDomain को अनलोड करने पर प्रतिबिंबित करता है, आप Mono.Cecil उपयोग कर सकते हैं। फिर आपको इसमें से कुछ भी नहीं करना पड़ेगा।

यह उतना ही सरल है:

AssemblyDefinition ad = AssemblyDefinition.ReadAssembly(assemblyPath);

foreach (TypeDefinition td in ad.MainModule.GetTypes())
{
    if (td.BaseType != null && td.BaseType.FullName == "MyNamespace.MyTypeName")
    {        
        return true;
    }
}

सेसिल के साथ ऐसा करने के और भी बेहतर तरीके हैं, लेकिन मैं इस लाइब्रेरी का विशेषज्ञ उपयोगकर्ता नहीं हूं।

सादर,





maf