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

栏目: PHP · 发布时间: 7年前

内容简介: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

以上所述就是小编给大家介绍的《Yii2的场景(scenario)和验证规则(rule)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

重新定义公司

重新定义公司

[美]埃里克·施密特 / 靳婷婷、陈序、何晔 / 中信出版社 / 2015-8 / 49.00

谷歌高管手绘风漫画视频: http://v.youku.com/v_show/id_XMTMxMzQ3NjMyMA==.html?from=y1.7-1.2 Google掌门人第一本国内引进作品 首次公开谷歌内部的管理与运营方法 全面解密执掌谷歌10余年的内幕故事 谷歌 创始人拉里•佩奇作序推荐 今日的谷歌是全球最具标志性的企业,在各个领域都有创新突破,并向技术......一起来看看 《重新定义公司》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具