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

Question

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

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

• Текущий пользователь извлекается из метода current_user в слое Controller.
• Бросить исключение, если current_user.has_permission? :edit_page равно false
• editor_id установлен на current_user.id
• Изменение заносится в отдельную таблицу

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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