Является ли использование условий безопасности в представлении нарушением MVC?

Часто то, что отображается пользователю (например, на веб-странице), будет частично основано на проверках безопасности. Обычно я считаю, что безопасность на уровне пользователя / ACL является частью бизнес-логики системы. Если представление явно проверяет безопасность для условного отображения элементов пользовательского интерфейса, нарушает ли оно MVC, сдерживая бизнес-логику?

Может быть два типа условий безопасности: один для модели, а другой для вида. Представление управляет отображением соответствующих элементов в зависимости от разрешений текущего пользователя, но модель контролирует доступ к базовым данным. Пока модель обладает всеми необходимыми проверками / проверками, даже если представление отсутствует, безопасность все равно сохраняется.

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

Вот почему большинство шаблонных фреймворков имеют условные элементы ( пример Handlebars ):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Таким образом, это означает, что это не нарушение, если соответствующие части находятся в правильном месте.

Да и нет.

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

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

Я бы сказал нет .

Но по другой причине, чем сказал @rvcoutinho (хотя он цитирует Википедию, которая заставляет меня чувствовать себя не в своей тарелке)

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

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

Двухуровневая защита, подобная этой, является стандартом в отрасли, и этот способ позволяет вашей логике безопасности существовать только в двух местах, поэтому это является преимуществом, как только вы вставляете логику безопасности в свой контроллер, вы помещаете ее туда и в Пользовательский интерфейс и модель (модель нуждается в ней, поскольку она является последней линией защиты и особенно важна для любых применений вне этого веб-приложения MVC, таких как клиент рабочего стола или любые инструменты управления сервером)

Я бы сказал нет .

Обычно такие проверки безопасности выполняются контроллером.

Как из Википедии :

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

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

Опять же из Википедии :

Представление запрашивает у модели информацию, необходимую для создания выходного представления .

Есть несколько вопросов, связанных с этим вопросом.

1. Аутентификация (это тот пользователь, которым, по его словам, он является) не должна беспокоить View.
2. Авторизация (разрешено ли текущему пользователю делать это ) - это забота о View, потому что она может повлиять на то, что будет представлено пользователю. Таким образом, код для отображения кнопки редактирования может быть окружен условным аналогом if model.userCanEdit() ... endif.
3. Определение того, какие атрибуты авторизации имеет пользователь, то есть бизнес-логика и должно быть размещено в модели. (Например, привилегия 'edit' требует от вас 2000 репутации; или что вы должны быть автором или модератором)

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

Если представление явно проверяет безопасность для условного отображения элементов пользовательского интерфейса, нарушает ли оно MVC, сдерживая бизнес-логику?

Да, это нарушение MVC.

Представление существует только для отображения элементов, и логика должна быть в модели. Имея представление, которое делает что-то (в вашем случае, проверьте безопасность), вы размещаете логику там.