WedX - журнал о программировании и компьютерных науках

Логика приложения (правильное место для аутентификации/авторизации)

Я разрабатываю приложение, похожее на CMS, с использованием MVC 3 (RC2), и сейчас я нахожусь на распутье. Я не могу убедить себя, подходит ли мой предложенный подход или нет. Я предполагаю, что это потому, что я знаю, что пытаюсь срезать некоторые углы, которые впоследствии дорого мне обойдутся.

Перейду сразу к описанию моей проблемы:

1) У меня есть ресурс (назовем его А), который нужно сделать редактируемым.

2) У меня реализована пользовательская система разрешений, которая имеет 2 (из многих) разрешений:

  • Может редактировать собственный ресурс
  • Может редактировать другой ресурс

3) Создатель ресурса А может редактировать его, если у него есть разрешение «Может редактировать собственный ресурс».

4) Отдельный пользователь может редактировать только A, если у него есть разрешение «Может редактировать другой ресурс».

Теперь, когда требования описаны, позвольте мне рассказать вам о моем подходе:

1) У меня есть контроллер под названием ResourceController.

2) У меня есть действие под названием "Редактировать"

3) У действия есть атрибут: [CustomerAuthorize(Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true)]

4) У меня есть класс обслуживания, который занимается проверкой домена.

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

Как мне решить (и где это решение должно быть принято) о том, имеет ли пользователь право доступа или нет (в зависимости от того, владеет ли он ресурсом?) Должен ли он быть в действии контроллера, в классе обслуживания ресурса, в отдельном класс обслуживания?

Жду разных мнений...

asp.net-mvc asp.net-mvc-3 logic domain-driven-design
14.12.2010

Ответы:


1

Из-за природы MVC вам может потребоваться проверка аутентификации в различных точках.

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

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

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

14.12.2010
  • Но разве это не дублирование логики? Одни и те же проверки повторяются несколько раз? Но я понимаю вашу озабоченность. Интересно, смогу ли я увидеть некоторые проекты OSS, чтобы изучить шаблон. 14.12.2010
  • @ KiD0M4N: Есть несколько сценариев, в которых повторить некоторую логику намного проще (включая соображения долгосрочного обслуживания), чем не повторять ее. То есть иногда технологические ограничения или существующие дизайнерские решения делают неоправданно трудным достижение абсолютно чистого принципа «не повторяй себя». 14.12.2010

    • 2

    Один из способов приблизиться к этому - иметь 2 действия, а не только «Изменить», у вас есть «EditOwnResource» и «EditOtherResource». Затем вы можете разместить одно разрешение на каждом из них.

    Затем, если вы используете шаблон MVVM, вы можете привязать доступность этих действий к тому, является ли это ownResource или otherResource. Установка этих значений выполняется в модели представления.

    14.12.2010
  • Я использую ASP.NET MVC. Таким образом, биты MVVM не применяются. Но я подумаю о двух отдельных передних действиях. Но это, вероятно, будет невозможно в моем конкретном случае 14.12.2010
    • Новые материалы
    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..
    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..
    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..
    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..
    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..
    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..
    ИИ в аэрокосмической отрасли
    Каждый полет – это шаг вперед к великой мечте. Чтобы это происходило в их собственном темпе, необходима команда астронавтов для погони за космосом и команда технического обслуживания..
    Для любых предложений по сайту: [email protected]