Безопасность и контроль доступа в приложении MVC

Question

Я только недавно начал работать с подходом MVC, поэтому я полагаю, что это простой способ для вас, гуру:

Где поставить контроль доступа?

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

Или есть другой вариант?

Answer 1

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

На высоком уровне вам необходимо настроить безопасность доступа в точках входа. И вам следует перепроверять безопасность доступа на каждом уровне, который можно считать автономным или повторно используемым из нескольких частей вашего приложения (кто знает, проверяется ли безопасность на портале вашего коллеги, который использует ваш логический уровень? И т. Д.). Еще одна вещь, о которой стоит беспокоиться, это безопасность данных, и она относится как можно ближе к вашим данным (так что, да, к вашему # 2 выше, но поймите, что это отдельно).

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

Answer 2

Для безопасности модели (или данных) Модель будет «контролировать» доступ, а контроллер будет «облегчать» доступ. Это предусматривает повторное использование модели независимо от контроллера и сводит к минимуму, если не отменяет общую репликацию кода, необходимую для разнородных контроллеров, использующих модель.

Например, Автомобиль, Водитель и Ключ. (Модель, Контроллер, API соответственно). Благодаря очень маленькому интерфейсу (ключ == API) Модель разрешает или запрещает доступ контроллера к API (брелок). Разрешены различные типы доступа (ключ камердинера, ключ владельца, владелец FOB). Используя ключевой интерфейс камердинера, контроллер не будет иметь доступа к некоторым данным / функциям модели, таким как перчаточный ящик, багажник и бензобак. По сути, это доступ на основе ролей, реализуемый Моделью посредством идентификации и категоризации Контроллера с очень маленькой областью API / поверхности команд.

Это означает, что Модель может использоваться другими контроллерами (автомобиль с другими водителями), которым требуется только базовая аутентификация для доступа к данным модели (функции и отделения автомобиля).