Зачем мне жестко прописывать пользовательские разрешения в атрибутах моего контроллера?

Question

Я видел пример кода, который выглядит следующим образом, который выглядит вполне разумным:

[Authorize(Roles = "Admin, User")] 
public class SomeController : Controller 

Но я также видел несколько примеров, которые выглядят так:

[Authorize(Users = "Charles, Linus")] 
public class SomeController : Controller 

Зачем мне это делать? Я не могу представить ни одного сценария, в котором я хотел бы создать систему, которая заранее знает имена пользователей.

Answer 1

Существует несколько законных способов использования этого, и вот один пример: если вы создаете действительно простой сайт, у которого просто есть учетная запись администратора и учетная запись без аутентификации, вы можете сделать

[Authorize(Users = "Admin")] 

Это избавляет вас от необходимости создавать роли только для одного пользователя. Подумайте о стиле UNIX, где учетная запись root (uid 0) является особенной, а не определенной группой.

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

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

Answer 2

Единственная «законная» причина, по которой я могу придумать, - это построить черный ход - либо для гнусной, либо для «будущей эксплуатации» цели. Последний - Бад Джуджу, поскольку он представляет угрозу безопасности. Первый, конечно же, Бад Джуджу:)

Answer 3

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

Редактировать: Я полагаю, что, например, когда .net 1.0 поражает весь web.config с разрешениями разрешить / запретить, они (или, по крайней мере, ДОЛЖНЫ быть) используются в качестве примера соуса, даже если я нахожусь в куче люди, которые считают, что блоги, учебные пособия и примеры должны использовать только передовой опыт.

Answer 4

Я согласен с Дэвидом Пфеффером.

Кроме того, я думаю, что вы могли бы определить набор пользователей с очень конкретными разрешениями и заданиями внутри вашего приложения - возможно, в целях тестирования, возможно, отслеживания производительности ... вы будете знатькогда требование стучать в дверь;) -.

Просто группа, которая не должна содержаться в наборе допустимых пользователей, используемых вашим приложением.:) -хардкорный путь-

Answer 5

Несколько причин, по которым вы могли бы подумать об этом:

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

В любом случае все сводится к плохому дизайну, и вы не захотите это делать. Но интерфейс есть, потому что это самый простой уровень контроля.