2009-10-12 8 views
10

मैं एएसपी.नेट एमवीसी 1.0 का उपयोग कर एक एप्लीकेशन पर काम कर रहा हूं और मैं एक कस्टम आईपीआरआईआरपीआर ऑब्जेक्ट को HttpContext.Current.User ऑब्जेक्ट में इंजेक्ट करने की कोशिश कर रहा हूं।एएसपी.नेट एमवीसी कस्टम आईप्रिनियर इंजेक्शन

पारंपरिक वेबफॉर्म एप्लिकेशन के साथ मैंने इस प्रकार ऐसा करने के लिए Application_AuthenticateRequest ईवेंट का उपयोग किया है।

protected void Application_AuthenticateRequest(object sender, EventArgs e) 
    { 
     if (HttpContext.Current.User != null) 
     { 
      if (HttpContext.Current.User.Identity.IsAuthenticated) 
      { 
       if (HttpContext.Current.User.Identity is FormsIdentity) 
       { 
        // Get Forms Identity From Current User 
        FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity; 
        // Get Forms Ticket From Identity object 
        FormsAuthenticationTicket ticket = id.Ticket; 
        // Create a new Generic Principal Instance and assign to Current User 
        SiteUser siteUser = new SiteUser(Convert.ToInt32(id.Name)); 

        HttpContext.Current.User = siteUser; 
       } 
      } 
     } 

    } 

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

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

एएसपी.नेट एमवीसी 1.0 के भीतर HttpContext.Current.User ऑब्जेक्ट में मेरे कस्टम आईप्रिंसिपल इंजेक्शन के बारे में कोई मदद या सुझाव मुझे बहुत सराहना की जाएगी। मैंने SO पर निम्न पोस्ट देखा था, लेकिन ऐसा लगता है कि मैं जो हासिल करने की कोशिश कर रहा हूं उसे पूरा करने के लिए प्रतीत नहीं होता: ASP.NET MVC - Set custom IIdentity or IPrincipal

टीआईए।

+0

फ़ाइल प्रकार के बावजूद यह मरना नहीं चाहिए - आप क्या त्रुटि देख रहे हैं? – blowdart

+0

मुझे अनुरोध किए गए प्रत्येक संसाधन के लिए Application_AuthenticateRequest विधि पर "हिट" मिलता है। यह पृष्ठ को एप्लिकेशन_एट प्रमाणीकरण रिवेस्ट विधि के बिना चलने की तुलना में धीरे-धीरे दर्दनाक रूप से प्रस्तुत करता है। SiteUser ऑब्जेक्ट के लिए कन्स्ट्रक्टर विशेष रूप से शानदार नहीं करता है, केवल डीबी से उपयोगकर्ता विवरण और भूमिका सूची प्राप्त करता है। –

+0

बेशक आप ऐसा करते हैं, इस तरह IIS7 काम करता है - मैंने सोचा था कि आप एक त्रुटि – blowdart

उत्तर

8

मेरी समस्या यह है कि ASP.NET MVC साथ Application_AuthenticateRequest आग जब भी किसी भी अनुरोध बनाया जो मरने के लिए आवेदन का कारण बनता है (ताकि जे एस फ़ाइलें, चित्र आदि के लिए) है लगता है।

यह एक विशिष्ट एमवीसी समस्या नहीं है - यदि आपने आईआईएस 7 पर एकीकृत पाइपलाइन के साथ अपना आवेदन चलाया तो आप एक ही चीज़ देखेंगे।

तो देखने के साथ समस्या यह scalability है तो मुझे लगता है वास्तविक समस्या है

भीतर
FormsAuthenticationTicket ticket = id.Ticket; 
SiteUser siteUser = new SiteUser(Convert.ToInt32(id.Name)); 

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

यदि आप ऐसा करते हैं तो आप एक कदम आगे जा सकते हैं, थ्रेड सिद्धांत को अपने साइट यूज़र के साथ बदल सकते हैं, या कम से कम एक कस्टम आईप्रिनिपियर/आईयूसर संयोजन जिसमें आपकी साइट यूज़र कक्षा के समान जानकारी होगी।

तो AuthenticateRequest अंदर आप की तरह

SiteUserSecurityToken sessionToken = null; 
if (TryReadSiteUserSecurityToken(ref sessionToken) && sessionToken != null) 
{ 
    // Call functions to attach my principal. 
} 
else 
{ 
    if (HttpContext.Current.User != null && 
     HttpContext.Current.User.Identity.IsAuthenticated && 
     HttpContext.Current.User.Identity is FormsIdentity) 
    { 
     // Get my SiteUser object 

     // Create SiteUserSecurityToken 

     // Call functions to attach my principal. 
    } 
} 

कुछ प्रवाह और समारोह प्रिंसिपल आप सुनिश्चित करने के लिए चाहता हूँ की तरह

HttpContext.Current.User = sessionSecurityToken.ClaimsPrincipal; 
Thread.CurrentPrincipal = sessionSecurityToken.ClaimsPrincipal; 
this.ContextSessionSecurityToken = sessionSecurityToken; 

कुछ शामिल होगा संलग्न करना चाहते हैं कि कार्य जो कुकी टोकन को कम से कम एक चेकसम/मैक वैल्यू में सुरक्षा टोकन लिखें, और यदि आप चाहें तो मशीन कुंजी का उपयोग करके एन्क्रिप्शन का समर्थन करें यदि यह ऐसा करने के लिए कॉन्फ़िगर किया गया है।पढ़ने के कार्यों को इन मानों को मान्य करना चाहिए।

+0

यह बढ़िया है, धन्यवाद। मेरे हिस्से पर एक स्कूली लड़का त्रुटि! बहुत धन्यवाद। –

1

यह custom Authorization Filter के लिए नौकरी की तरह लगता है।

+0

के साथ मरने का मतलब है मैंने इस पर विचार किया है, लेकिन मैं अपने दृढ़ टाइप किए गए उपयोगकर्ता ऑब्जेक्ट को अन्य तरीकों से भी उपयोग करने में सक्षम होना चाहता हूं। मैं उम्मीद कर रहा था कि मुझे कस्टम प्राधिकरण फ़िल्टर का उत्पादन नहीं करना पड़ेगा और उसके बाद कस्टम उपयोगकर्ता नियंत्रक वर्ग में मेरी उपयोगकर्ता ऑब्जेक्ट्स को तारों को शुरू करना होगा, लेकिन ऐसा लगता है कि यह जाने का तरीका हो सकता है। मैं वास्तव में एक कस्टम सदस्यता प्रदाता को भी लागू नहीं करना चाहता हूं। किसी भी तरह के सुझाव के लिए धन्यवाद :) यह तेजी से दिख रहा है जैसे यह दृष्टिकोण है जिसे मुझे लेने के लिए मजबूर किया जाएगा। –

+0

यदि आप समझाते हैं * क्यों * आप कस्टम प्रिंसिपल इंजेक्शन दे रहे हैं, तो शायद अन्य समस्याएं हैं, एएसपी.नेट एमवीसी, आपकी समस्या का समाधान करने के तरीके। – bzlm

संबंधित मुद्दे