Решил эту проблему, немного обойдя дома и построив новую цепочку соединений для тестирования с ADO. Все еще включает использование try catch, но это намного быстрее:
private bool TestConnection()
{
EntityConnectionStringBuilder b = new EntityConnectionStringBuilder();
ConnectionStringSettings entityConString = ConfigurationManager.ConnectionStrings["MyEntityConnectionString"];
b.ConnectionString = entityConString.ConnectionString;
string providerConnectionString = b.ProviderConnectionString;
SqlConnectionStringBuilder conStringBuilder = new SqlConnectionStringBuilder();
conStringBuilder.ConnectionString = providerConnectionString;
conStringBuilder.ConnectTimeout = 1;
string constr = conStringBuilder.ConnectionString;
using (SqlConnection conn = new SqlConnection(constr))
{
try
{
conn.Open();
return true;
}
catch
{
return false;
}
}
}
AuthorizationContext (параметр для OnAuthorize) обеспечивает доступ к Контроллеру, RouteData, HttpContext и т. Д. Вы должны иметь возможность использовать их в настраиваемом фильтре авторизации, чтобы делать то, что вы хотите. Ниже приведен пример кода из атрибута RoleOrOwnerAttribute, производного от AuthorizeAttribute.
public override void OnAuthorization( AuthorizationContext filterContext )
{
if (filterContext == null)
{
throw new ArgumentNullException( "filterContext" );
}
if (AuthorizeCore( filterContext.HttpContext )) // checks roles/users
{
SetCachePolicy( filterContext );
}
else if (!filterContext.HttpContext.User.Identity.IsAuthenticated)
{
// auth failed, redirect to login page
filterContext.Result = new HttpUnauthorizedResult();
}
// custom check for global role or ownership
else if (filterContext.HttpContext.User.IsInRole( "SuperUser" ) || IsOwner( filterContext ))
{
SetCachePolicy( filterContext );
}
else
{
ViewDataDictionary viewData = new ViewDataDictionary();
viewData.Add( "Message", "You do not have sufficient privileges for this operation." );
filterContext.Result = new ViewResult { MasterName = this.MasterName, ViewName = this.ViewName, ViewData = viewData };
}
}
// helper method to determine ownership, uses factory to get data context,
// then check the specified route parameter (property on the attribute)
// corresponds to the id of the current user in the database.
private bool IsOwner( AuthorizationContext filterContext )
{
using (IAuditableDataContextWrapper dc = this.ContextFactory.GetDataContextWrapper())
{
int id = -1;
if (filterContext.RouteData.Values.ContainsKey( this.RouteParameter ))
{
id = Convert.ToInt32( filterContext.RouteData.Values[this.RouteParameter] );
}
string userName = filterContext.HttpContext.User.Identity.Name;
return dc.Table<Participant>().Where( p => p.UserName == userName && p.ParticipantID == id ).Any();
}
}
protected void SetCachePolicy( AuthorizationContext filterContext )
{
// ** IMPORTANT **
// Since we're performing authorization at the action level, the authorization code runs
// after the output caching module. In the worst case this could allow an authorized user
// to cause the page to be cached, then an unauthorized user would later be served the
// cached page. We work around this by telling proxies not to cache the sensitive page,
// then we hook our custom authorization code into the caching mechanism so that we have
// the final say on whether a page should be served from the cache.
HttpCachePolicyBase cachePolicy = filterContext.HttpContext.Response.Cache;
cachePolicy.SetProxyMaxAge( new TimeSpan( 0 ) );
cachePolicy.AddValidationCallback( CacheValidateHandler, null /* data */);
}
Если авторизация действительно такая динамичная, я бы обработал ее в контроллере. У меня есть одно действие, в котором я это делаю - вы можете вернуть HttpUnauthorizedResult для перенаправления на страницу входа или вы можете показать настраиваемую ошибку в вашем представлении.
Я не перенаправляю по умолчанию на страницу входа, когда кто-то уже вошел в систему в, но не в правильной роли. Это очень сбивает с толку пользователя.
Мой ответ не очень хорош, потому что он убивает модульное тестирование, но я беру значения из System.Web.HttpContext.Current.Session
. Синглтон доступен на протяжении всего проекта. Сохраняя текущего пользователя в сеансе, вы можете получить к нему доступ из любого места, включая служебные классы, такие как AuthorizeAttribute
.
Тем не менее, мне бы хотелось увидеть решение с возможностью модульного тестирования.