Ограничить доступ по контроллеру или по модели?
Я только начинаю набрасывать основы веб-системы и хотел бы, чтобы у администратора была возможность ограничить доступ либо по контроллеру, либо по модели. Моя проблема в том, что я не могу решить, с кем из них (или обоими?) Мне следует идти. Есть идеи? За и против?
Сначала я склонялся к тому, чтобы делать это в контроллерах, видя, как они "контролируют" поток системы. Но затем, думая, что доступ, вероятно, должен быть ограничен данными, к которым он обращается, а не логической частью системы, я почувствовал, что действительно должен пойти с моделью.
Теперь я просто не могу решить... Я прыгал туда-сюда в течение нескольких дней, вообще не двигаясь вперед, так что теперь я обращаюсь к Тебе, о Великий Интернет, в надежде на ответы!
Моя реализация находится в C# / ASP.NET / MVC2, но я все еще работаю "теоретически", так что это не совсем зависит от фреймворка.
4 ответа
Хотя из этого могут быть исключения, контроль доступа должен выполняться контроллером.
Модели не должны обладать какой-либо процедурной функциональностью, только бизнес-логикой. Сама по себе бизнес-логика не должна быть контролируемой.
Контроллер, который содержит действия, которые "взаимодействуют" с этой бизнес-логикой и моделями, должен быть тем местом, где должен быть контроль доступа. Некоторые платформы уже предоставляют функциональные возможности для управления доступом, которые могут оценивать состояние приложения, чтобы решить, является ли определенное действие может быть выполнено.
Пример: В веб-приложении Модель "Person" содержит "Person" и имеет функцию "createNew (name)". Контроллер "PersonsController" имеет действие "addNewPerson()", которое считывает имя из HTTP Post и вызывает упомянутую функцию. выше. У него также есть правило доступа, которое гласит, что действие addNewPerson может не вызываться, если текущее состояние приложения указывает, что пользователь, запрашивающий действие, не вошел в систему.
Авторизация пользователя является строго основанной на сеансе задачей, поэтому лучше всего ее решать в контроллере. Создание моделей с учетом сессий возможно, но это нарушение интересов и определенно непростое в моем опыте. Вам также нужно беспокоиться о том, чтобы запросы были поточно-ориентированными в зависимости от вашего технологического стека.
Приложения Rails обычно решают эту проблему, добавляя функции авторизации в базовый класс Controller и позволяя вам определить before_filter либо весь контроллер или конкретные действия, которые должны авторизовать запрос.
Как правило, я ожидаю, что ваши пользователи будут иметь роли, которые имеют доступ к целому ряду функций, которые они могут выполнять на разных моделях. Этот доступ / нет доступа будет выполнен в контроллере.
В текущем проекте, над которым я работаю, мы ограничиваем доступ на уровне контроллера с помощью фильтров действий.
Фильтры действий могут быть определены для конкретного действия, если мы хотим ограничить доступ только этим определенным образом (например, определенной страницей, которую пользователь не должен видеть) или определить на контроллере, если вся эта область ограничена.
Сам фильтр действий довольно прост и использует HttpContext для определения личности пользователя, но в нашем случае мы используем аутентификацию формы, поэтому она может отличаться в зависимости от того, какой тип механизма аутентификации вы используете.