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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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