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

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

Matt прав.

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

Так два решения:

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

, Но отвечать на вопрос, Авторизация только для высказывания "да, Этот человек может использовать изменить пользовательское действие", не на основе вводимого параметра.

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

Более элегантным решением было бы написать свой собственный фильтр действий авторизации, либо расширив [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]).

Мои $ .02:

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

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

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

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

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