Смешивание логики безопасности с моделями в Ruby on Rails?

Question

Неплохой дизайн для смешивания кода, который касается логики безопасности в модели?

Пример для редактирования страницы в before_save обратного вызова

• Текущий пользователь схваченного от метода current_user в слое контроллера.
• Throw исключение, если current_user.has_permission? :edit_page ложно
• editor_id установлен в current_user.id
• Изменение вошедшего в отдельной таблице

Модель не только проверка безопасности в приложении. Пользовательский интерфейс проверяет разрешение перед просмотром редактирования экрана. Модель выступает в качестве препятствия для любых ошибок на уровне View/Controller.

Примечание: Единственное нарушение между уровнями модели и контроллера - это метод current_user. Приложение, над которым я работаю, никогда не позволит анонимным пользователям.

Answer 1

Я не думаю, что это плохой дизайн, чтобы поставить логику безопасности в модель. Вы размещаете там бизнес-логику, и вы, возможно, можете рассматривать логику безопасности как своего рода бизнес-логику. Вы, конечно, не хотите все это в контроллере или в представлении, вы хотите следовать подходу skinny controller, fat model.

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

Answer 2

Я бы сказал, что это зависит от того, предназначены ли ваши модели для непосредственного доступа. Если да, то обязательно должно быть осознание проблем безопасности, возможно, через mixin, поскольку такие проблемы, вероятно, будут несколько ортогональны основным проблемам модели.

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

Answer 3

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

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

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