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

Question

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

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

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

Или есть еще один вариант?

Answer 1

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

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

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

Answer 2

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

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

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