Дизайн членства в Asp.net MVC - PullRequest
Новая
       19

Дизайн членства в Asp.net MVC

0 голосов
/ 30 октября 2009

Некоторый фон для начала:

Я реализовал пользовательский MembershipProvider , который проверяет пользователя из моего сервисного уровня с именем "WebMemberShipProvider"

В настоящее время у меня есть служба под названием «MembershipService», эта служба реализует интерфейс IMembershipService на уровне службы. этот MemberShipService запрашивает dal и проверяет пользователя на основе имени пользователя / пароля

Я также создал собственный AuthorizeAttribute с именем "AuthorizeOwnerAttribute", и именно здесь у меня возникают проблемы с дизайном.

Для каждого контроллера у меня есть зависимость от службы. например. UsersController использует IUserService в своем конструкторе.

Как я могу вызвать AuthorizeAttribute для ActionResult, где текущий вошедший в систему пользователь и редактируемый пользователь имеют одинаковый "StudioId". Примечание: я хочу использовать AuthorizeAttribute с несколькими контроллерами, а не только с «UserController»

Итак, мои вопросы к вам:

  1. Что я должен сделать, чтобы сохранить текущий аутентифицированный пользователь "StudioId", так как это будет использоваться через несколько контроллеров.
  2. Как мне передать аутентификацию на уровень сервиса, потому что я хочу проверить, что запросы действительны на уровне сервиса и доступа к данным, а не только на клиенте. (Если это целесообразно, я просто предполагаю, что проверки на клиенте достаточно, только если я хочу позже использовать BLL и DAL в автономном приложении)

Используемые технологии: - LINQ to SQL через Шаблон репозитория - ASP.NET MVC Preview 2

Любые рекомендации или примеры кода будут приветствоваться.

1 Ответ

1 голос
/ 30 октября 2009

Я в основном сделал свою безопасность в основном на уровне контроллера для чего-то вроде этого. Я принял решение не передавать информацию слишком далеко вниз по цепочке, чтобы выяснить, есть ли у человека доступ к ней или, если я это сделал, я просто убедился, что IPrincipal.IsInRole () будет достаточно для ее удовлетворения.

Теперь я сделал что-то еще, что кажется более хакерским. Мне нужно было убедиться, что люди, которые были зарегистрированы и которым был назначен этот кусок, были единственными, кто мог получить к нему доступ из этого раздела.

Итак, я создал фильтр атрибутов, который работает примерно так: 

public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            var thingToView = filterContext.ActionParameters[_thingToView] as thingToView ;
            var registration = filterContext.ActionParameters[_registration] as Registration;


            if (!registration.CanSeeThing(thingToView))
            {
                throw new RegistrationCannotViewThing(registration, thingToView);
            }

            base.OnActionExecuting(filterContext);
        }

Теперь в этой реализации ощущается что-то вроде хаки , так как я сделал это с помощью моего метода контроллера: 

[AuthFilter(ThingToView ="thingToView", Registration="registration")
public ActionResult Method(Thing thingToView, Registration registration)
{
....
}

Фактические назначения параметров произошли в подшивке модели. Безопасность происходит через фильтр, который проверяет параметры, переданные методу. Затем я повторно использовал этот фильтр во многих местах.

Я сделал нечто похожее с привязкой модели к сообщению Скотта Хансельмана: http://www.hanselman.com/blog/IPrincipalUserModelBinderInASPNETMVCForEasierTesting.aspx, чтобы передать то, что пользователь вызывает методом.

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

...