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

10

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

Мэтт С
источник
Какой будет альтернатива?
1
Вы используете то, что дает вам наилучшую защиту, даже если некоторые считают, что это антипаттерн .
zxcdw

Ответы:

6

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

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

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

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

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

knownasilya
источник
4

Да и нет.

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

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

tdammers
источник
2

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

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

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

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

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

Джимми Хоффа
источник
Утверждение Википедии о том, что «Контроллер может отправлять команды в свой связанный вид для изменения представления модели в представлении », кажется более подходящим для Model-View-Presenter , поскольку интерактивная модель, которую, как кажется, описывает эта фраза, возможна там, тогда как в MVC, когда-то представление отображается, дальнейшие действия между представлением и контроллером не выполняются.
Роберт Харви
1
@RobertHarvey Я бы согласился, что утверждение не вписывается в мое определение MVC, но, к счастью, мы работаем в отрасли, где правильность определяется множеством соглашений, а не какой-либо доказуемостью, потому что эти определения просто всплывают, как будто из эфира с постоянно развивающийся фонд, позволяющий каждому делать свои собственные блюда на дом. Или, более простыми словами, я, вероятно, так же, как и все остальные здесь.
Джимми Хоффа
3
Вот почему я думаю, что люди все равно слишком педантичны к таким вещам.
Роберт Харви
1
@ rvcoutinho Я бы так не сказал, я был буквальным; у вас есть ссылки на вашу сторону, все, что у меня есть, это мое мнение, так что в моем представлении это означает, что я, вероятно, ошибаюсь, поэтому я упомянул это. Я чувствую, что мое мнение достаточно правдоподобно, чтобы его стоило поделиться, хотя у меня нет ссылок, поэтому я все равно сделал это, несмотря на то, что, как я сказал, я, вероятно, ошибаюсь.
Джимми Хоффа
1
@rvcoutinho: На самом деле я имел в виду вопрос ОП. :) В правилах нет ничего плохого, если правила не мешают что-то сделать.
Роберт Харви
2

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

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

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

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

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

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

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

rvcoutinho
источник
1
Во многих программных системах отображение элемента зависит от уровня безопасности пользователя. Хотя вы можете запретить отображение элемента данных, установив его в ноль или ноль в модели представления, имя или описание элемента данных все равно будет отображаться. Единственное место, где вы можете запретить отображение описания элемента данных (на практике), это View.
Роберт Харви
Я склонен не соглашаться Я бы сказал, что представление будет запрашивать данные, контроллер будет манипулировать моделью, и представление снова будет представлять ее. Представление должно отвечать только за представление результатов.
rvcoutinho
Вот почему View должен скрывать те визуальные элементы, которые пользователь не должен видеть. Контроллер не несет ответственности за создание визуального представления данных; Вид есть. Конечно, если то, что вы отображаете, настолько чувствительно, что его даже не может быть в View / Source, тогда контроллер должен вернуть другое представление.
Роберт Харви
1
Это моя точка зрения. Мнение должно быть другим. Насколько я понимаю, похоже, что представление должно заботиться только о представлении данных. Под представлением я подразумеваю, как показать что-то, а не когда показать это. Все же ваши комментарии абсолютно актуальны.
rvcoutinho
Ну, я думаю, что мы могли бы просто использовать одно и то же выражение для двух разных вещей. В любом случае, что это за другой взгляд? Но я думаю, что мы согласны по самому важному вопросу: если он чувствителен к безопасности, он не должен рассматриваться точкой зрения.
rvcoutinho
1

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

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

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

Торстен Мюллер
источник
0

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

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

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

BЈовић
источник
Тогда как представление узнает, отображать или нет что-то вроде кнопки редактирования?
Мэтт S
@MattS Презентатор вызывает функцию в представлении, чтобы показать или скрыть эту кнопку (в зависимости от состояния в модели).
BЈовић