Логика приложения против авторизации

Question

Я использую в Rails cancan gem, но это, вероятно, более общий.

Краткое введение. В cancan, можно определить разрешение, как это:

can :read, Post 
can :manage, Post if user.is_admin? 
can :manage, Post do |post| post.author == user end 

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

Теперь я хотел бы изменить свою логику приложения, чтобы вы не могли удалить сообщение, если у него есть какие-либо комментарии (если вы не являетесь администратором). Это по-прежнему легко с cancan (добавлено в конце предыдущего фрагмента кода):

cannot :destroy, Post do |post| post.comments.count > 0 && !user.is_admin? end 

А это значит, что я могу использовать следующий псевдокод в представлении (шаблон HTML):

<h1><%=post.title%></h1> 
<p><%=post.text%></p> 
<%=link_to 'Edit', edit_post_path(post) if can? :edit, post%> 
<%=link_to 'Delete', delete_post_path(post) if can? :destroy, post%> 

Мой вопрос только в том разумно ли смешивать разрешения с логикой приложения? Он чувствует себя вид грязный, но с другой стороны, я должен был бы сломать DRY и заменить это двойной проверки везде в приложении (внешний интерфейс, API и т.д.)

<h1><%=post.title%></h1> 
<p><%=post.text%></p> 
<%=link_to 'Edit', edit_post_path(post) if post.can_be_edited? && can? :edit, post%> 
<%=link_to 'Delete', delete_post_path(post) if post.can_be_destroyed? && can? :destroy, post %> 

Answer 1

Я не вижу никаких проблем с поместив чеки на поведение, связанное с авторизацией, в том месте, которое вы предложили. Как вы уже упоминали, альтернатива хуже. Кроме того, это означает, что кто-то может легко посмотреть в одном месте, чтобы увидеть схему авторизации для Post, что очень желательно. Альтернативу (наличие проверок в нескольких местах) гораздо сложнее поддерживать и обосновывать, не говоря уже о том, что изменения должны быть отредактированы в нескольких местах, и это всего лишь «согласие джентльмена» разработчика, редактирующего их все одновременно, что их удерживает в синхронизации.

Answer 2

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

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

Посмотрите на XACML reference architecture для официального архитектурного обзора.