Ограничить доступ по контроллеру или по модели?

Question

Я только начинаю делать набросок основы веб-системы и хотел бы, чтобы у администратора была возможность ограничить доступ либо по контроллеру, либо по модели.Моя проблема в том, что я не могу решить, с кем (или обоими?) Мне следует идти.Есть идеи?Плюсы / минусы?

Сначала я склонялся к тому, чтобы делать это в контроллерах, видя, как они «контролируют» поток системы.Но потом, думая, что доступ, вероятно, должен быть ограничен данными, к которым он обращается, а не логической частью системы, я почувствовал, что действительно должен пойти с моделью.

Теперь я просто не могу решить.Я прыгал туда-сюда несколько дней назад, вообще не двигаясь вперед, так что теперь я обращаюсь к Тебе, о Великий Интернет, в надежде на ответы!

Моя реализация в C # /ASP.NET / MVC2, но я все еще работаю «теоретически», так что это не совсем зависит от фреймворка ..

Answer 1

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

Модели не должны содержать никаких процедурных функций, только бизнес-логика.Сама по себе бизнес-логика не должна контролироваться.

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

Пример: В веб-приложении Модель "Person" содержит "персоны" и имеет функцию 'createNew (name)' Контроллер 'PersonsController' имеет действие 'addNewPerson() ', который читает имя из HTTP Post и вызывает функцию, упомянутую выше.У него также есть правило доступа, которое говорит, что действие addNewPerson не может быть вызвано, если текущее состояние приложения указывает, что пользователь, запрашивающий действие, не вошел в систему.

Answer 2

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

Способ, которым приложения Rails обычно справляются с этим, заключается в добавлении функций авторизации в базовый класс Controller и предоставлении вам возможности определить before_filter либо всему контроллеру, либо конкретным действиям, которые должны авторизовать запрос.

Answer 3

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

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

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

Answer 4

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