एएसपी.नेट एमवीसी - प्रशासन या प्रशासन के लिए अलग वेब अनुप्रयोग?

Question

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

यह एक हालिया परियोजना में एक समस्या बन गई है क्योंकि मैं उपयोगकर्ताओं के लिए समय समाप्त नहीं होने वाली ऑथ कुकीज़ सेट करना चाहता था, लेकिन मैं प्रशासन उपयोगकर्ताओं के लिए यह नहीं चाहता हूं। मैं यह भी नहीं चाहता कि उपयोगकर्ता लॉगिन पेज का उपयोग व्यवस्थापक उपकरणों तक पहुंचने के लिए किया जाए।

मैं पूरी तरह से व्यवस्थापक उपकरण के लिए समाधान में एक अलग एमवीसी परियोजना स्थापित करने पर विचार कर रहा हूं। यह मुझे सबसे अच्छा विकल्प लगता है, लेकिन मैं तैनाती के साथ जटिलताओं के बारे में सोच रहा हूँ। (वर्तमान में मैं निर्माण के प्रबंधन के लिए वीएस 2008 में एक वेब परिनियोजन परियोजना का उपयोग कर रहा हूं)।

क्या कोई वर्तमान में व्यवस्थापक अनुभाग के लिए एक अलग एमवीसी प्रोजेक्ट का उपयोग करता है? कोई गॉथस? अन्य राय क्यों यह एक अच्छा विचार नहीं है?

धन्यवाद।

Answer 1

मैं हमेशा प्रशासन के लिए एक अलग वेबसाइट का उपयोग कर रहा हूं। लेकिन यह मुख्य रूप से इसलिए है क्योंकि मेरी साइटों के लिए प्रशासन उपयोग से बिल्कुल अलग है और इसलिए एक अलग लेआउट की आवश्यकता है।

एक और सकारात्मक बात यह है कि आपको आश्चर्य नहीं करना चाहिए कि क्या उपयोगकर्ता उन चीजों को संशोधित करने में सक्षम हो सकते हैं जिन्हें वे संशोधित नहीं कर पाएंगे क्योंकि उन हिस्सों को उपयोगकर्ता वेबसाइट में नहीं बनाया गया है।

अद्यतन

मैं webforms साथ उस्तरा या masterpage साथ लेआउट मतलब इंजन देखने।

हम साइट को अलग करने के लिए http://admin.domainname.com और http://www.domainname.com का उपयोग करते हैं। सेटअप करने के लिए काफी आसान है।

साइट्स को अलग करने से नियंत्रक भी बहुत साफ हो जाते हैं क्योंकि वे केवल प्रशासकों या उपयोगकर्ताओं के लिए कार्यों को संभालते हैं। बहुत सारे ifs की आवश्यकता नहीं है (जो अन्यथा मेरे जैसे हैं = आलसी कोडर :)

Answer 2

FormsAuthentication.SetAuthCookie विधि आपको सत्रों में बनी रहती है या नहीं, इसे नियंत्रित करने की अनुमति देती है।

यदि वे एक व्यवस्थापक हैं, तो इसे false पर सेट करें, अन्यथा true पर।

अधिक जानकारी के लिए http://msdn.microsoft.com/en-us/library/twk5762b.aspx देखें (दूसरा पैरामीटर createPersistentCookie इसे नियंत्रित करता है)।

उपयोगकर्ता के विभिन्न वर्गों के लिए एक अलग लॉगिन पेज के संदर्भ में, यदि आप उपयोगकर्ता की गलत कक्षा हैं और गलत लॉगिन पृष्ठ तक पहुंच रहे हैं तो आप प्रमाणीकरण विधि से झूठी वापसी कर सकते हैं।

प्रमाणीकरण टोकन सेट करने से पहले यह तर्क होना चाहिए।

Answer 3

मैं नहीं बल्कि रखना प्रशासन साइट कारणों की एक संख्या के लिए अलग चाहते हैं:

• संभावित सुरक्षा जोखिम बहुत संवेदनशील क्षेत्रों के लिए उपयोग के रूप में कम कर रहे हैं को प्रतिबंधित करने और नियंत्रित करने के लिए आसान होगा।
• परतों (सेवा/डेटा इत्यादि) के बीच Separation of Concerns का मतलब है कि यह आपकी मुख्य साइट पर उपलब्ध कार्यक्षमता तक पहुंचने के लिए आपकी व्यवस्थापक साइट को तार करने के लिए अपेक्षाकृत सरल होना चाहिए।
• डेवलपर्स अपनी व्यवस्थापक साइट को पॉलिश करने के बारे में कम चिंतित हैं, क्योंकि कंपनियां आम तौर पर अपनी फ्रंट-एंड साइटों पर ध्यान केंद्रित करती हैं। इसका मतलब यह है कि व्यवस्थापक साइट को प्रभावित करने वाली लापरवाही कीड़े मुख्य को प्रभावित करने की संभावना कम होती हैं।
• मैं AuthorizeAttribute के साथ बेस नियंत्रक का उपयोग करता हूं, जिसका अर्थ है कि सभी क्रियाएं (login को छोड़कर!) उचित क्रेडेंशियल के बिना बाहरी उपयोगकर्ताओं द्वारा एक्सेस करने में असमर्थ हैं। व्यक्तिगत कार्यों को तब प्रासंगिक क्रेडेंशियल्स के साथ ओवरराइड किया जाता है जहां आवश्यक हो, लेकिन आम तौर पर, यह एक "सेट और भूल" दृष्टिकोण है। यद्यपि आप एक एकल साइट दृष्टिकोण में दो आधार नियंत्रक हो सकते हैं, मेरा मानना ​​है कि यह थोड़ा कम प्रबंधनीय होगा।

Answer 4

फॉर्म ऑथ कुकी व्यवस्थापक-क्षेत्र के लिए पथ प्रतिबंधित हो सकता है, लेकिन यह प्रमाणीकरण से निपटने के दौरान आपको कुछ सिरदर्द देगा, लेकिन हासिल करना संभव हो सकता है।

admin.hostname.com या उसके जैसा कुछ भी करने के बजाय एक अन्य विकल्प,/व्यवस्थापक पर उप-उपयोग का उपयोग करना है, हालांकि यह आपकी समस्या को हल नहीं करेगा।

हमने अपने वेब एप्लिकेशन को दो अलग-अलग साइटों के रूप में विकसित किया, मुख्य रूप से क्योंकि हम प्रशासन को वास्तविक साइट से विभाजित करने का विकल्प चाहते थे, और स्केलेबिलिटी कारणों के लिए भी। हम सवाल में वास्तविक वेबसाइट को स्केल करने में सक्षम होना चाहते थे, न कि प्रशासनिक हिस्सा।

हम निम्नलिखित समस्या आ जाती है:

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

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