2017-02-12 2 views
0

Большинство статей/примеров, которые я нахожу в отношении прав доступа для asp.net mvc, связаны с ограничением доступа к определенным контроллерам с использованием ролей, но я пытаюсь выяснить, права доступа должны быть назначены пользователю, принадлежащему к определенной роли.Назначение прав доступа к ролям в asp.net mvc

Мой сценарий довольно прост, как только роль, которая требует прав доступа на уровне пользователей является «Staff Members» Роль:

  • Администратор: доступ ко всем функциям.
  • Персонал: доступ к определенным функциям.
  • Участник: Доступ к определенным функциям отсутствует.

В идеале я хотел бы реализовать нечто подобное ниже

@if (@User.IsInRole("IsAdmin") || (@User.IsInRole("IsStaff") && 
    @User.HasAccess("DownloadData")) 
{ 
    <a href='@Url.Action("DownloadData".... 
    </a>  
} 

У меня есть отдельная таблица, где я хранить права доступа сотрудников и поскольку они назначаются на уровне пользователя, Я использую тот же Id, сгенерированный в AspNetUsers, поэтому простое объединение EF/SQL Linq делает трюк, когда я вхожу в систему, чтобы получить соответствующие права доступа для конкретного сотрудника.

Теперь мои вопросы:

  1. Могу ли я расширить @user (Принципал), чтобы иметь сценарий, аналогичный приведенному выше путем введения новой функции такой есть HasAccess, где я мог бы передать право доступа, который необходимо для проверки конкретного сотрудника.

  2. Если 1. не может быть выполнено, передается ли право входа пользователя в систему в режим ViewModel, используемый для создания моей страницы, является жизнеспособным вариантом? Это слишком рискованно? Я ошибаюсь, полагая, что это должно быть хорошо, поскольку это код на основе сервера и не будет передан на стороне клиента?

  3. Если 1 & 2 не подходят, какой лучший/рекомендуемый метод для достижения этого?

Благодаря

ответ

0

Проще всего было бы создать метод расширения на IPrincipal или IClaimsPrincipal. Таким образом, вы можете унифицировать определения прав доступа в одном месте. Если у вас много проверок прав доступа, возможно, вам нужно добавить права доступа в качестве претензий (если вы используете претензии) или кэшировать их так или иначе, чтобы каждый раз вам не нужен доступ к базе данных (если они хранятся в базе данных) ,

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

+0

Хорошо, я поеду на исследовательский вариант 1 и посмотрю, что можно сделать. Если у вас есть какие-либо связи интересов, не могли бы вы их опубликовать. – Thierry

+0

Я нашел этот вопрос на SO, и хотя он объясняет, как расширить IPrincipal, я все еще не уверен, как его использовать. Я могу заменить свой ApplicationUser: IdentityUser на ApplicationUser: UserPrincipal, где UserPrincipal наследуется от IPrincipal? – Thierry

+0

В новых версиях ASP.NET MVC вам не нужно распространять Принципала, поскольку он использует претензии. Вы просто добавляете свои права доступа в качестве новых требований.Кроме того, чтобы добавить функцию для проверки прав доступа, возможно, этого достаточно, чтобы создать метод расширения вместо использования наследования. –

Смежные вопросы