Правило валідації - safe, для тих, хто в танку

вступ

Вкраце. Правила валідації служить двом цілям:
  1. Переконатися, що дані передані через форму, введені коректно.
  2. Визначити, які поля можуть бути призначені змінної $ model.
Вони пов'язані, але вона не є одним і тим же.

Погляньмо на набір правил перевірки

Перед тим, як почати роботу, ми продемонструємо Вам типові правила перевірки даних моделі. Наш приклад взятий з блогу Tutorial. Модель «User» знаходиться в protected / models / User.php.

Правила перевірки визначаються з масиву array (.). Містить список атрибутів, ім'я валідатора, а також додаткові параметри, необхідні різним валідатори. Також може містити ключове слово «on», яке вказує сценарій валідації, але ми не будемо описувати це в статті.

Правила валідації

Головна мета для валідаторів переконатися, що користувачі передають у формі правильні дані.

Якщо поле має бути не більше 16 символів, якщо значення повинно бути унікальним, або якщо значення повинно бути правильним email, Yii надає багатий набір валідаторів, для перевірки даних користувача.

Крім того, можна створювати власні валідатори, або як клас функцій, або автономним розширенням. Але це виходить за рамки даної статті.

масове присвоювання

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

Це код дії update контролеа post (? R = post / update):

$ Model-> attributes = $ _POST [ 'Post'] оманливе проста конструкція, неправдалі?
Насправді викликається метод

Так як $ _POST [ 'Post'] насправді масив, що представляє всі поля відразу, Yii проходить всі поля по одному. Кожне поле присвоюється відповідному атрибуту в моделі (після перевірки, звичайно), яка може бути збережена або оновлених або будь-який інший.

Масове присвоювання насправді виглядає так:

Масове присвоювання дуже важливо - ваше Yii програма не буде працювати без нього.

Чому масове присвоювання іноді не працює?

As «obvious» as Massive Assignment is, it's remarkably common for users to find that their $ model variables fail to -> save () due to missing field values. Either the validation is failing outright, or field values ​​are not copied from the form to the $ model.
До сожиленію не зміг перевести цю фразу.

Ключовий момент - масове присвоювання буде здійснюватися тільки для полів, у яких є явні правила перевірки. Явні правила - length, email, required і т.д. - всі стандартні. Але деякі поля вільної форми не обов'язкові і не мають ніякого формату вимог - користувач може передати в ньому що завгодно, в тому числі залишити це поле порожнім.

Деякі поля не потрібно перевіряти, правильно?

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

Атрибути, які не з'являються в будь-якому правилі перевірки не копіюються в модель при масовому присвоєння.
Якщо атрибут не має певного валідатора даних, ми повинні сказати Yii ми хочемо вирішити атрибуту заповнюватися під час масових присвоєнь. Це робиться за допомогою валідатора «safe».

Так у чому ж справа?

Чому це правило «safe» необхідно вмес атрибутам? Це дуже поширений питання.

Зрештою, якщо розробник налаштовує форми з певним полях, вони не повинні бути просто скопійована в $ model після перевірки? Чому це не достатньо добре?

Тому що Yii захищає вас від сюрпризів безпеки.

Хоча це може здатися очевидним, але Yii не має можливості дізнатися, що дані були послані з форми, а не є даними від поганий хлопець, який синтезував результати, щоб обдурити додаток.

Це захист від двох сценаріїв:
  1. Деякі моделі мають атрибути, які є дозволеними, але не в конкретній формі. Наприклад, форма «зміна вашого пароля», повинні бути заповнені поля «пароль» і «підтвердіть пароль». Але за сценарієм ChangePassword, атрибут isAdmin повинен бути відзначені «unsafe» (небезпечним для масового присвоєння).
  2. Всі моделі об'єктів на основі CActiveRecord мають внутрішні атрибути (властивості), які можуть бути скомпрометовані, якщо поганий хлопець міг масово присвоювати будь-які атрибути. Приклади таких свойотв:
    • $ Model-> isnewrecord
    • $ Model-> dbcriteria
    • $ Model-> primarykey
    • $ Model-> tablealias
    • $ Model-> scenario
Є ще й інші властивості, все їх ми перераховувати тут не будемо. Це досить страшно подумати, що може трапитися, якщо поганий хлопець міг би керувати цими властивостями. Але він не може тому, що вони не згадується ні в одному правилі перевірки - «safe» - вони захищені.

Yii має консервативний підхід. Атрибути вважаються небезпечними, якщо розробник явно не вказує їх безпечними (парадигма «заборони за замовчуванням»).

Бажано переглянути правила валідації моделей час від часу, щоб переконатися, що ви не дозволяєте змінювати атрибути, до яких користувач не повинен мати доступ (особливо при сценаріях), тому що найчастіше в моделі все поля відмічені як «safe».

від перекладача

Від себе додам з приводу останнього абзацу. Що б запобігти масовому присвоювання значень через модель, можна створювати моделі форм, з чітко визначеними полями, які можуть бути послані через форму. І вже в моделі форми поізводіт присвоювання значень моделі acrive record і виробляти збереження.

Схожі статті