ASP.NET MVC Пользовательская Авторизация - PullRequest
24 голосов
/ 09 июня 2009

У меня вопрос по поводу пользовательской авторизации в MVC.

У меня есть сайт, который я хочу ограничить доступ к определенным страницам, в зависимости от их членства в группе. Теперь я видел множество примеров того, как это сделать, если есть, например, одна группа администраторов и одна группа пользователей, но нет примеров для третьего уровня.

Например, только пользователи компании могут просматривать заказы для своей компании (и у каждой компании есть свои администраторы и т. Д.). Эти компании хранятся в БД. Итак, я видел способы сделать пользовательскую авторизацию, переопределяя метод AuthorizeCore на AuthorizeAttribute, но я не знаю, как получить доступ к параметрам, передаваемым в контроллер, чтобы посмотреть, есть ли у пользователя доступ к заказу (заказу). идентификатор, например).

Является ли это даже лучшим местом для проверки, или это должно быть сделано непосредственно из метода контроллера?

Ответы [ 3 ]

30 голосов
/ 09 июня 2009

AuthorizationContext (параметр OnAuthorize) предоставляет доступ к Controller, 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 */);
}
2 голосов
/ 09 июня 2009

Если авторизация действительно такая динамическая, я бы обработал ее в контроллере. У меня есть одно действие, где я делаю это - вы можете вернуть HttpUnauthorizedResult для перенаправления на страницу входа в систему или вы можете показать пользовательскую ошибку в вашем представлении.

Я не перенаправляю по умолчанию на страницу входа, когда кто-то уже вошел в систему, но не в нужной роли. Это очень запутанно для пользователя.

1 голос
/ 09 июня 2009

Мой ответ не велик, потому что он убивает юнит-тестирование, но я получаю значения из System.Web.HttpContext.Current.Session. Синглтон доступен на протяжении всего проекта. Сохраняя текущего пользователя в сеансе, вы можете получить к нему доступ из любого места, включая служебные классы, такие как AuthorizeAttribute.

Хотелось бы увидеть тестируемое модулем решение.

...