Yii2的場景(scenario)和驗證規則(rule)

和使用者有互動的系統必不可少的功能包括收集使用者資料、校驗和處理。實際業務中,往往還需要將資料進行持久化儲存。出於安全考慮,開發人員應當牢牢把握“客戶端的輸入都是不可信”的準則,客戶端傳過來的資料先進行過濾和清洗後再儲存或傳遞到內部系統。

Yii2推薦使用Model類來收集和校驗使用者資料,持久化的ActiveRecord類是其子類。Model類的load和validate兩個方法,分別用來收集和校驗客戶端資料。哪些資料應該被收集,哪些資料需要在什么場景下驗證,便是本文的主題:場景(scenario)和驗證規則(rule)。

系統結構

先引入一個簡單的業務系統:系統中存在學生和教師兩種角色,資料庫中使用了三張表儲存角色資訊:

user: [id, username, password, status, 其他通用屬性]

student: [id, user_id, student_no, grade, class, 其他學生屬性]

teacher: [id, user_id, work_no, title, telphone, 其他教師屬性]

實際業務不限於對這三張表的增刪查改操作。為了簡化問題,後續僅討論user和student兩張表的資料變更(給出teacher表是為了讓讀者不認為設計資料庫的人是腦殘:明明可以放到一張表的,為什么要拆開!)。

學生報名

學生報名是典型的增刪查改操作,送分題。學生報名的簡要程式碼示例如下:

public function actionSignup()
{
    $data = Yii::$app->request->post();
    $user = new User();
    $user->load($data);
    if ($user->save()) {
        $student = new Student([
            "user_id" => $user->id,
        ]);
        $student->load($data);
        if ($student->save()) {
            // redirect to success page
        } else {
            $user->delete();
        }
    }
 
    // render error page
}

相信有Yii2使用經驗的人都能根據資料庫的欄位約束快速的把User和Student類的rules方法寫出來。例如User類文件內容可能如下:

namespace app\models;
 
class User extends \yii\db\ActiveRecord
{
    public function rules()
    {
        return [
            [["username", "password", "status",], "required"],
            ["username", "unique"],
            // other rules
        ];
    }
    // other method
}

定義資料的驗證規則,這是大多數人對rules的第一印象,並且是一個很好的印象:它打回非法的資料,讓正常的資料進入系統中。安全的實踐應該儘量定義完整的規則,充分驗證資料。也建議每一個Yii2開發人員對內建的核心校驗器熟悉。

修改資訊

修改資訊,也是典型的增刪查改操作。實現程式碼和報名差別不大,這裡僅討論兩點:

  1. 使用者密碼的驗證

    註冊時會校驗使用者密碼是否8-16位,密碼的規則可能是: ["password", "string", "length" => [8, 16]] 。明文儲存密碼是不可取的,插入資料庫時至少會做MD5加密,password變成32位。假設使用者修改資訊時未修改密碼,再次儲存時密碼規則校驗出錯(長度不符合),無法儲存!

    怎么解決這個問題呢?翻閱Yii文件,發現了規則中的when屬性可以救場。一種可能的驗證規則是:

public function rules()
{
    return [
         ["password", "string", "length" => [8, 16], 'when' => function ($model) {
             return $model->isNewRecord;
         }],
         // other rules
      ];

只有在註冊(新增資料)時才校驗密碼欄位。問題解決,完美!

  1. 防止使用者私自改密碼

    假設有個小聰明的傢伙(例如湯姆),發現系統是用Yii框架做的,想搞點小破壞炫耀一下水平。在傳送修改資訊的表單時,湯姆增加&password=12345678這一段資料。系統使用$user->load($data)收集使用者輸入,更新password欄位,帶來如下後果:rules設定更新時不校驗密碼欄位,12345678直接作為password的值儲存到資料庫中。這個操作帶來連鎖反應:使用者再次登入時,加密過後的密碼與資料庫中的明文密碼不匹配,導致湯姆無法登入系統。煩人的是湯姆是個刺頭,登入不上後整天騷擾客服,不省心!

    怎么樣防止這種情況出現呢?一種解決的方法是阻止修改密碼:

unset($data["password"]); 
$user->load($data);
 
// 或者
$password = $user->password;
$user->load($data);
$user->password = $password;

把使用者輸入的密碼過濾掉,私自修改密碼的問題就解決了。

但是問題還沒有結束:湯姆可以轉向修改其他欄位,比如說性別,身份證等。更嚴重情況是修改student中user_id,就可以更改任意學生的資訊。事情十分嚴重,需要馬上修復漏洞。

可以按照密碼的方法,逐個遮蔽受保護屬性,但顯得囉嗦難看(雖然好使)。如果受保護屬性多,可以僅允許白名單進入,具體操作為:新增一個UpdateInfoForm類繼承Model,屬性是白名單屬性合計。用UpdateInfoForm類過濾使用者資料,校驗通過後再更新到user和student中:

$form = new UpdateInfoForm();
$form->load($data);
if ($form->validate()) {
    $user->load($form->attributes);
    $student->load($form->attributes);
    // next biz
}

這種方式更優雅,但仔細一想代價不小:屬性和驗證規則要重複寫一遍;user和student儲存時又重複校驗屬性。這種方式看起來優雅,實際上卻冗餘又低效。

scenario的登場,完美的解決解決上述問題。

場景(scenario)

分析上面問題,會發現關鍵點是批量賦值(massive assignment)和資料校驗(validate)兩個方法。如果對不同的場景指定賦值欄位和檢驗規則,問題就迎刃而解。

Yii中的scenario有 安全屬性活躍屬性 兩個概念。安全屬性用在批量賦值的load方法,只有安全屬性才能被賦值;活躍屬性用在規則校驗的validate方法,在活躍屬性集中並且定義了校驗規則的屬性才會被校驗。活躍屬性和安全屬性的關係是,安全屬性是活躍屬性的子集。

\yii\base\Model類定義了預設場景:SCENARIO_DEFAULT(值為default)。預設場景下,出現在rules方法中的屬性既是活躍屬性,又是安全屬性(這句話基本正確,看後續解釋)。為不同場景指定活躍屬性、安全屬性以及校驗器,可以通過覆蓋senarios或rules兩個方法實現(幾乎每個Model類都會重寫rules方法,senarios用得少)。

rules

先看rules方法。預設的屬性加校驗器定義方式,讓每個屬性既是安全屬性,也是活躍屬性。如果想讓某個屬性不是安全屬性(不能通過load批量賦值),在屬性名前加感嘆號!即可。例如student中的user_id欄位:

public function rules()
{
    return [
        ["!user_od", "required"],
        ["!user_id", "integer"],
        ["!user_od", "unique"],
        // other rules
    ];
}

user_id是活躍屬性,在寫入資料庫時會被校驗。但它不是安全屬性,不能通過load方法進行賦值,解決了安全隱患。

再看rules方法按場景區分校驗器規則的做法:定義校驗器時on屬性指定規則在哪些場景下生效,except屬性則排除一些場景(如果不指定on和except,規則對所有場景生效)。例如:

public function rules()
{
    return [
        ["password", "string", "length" => [8, 16], "on" => ["signup"]], // 僅在signup場景時才被驗證
        ["status", "integer", "except" => ["signup"],    // 除了signup場景,其他情況都校驗
        // other rules
    ];
}

在原來基礎上新增感嘆號和on/except屬性,非常簡便的就定義了非安全屬性以及分場景指定校驗規則。

scenarios

另外一種更清晰定義安全屬性和活躍屬性的做法是重寫scenarios方法。scenarios方法返回一個數組,陣列的鍵是場景名稱,值是活躍屬性集合(包飯安全屬性)。例如student表的可能實現如下:

public function scenarios()
{
    return [
        self::SCENARIO_DEFAULT => ["!user_id", "grade", "class", xxxx],
        "update" => ["grade", "class", xxxx],
    ];
}

預設情形下(學生報名),年級、班級這些資訊是安全屬性,但user_id不是,只能在程序內部賦值,並在插入資料時被校驗;在修改資訊時,user_id不是活躍屬性,既不能被批量賦值,也不需要校驗(事實上它不應該改變)。

scenarios方法只能定義活躍屬性和安全屬性,無法定義校驗規則,需要和rules配合使用。

總結

  1. 金肯定義完善的資料校驗規則
  2. 業務複雜時定義多個場景,仔細為每個場景定義安全屬性和校驗規則
  3. 優先使用rules;屬性較多、rules複雜時,可以配合scenarios方法迅速理清安全屬性和活躍屬性

參考

  1. http://www.yiiframework.com/doc-2.0/guide-input-validation.html

關鍵詞:Yii

相關推薦:

How to Implement Multiple User Types with Django

yii驗證系統學習記錄,基於yiicms(一)寫的太長了,再寫一篇(二)

如何寫程式碼 —— 程式設計內功心法【轉載】

rsync(六)命令中文手冊

ajax(同源與跨域)

面向物件高階程式設計(5)-使用元類

SpringMVC學習記錄(六)--Validator驗證

如何寫程式碼 —— 程式設計內功心法

Yii custom validation rule not called validate ()

struts2(四)之輸入校驗