Чи використання умов безпеки з огляду на порушення MVC?


10

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


Яка була б альтернатива?

1
Ви використовуєте те, що забезпечує найкращу безпеку, навіть якщо це вважається анти-зразком .
zxcdw

Відповіді:


6

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

Зазвичай у вас повинно бути обидва, оскільки погляд повинен змінюватися для різних рівнів / ролей. Контролер надсилає відповідні дані, які змінили б подання, але перегляд все ще повинен щось робити з цими даними, щоб приховати / відобразити вміст потрібному користувачеві.

Ось чому більшість шаблонів кадрів мають умовні елементи ( приклад руль ):

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

Тож це означає, що це не порушення, якщо відповідні шматки знаходяться в потрібному місці.


4

Так і ні.

Якщо фактичне рішення щодо безпеки приймається видом, то так, ви порушуєте MVC. Якщо, однак, вид делегує фактичне рішення моделі, тоді ви все добре. Немає нічого поганого в тому, щоб приймати рішення, які елементи показувати, виходячи з інформації моделі.

Наприклад, якщо у вас є кнопка "редагування", яка видно лише користувачам з дозволом "редактора", тоді добре переглядати модель, хто поточний користувач і чи має вони дозвіл "редактора", використовуючи цю інформацію, щоб вирішити, показувати кнопку чи ні. Якщо, однак, перегляд повинен здійснювати саму логіку аутентифікації та авторизації, ви б порушили MVC.


2

Я б сказав, що ні .

Але з іншої причини, ніж сказала @rvcoutinho (хоча він цитує вікіпедію, яка змушує мене почуватись неправильно в своєму мисленні)

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

Це дозволяє перевірити двошарову безпеку: на рівні інтерфейсу користувача, таким чином, задній зворотний зв'язок підривається як для звичайного випадку, так і для серверного рівня для поганих дійових осіб, де модель підтримує знання про безпеку всередині себе, тому контролер передає інформацію модель, яка негайно викидає його.

Двошаровий захист, як це, є стандартом у промисловості, і цей спосіб дозволяє вашій логіці безпеки існувати лише в двох місцях, тому це бонус, як тільки ви вставляєте логіку безпеки в свій контролер, ви ставите її туди і в Користувальницький інтерфейс та модель (модель потрібна, оскільки це остання лінія захисту і особливо важлива для будь-якого використання поза цим веб-додатком MVC, як настільний клієнт або будь-який інструмент управління сервером)


Твердження Вікіпедії про те, що "Контролер може надсилати команди до пов'язаного з ним перегляду, щоб змінити уявлення про модель у представленні", здається, більше підходить для Model-View-Presenter , оскільки інтерактивна модель, яку, як видається, описана фраза, можлива там, тоді як у MVC один раз Перегляд надається, ніяких подальших дій між Поглядом та Контролером не відбувається.
Роберт Харві

1
@RobertHarvey Я погодився б, що твердження не вписується в моє визначення MVC, але пощастило нам, що ми працюємо в галузі, де правильність визначається множиною угод, а не будь-якою доказовістю, тому що ці визначення просто пливуть так, ніби з ефіру постійно розвивається фундамент, який дозволяє кожному робити власні заходи. Або простішими словами, я, мабуть, так само помиляюся, як і всі інші тут.
Джиммі Хоффа

3
Саме тому я думаю, що люди все-таки занадто педантичні щодо такого роду.
Роберт Харві

1
@rvcoutinho Я б не сказав, що я взагалі був буквальним; у вас є посилання на вашу сторону, все, що я маю, - це моя думка, тому, на мій погляд, це означає, що я, ймовірно, помиляюся, саме тому я це згадав. Я вважаю, що моя думка є достатньо правдоподібною, щоб її варто було поділитися, хоча я не маю жодних посилань, тому я це все одно зробив, незалежно від того, що, як я вже сказав, я, ймовірно, помиляюся.
Джиммі Хоффа

1
@rvcoutinho: Насправді я мав на увазі питання ОП. :) З правилами немає нічого поганого, якщо тільки правила не заважають щось робити.
Роберт Харві

2

Я б сказав, що ні .

Зазвичай такий вид перевірок безпеки здійснює контролер.

Як з Вікіпедії :

Контролер може надсилати команди до пов'язаного з ним перегляду, щоб змінити подання моделі в поданні

І я не думаю, що це слід робити безпосередньо в погляді. Наприклад, якщо це робиться через javascript, це може бути проблемою безпеки (можна відключити javascript і отримати доступ до прихованих даних).

Знову з Вікіпедії :

Перегляд вимагає від моделі інформації, необхідної для створення вихідного представлення .


1
У багатьох програмних системах відображення елемента залежить від рівня безпеки користувача. Хоча ви можете заборонити відображення елемента даних, встановивши його в нульовому або нульовому значенні в Моделі перегляду, ім’я або опис елемента даних все одно відображатиметься. Єдине місце, де можна перешкодити відображенню опису елемента даних (практичним способом) - це Перегляд.
Роберт Харві

Я схильний не погоджуватися. Я б сказав, що перегляд вимагає даних, контролер маніпулює моделлю, а перегляд знову представляє їх. Погляд повинен відповідати лише за представлення результату.
rvcoutinho

Ось чому Перегляд повинен приховувати ті візуальні елементи, які користувачеві не потрібно бачити. Контролер не несе відповідальності за створення візуального подання даних; Погляд є. Звичайно, якщо те, що ви показуєте, настільки чутливе, що навіть не може бути у Перегляді / Джерелі, то те, що потрібно зробити контролеру, - це повернути інший вигляд.
Роберт Харві

1
Це моя думка. Погляд повинен бути різним. Наскільки я розумію, виглядає, що погляд повинен дбати лише про представлення даних. Під уявленням я мав би на увазі, як щось показати, а не коли це показати. І все ж ваші коментарі цілком актуальні.
rvcoutinho

Ну, я думаю, ми можемо просто використовувати один і той же вираз для двох різних речей. Який інакший погляд? Але я думаю, що ми погоджуємося з найважливішим питанням: якщо воно є чутливим до безпеки, його не слід розглядати з точки зору.
rvcoutinho

1

У цьому питанні бере участь кілька питань.

  1. Аутентифікація (чи є це користувач, який, за його словами, є) не повинна турбувати представлення.
  2. Авторизація (Є чи поточний користувач право робити це ) є предметом заклопотаності View, тому що це може вплинути на те , що отримує представляються користувачеві. Таким чином, код для відображення кнопки редагування може бути оточений умовним чином if model.userCanEdit() ... endif.
  3. Визначення того, які атрибути авторизації має користувач, тобто ділова логіка, і їх слід розміщувати в Моделі. (Наприклад, що привілей "редагувати" вимагає, щоб ви мали 2000 репутацію; або ви повинні бути автором або модератором)

0

Якщо мова йде лише про показ елемента інтерфейсу, я думаю, що це нормально (як би ви це зробили в будь-якому випадку?). Якщо в цих елементах будуть якісь дані, модель повинна переконатися, що контейнери порожні. І звичайно, код для отримання даних дозволу повинен був оброблятися перед переглядом, тому тут немає активного доступу до моделі.


0

Якщо представлення явно перевіряє безпеку для умовного відображення елементів інтерфейсу, чи порушує MVC вміст бізнес-логіки?

Так, це порушення MVC.

Вид існує лише для відображення елементів, і логіка повинна бути в моделі. Маючи вигляд зробити щось (у вашому випадку перевірити безпеку), ви розміщуєте логіку там.


Тоді як перегляд знає, чи потрібно відображати щось на зразок кнопки редагування?
Matt S

@MattS Ведучий викликає функцію у вікні подання або приховування цієї кнопки (залежно від стану в моделі).
BЈоviћ
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.