asp.net авторизация mvc с использованием ролей - PullRequest
Новая
       44

asp.net авторизация mvc с использованием ролей

24 голосов
/ 24 декабря 2008

Я создаю приложение asp.net mvc, которое имеет концепцию пользователей. Каждый пользователь может редактировать свой профиль. Например:

Ничего особенно захватывающего там нет ...

Однако у меня возникли некоторые проблемы со схемой авторизации. Сейчас в системе только две роли: «Администратор» и «DefaultUser», но в будущем их, вероятно, будет больше.

Я не могу использовать обычный атрибут Authorize для указания Авторизации, поскольку оба пользователя находятся в одной роли (т. Е. "DefaultUser").

Итак, если я укажу фильтр авторизации следующим образом: 

[Authorize(Roles = "DefaultUser")]

тогда эффекта нет. PersonID = 1 может войти и отредактировать свой собственный профиль (как они должны), но они также могут просто изменить URL-адрес на http://localhost/person/edit/2, и у них также есть полный доступ для редактирования профиля PersonID = 2 (который они не должны быть в состоянии сделать).

Значит ли это, что мне нужно создать собственный фильтр авторизации, который проверяет, принадлежит ли ему запрашиваемое действие, прежде чем разрешить ему доступ? То есть, если текущее вошедшее в систему лицо запрашивает действие редактирования с параметром = 1, нужно ли выполнять пользовательскую проверку, чтобы убедиться, что в данный момент зарегистрированное лицо имеет значение PersonID = 1, и, если это так, авторизовать их? и если нет, запретить доступ?

Чувствуется, что я упускаю что-то очевидное здесь, поэтому любые указания будут оценены.

Ответы [ 5 ]

62 голосов
/ 24 декабря 2008

Возможно, вы могли бы организовать действие контроллера таким образом, чтобы URL был больше похож на http://localhost/person/editme, и он отображал форму редактирования для текущего пользователя, вошедшего в систему. Таким образом, пользователь не сможет взломать URL, чтобы отредактировать кого-то еще.

36 голосов
/ 28 июня 2009

Мои $ .02:

Авторизованные и аутентифицированные две разные вещи. Проще говоря, вопрос в том, можете ли вы сделать эту вещь, вы должны это делать? Вы можете выбрать своих друзей, вы можете выбрать свой нос, но вы не можете выбрать свой нос друзей! Нет необходимости проверять авторизацию, если каждая роль может это сделать (у пользователя есть рука и нос). Предложите пользователям метод Post, чтобы получить доступ к своему профилю и проверить идентификатор профиля со скрытыми значениями формы или перенаправить (не твой нос, уходи)

Есть метод Get для редактирования других профилей и просто проверьте роль администратора здесь - (я доктор, я уполномочен засовывать вещи в нос) ...

16 голосов
/ 25 июня 2009

Более элегантным решением было бы написать собственный фильтр действий авторизации, либо расширив [Authorize], либо внедрив IAuthorizationFilter, следующим образом: 

public class AuthorizeOwnerAttribute: FilterAttribute, IAuthorizationFilter
{
    #region IAuthorizationFilter Members

    public void OnAuthorization(AuthorizationContext filterContext)
    {
        // add logic here that compares the currently logged in user, to the owner of the profile that is being edited
        // get currently logged in user info from filterContext.HttpContext.User.Identity;
        // get profile being edited from filterContext.RouteData or filterContext.Something
    }

    #endregion
}

Я не уверен в том, какая логика будет в методе OnAuthorization, но мои комментарии должны дать вам отправную точку. Чтобы узнать больше, вам придется обратиться в Google - как перенаправить пользователя в другое представление или сгенерировать строго типизированное исключение, которое обрабатывается где-то еще (возможно, в атрибуте [HandleError]).

10 голосов
/ 24 декабря 2008

Мэтт прав.

Для этого нужно показать, что им разрешено выполнять эту функцию - вы пытаетесь сказать, могут ли они выполнять эту функцию для этого конкретного идентификатора.

Итак, два решения:

  1. Как сказал Мэтт, выполните действие, которое не требует идентификатора, но ищет текущего пользователя, вошедшего в систему, из информации о сеансе и извлекает их.
  2. Выполните действие, которое принимает идентификатор, но разрешает доступ только администраторам, чтобы они могли при необходимости изменять информацию других пользователей.

Но для ответа на вопрос авторизация должна только сказать «Да, этот человек может использовать действие изменения пользователя», а не на основе введенного параметра.

Другой способ заключается в том, что вы можете заставить его проверить, что пользователь получил == текущего пользователя, или перенаправить на другое действие, сказав, что они не могут редактировать этого пользователя - но было бы лучше просто предоставить действие, которое взять идентификатор и просто получить текущего вошедшего в систему пользователя.

4 голосов
/ 22 февраля 2010

Решение этой проблемы: http://nerddinnerbook.s3.amazonaws.com/Part9.htm

"Использование свойства User.Identity.Name при редактировании обедов

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

...