Почему был бы я полномочия пользователя твердого кода в моих атрибутах контроллера?
Я видел пример кода, который похож на это, которое кажется совершенно разумным:
[Authorize(Roles = "Admin, User")]
public class SomeController : Controller
Но я также видел несколько примеров, которые похожи на это:
[Authorize(Users = "Charles, Linus")]
public class SomeController : Controller
Почему я когда-либо хотел бы сделать это? Я не могу вообразить сценарий, где я хотел бы создать систему, которая знает ее имена пользователей заранее.
5 ответов
Есть несколько законных применений этого, и вот один пример: если вы создаете действительно простой сайт, на котором просто есть учетная запись администратора и неаутентифицированная учетная запись, вы можете сделать
[Authorize(Users = "Admin")]
Это избавит вас от необходимости беспокоиться о создании ролей только для одного пользователя. Подумайте о стиле UNIX, где учетная запись root (uid 0) является особенной, а не конкретной группой.
Другой пример - это одноразовое приложение, в котором вы что-то тестируете. Нет причин возиться с ролями, если вы просто хотите протестировать свою страницу аутентификации или что-то в этом роде.
Еще одна причина: тестирование. Вы можете создать модульный тест только для аутентификации, не желая проводить модульное тестирование своей ролевой структуры. (Имейте в виду, что не все используют поставщика членства по умолчанию, а некоторые поставщики членства довольно сложны.) Создав жестко закодированную аутентификацию для тестового пользователя, вы можете обойти структуру ролей.
Единственная «законная» причина для этого, которую я могу придумать, - это строительство черного хода - либо для гнусных целей, либо для целей «технического обслуживания в будущем». Последний вариант называется Бад-Жужу, поскольку представляет собой угрозу безопасности. Первый, конечно, тоже Bad Juju :)
Пара причин, по которым вы можете это сделать:
- Ожидается, что приложение будет иметь очень короткий жизненный цикл и не будет {{ 1}} требуется обслуживание.
- Рассматриваемые пользователи могут не принадлежать к достаточно определенной группе (как в случае малого бизнеса), и нет ожидаемых изменений. (все еще очень плохой дизайн, но не будет неслыханным)
- У вас может быть несколько перегрузок в небольшом {{1 }} приложение, которое требует различного поведения для отдельных лиц в группе.
В любом случае все сводится к плохому дизайну, и вы бы не захотели этого делать. Но интерфейс есть, потому что это самый простой уровень управления.
Я согласен с Дэвидом Пфеффером.
Вдобавок я думаю, что вы можете определить набор пользователей с очень конкретными разрешениями и заданиями внутри вашего приложения - возможно, в целях тестирования, возможно, отслеживания производительности ... вы узнаете это, когда требование постучит в дверь; ) -.
Просто группа, которая не должна входить в набор допустимых пользователей, используемых вашим приложением. :) -хардкорный способ-
Вы бы не стали, жесткое кодирование пользователей - это плохой запах. Для таких вещей существуют роли.
Edit: I believe that, like when .net 1.0 hit with the whole web.config with allow/deny permissions, those are (or at least SHOULD ONLY be) used as example sauce, even if if I'm into the pile of people that believe that blogs, tutorials and samples should only use good practices.