月下博客

Yii2的场景(scenario)和验证规则(rule)

转载请注明来源:https://ssrvps.org/archives/4068

和用户有交互的系统必不可少的功能包括收集用户数据、校验和处理。实际业务中,往往还需要将数据进行持久化存储。出于安全考虑,开发人员应当牢牢把握“客户端的输入都是不可信”的准则,客户端传过来的数据先进行过滤和清洗后再存储或传递到内部系统。

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
  2. http://www.yiiframework.com/doc-2.0/guide-structure-models.html
  3. http://www.yiiframework.com/doc-2.0/guide-db-active-record.html