MvcSiteMapNodeProvider с защитой обрезки enabled throws sql exception

Question

Когда я запускаю приложение MVC5 EF6 MSSQL 2012, я получаю следующее исключение.

Я отслеживал проблему вниз к линии в моей конфигурации

<add key="MvcSiteMapProvider_SecurityTrimmingEnabled" value="true" /> 

После того, как я удалить эту строку, мой сайт строит правильно, но с курсом по ролям безопасности отключена, так что теперь мое меню сломана.

Весь раздел AppSettings выглядит следующим образом

<appSettings> 
<add key="webpages:Version" value="3.0.0.0" /> 
<add key="webpages:Enabled" value="false" /> 
<add key="ClientValidationEnabled" value="true" /> 
<add key="UnobtrusiveJavaScriptEnabled" value="true" /> 
<add key="SkipApplicationAuthorizationRole" value="Developer" /> 
<add key="MvcSiteMapProvider_UseExternalDIContainer" value="false" /> 
<add key="MvcSiteMapProvider_ScanAssembliesForSiteMapNodes" value="false" /> 
<add key="MvcSiteMapProvider_IncludeAssembliesForScan" value="Triton.Web" /> 
<add key="MvcSiteMapProvider_SecurityTrimmingEnabled" value="true" /> 
<add key="MvcSiteMapProvider_AttributesToIgnore" value="type" /> 
<add key="MvcSiteMapProvider_DefaultSiteMapNodeVisibiltyProvider" value="MvcSiteMapProvider.FilteredSiteMapNodeVisibilityProvider, MvcSiteMapProvider" /> 
<add key="mvc" /> 
<add key="Twilio.Sid" value="PNf8944dec9bf751ad111f87e1a7ece2b3" /> 
<add key="Twilio.Token" value="2d1a16e5f7109c56307cc6b696ff1de4" /> 
<add key="Twilio.Phone" value="3362522181" /> 

Любые мысли о том, как решить эту проблему?

Редактировать Я забыл упомянуть, что при запуске локально с точкой строки подключения к серверу SQL производства, это не проблема, но я предоставлю мой connection string тем не менее.

<add name="DefaultConnection" connectionString="Data Source=localhost;Initial Catalog=name; User ID=user;Password=password;Integrated Security=False;" providerName="System.Data.SqlClient" /> 

Answer 1

Добавление следующего кода в мой web.config исправил мою проблему. Это переопределяет другие файлы конфигурации на сервере хостинговых компаний для ключей.

<membership> 
    <providers> 
    <clear /> 
    <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="DefaultConnection" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" /> 
    </providers> 
</membership> 
<profile> 
    <providers> 
    <clear /> 
    <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="DefaultConnection" applicationName="/" /> 
    </providers> 
</profile> 
<roleManager enabled="false"> 
    <providers> 
    <clear /> 
    <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="DefaultConnection" applicationName="/" /> 
    <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" /> 
    </providers> 
</roleManager> 

Answer 2

Обрезка безопасности создает экземпляр контроллера для каждого узла в SiteMap. Хотя он не взаимодействует с инфраструктурой сущности, доллары на пончики один или несколько конструкторов контроллера.

Чтобы использовать эту функцию, важно следить за центрирующим подходом к контроллерам, даже если вы на самом деле не используете DI. Другими словами, конструкторы всегда должны быть простыми и легкими - они должны делать не что иное, как назначать зависимости (независимо от того, действительно ли вы можете передать их в конструктор). См. this answer для нескольких решений по устранению проблем с конструктором.

Другая возможность заключается в том, что у вас есть собственный подкласс AuthorizeAttribute, который вызывает вызовы в базе данных. Если им не требуется определять, разрешен ли пользователь, вы должны отложить эти вызовы с помощью обработчика так же, как это делает Microsoft. MvcSiteMapProvider не выполняет обработчик, но выполняет логику, которая определяет, разрешен ли пользователь.

Вот отрывок из AuthorizeAttribute из MVC 5.2 (через отражатель):

/* Defer execution of result to a handler */ 
protected virtual void HandleUnauthorizedRequest(AuthorizationContext filterContext) 
{ 
    filterContext.Result = new HttpUnauthorizedResult(); 
} 

public virtual void OnAuthorization(AuthorizationContext filterContext) 
{ 
    if (filterContext == null) 
    { 
     throw new ArgumentNullException("filterContext"); 
    } 
    if (OutputCacheAttribute.IsChildActionCacheActive(filterContext)) 
    { 
     throw new InvalidOperationException(MvcResources.AuthorizeAttribute_CannotUseWithinChildActionCache); 
    } 
    if (!filterContext.ActionDescriptor.IsDefined(typeof(AllowAnonymousAttribute), true) && !filterContext.ActionDescriptor.ControllerDescriptor.IsDefined(typeof(AllowAnonymousAttribute), true)) 
    { 
     if (this.AuthorizeCore(filterContext.HttpContext)) 
     { 
      HttpCachePolicyBase cache = filterContext.HttpContext.Response.Cache; 
      cache.SetProxyMaxAge(new TimeSpan(0L)); 
      cache.AddValidationCallback(new HttpCacheValidateHandler(this.CacheValidateHandler), null); 
     } 
     else 
     { 
      this.HandleUnauthorizedRequest(filterContext); 
     } 
    } 
}