ASP.NET MVC Авторизация и роли для team_id

Question

Я начинаю проект с использованием ASP.NET MVC и не могу понять, каков наилучший способ обработки авторизации и ролей на основе team_id. Каждая запись в блоге или сообщение на форуме, которые я читаю, всегда говорят об определении глобальной роли («admin», «helpdesk», «editor» и т. Д.) С использованием членства asp.net или создании фильтра CustomAuthorize. Проблема в моем приложении состоит в том, что нет глобальных ролей. Пользователь будет менеджером team1, но не сможет редактировать или просматривать данные team2. Итак, детали авторизации: - Пользователь может просматривать планирование своей команды и доступность своих товарищей по команде, но не может видеть другие команды - менеджер команды может редактировать данные команды, но не может редактировать данные других команд - В команде может быть 1 или несколько менеджеров - Пользователь может быть частью 1 или нескольких команд

Банкомат, у меня есть 3 таблицы для обработки этого отношения.

teams --> teams_users <-- users
team_id   #team_id        user_id
          #user_id
          isManager?

В крайнем случае, я планирую сохранить текущий идентификатор team_id и isManager пользователя в сеансных переменных при его входе в систему и создать фильтр CustomAuthorize, который будет проверять, совпадает ли идентификатор team_id сессии с model.team_id. Дайте мне знать, если есть другой способ сделать это. Спасибо

Answer 1

Я думаю, что ваше решение выглядит хорошо. Если вы сильно полагаетесь на роли ASP.NET, чтобы выполнить начальный подъем для вас, у вас будет много проблем:

Пользователь 1 - менеджер для команды 1 и обычный пользователь для команды 2. ViewSchedule доступен только для пользователей и доступен для редактирования менеджерам. Код на ViewSchedule:

if (User.IsInRole("manager")) {
    if (isTeamManager(userid)) {}
}
else {}

bool isTeamManager(int userid) {
    return db.IsTeamManager(userid) {
}

Если вы сделаете это, то, когда пользователь использует команду 2, он вообще пропустит этот блок. Он является менеджером в отношении ролей ASP.NET, но не для этой команды. Нет проблем, очевидно, мы можем объединить условия следующим образом:

if (User.IsInRole("manager") && isTeamManager(userid)) { }
else {}

О, да, и если мы вызываем isTeamManager (), то мы уже получаем единственную информацию, которую предоставляет User.IsInRole ("manager"), поэтому нам это даже не нужно:

if (isTeamManager(userid)) { }
else {}

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

Answer 2

Наконец-то я создал собственный маршрут:

/{team_id}/controller/action/{id}

{team_id} устанавливается, когда пользователь входит в систему, а затем настраиваемый фильтр проверяет, что пользователь входит в команду поверх каждого контроллера. Всякий раз, когда он меняет команду, {team_id} обновляется. Кроме того, существует фильтр «isManager» для обеспечения определенных действий менеджера, который проверяет, является ли пользователь руководителем текущей группы. Спасибо, ребята, за ваши ответы

Answer 3

Я бы тогда имел 2 роли - Менеджер и Пользователь Тогда я бы связал в базе данных, как вы указали.

Роли контролируют, какие действия может выполнять каждый пользователь (пользователь может просматривать информацию, менеджер может редактировать / создавать информацию), затем в каждом действии я бы быстро проверял, может ли текущий пользователь. Выполните это действие в команде, которое потребуется (т. Е. Имеет ли пользователь доступ к команде).

Answer 4

Я разработал два пользовательских атрибута для обработки таких случаев: RoleOrOwnerAuthorization и RoleOrOwnerAssociatedAuthorization. RoleOrOwner проверяет, совпадает ли текущий пользователь системы с идентификатором пользователя рассматриваемых данных. То есть вы имеете право просматривать свои собственные данные. RoleOrOwnerAssociated проверяет, есть ли в таблице соединений строка, относящаяся к данным текущего пользователя. Например, у меня могут быть Группы, GroupLeaders и Пользователи, где GroupLeaders - это таблица соединений, связывающая Группы с Пользователями. Для просмотра данных группы вам нужно либо быть в роли ViewGroups, либо быть лидером группы (о чем свидетельствует строка в GroupLeaders с идентификатором группы и вашим идентификатором). Я думаю, что это работает очень хорошо.