Offizieller Leitfaden zum Yii Framework, Serie 17 – Verwenden von Formularen: Erstellen von Modellen-PHP-Tutorial-php.cn

Bevor wir den für das Formular erforderlichen HTML-Code schreiben, sollten wir zunächst bestimmen, welche Art von Daten aus der Endbenutzereingabe stammen und was die Daten sein sollen sich an solche Regeln halten. Zur Aufzeichnung dieser Informationen können Modellklassen verwendet werden. Wie im Kapitel „Modelle“ definiert, ist ein Modell der zentrale Ort zum Speichern von Benutzereingaben und zum Validieren dieser Eingaben.

Je nachdem, wie die vom Benutzer eingegebenen Daten verwendet werden, können wir zwei Arten von Modellen erstellen. Wenn Benutzereingaben gesammelt, verwendet und dann verworfen werden, sollten wir ein Formularmodell erstellen. Wenn Benutzereingaben gesammelt und dann in einer Datenbank gespeichert werden, sollten wir einen aktiven Datensatz verwenden. Beide Modelltypen nutzen dieselbe Basisklasse CModel , die die für das Formular erforderliche gemeinsame Schnittstelle definiert.

Hinweis: In den Beispielen in diesem Abschnitt verwenden wir hauptsächlich das Formularmodell. Der gleiche Vorgang kann jedoch auch auf Active Record-Modelle angewendet werden.

1. Definieren Sie die Modellklasse

Nachfolgend erstellen wir eine LoginForm Modellklasse zum Sammeln von Benutzereingaben auf einer Anmeldeseite. Da die Anmeldeinformationen nur zur Authentifizierung des Benutzers dienen und nicht gespeichert werden müssen, erstellen wir LoginForm als Formularmodell.

class LoginForm extends CFormModel
{
    public $username;
    public $password;
    public $rememberMe=false;
}

Nach dem Login kopieren

LoginForm definiert drei Attribute: $username, $password und $rememberMe. Sie dienen dazu, den vom Benutzer eingegebenen Benutzernamen und das Passwort zu speichern und bieten auch die Möglichkeit, dass der Benutzer sich sein Login merken möchte. Da $rememberMe den Standardwert false hat, ist die entsprechende Option bei der ersten Anzeige im Anmeldeformular deaktiviert.

Informationen: Wir nennen diese Mitgliedsvariablen Attribute anstelle von Eigenschaften, um sie von gewöhnlichen Eigenschaften zu unterscheiden. Ein Attribut ist eine Eigenschaft, die hauptsächlich zum Speichern von Daten aus Benutzereingaben oder Datenbanken verwendet wird.

2. Validierungsregeln deklarieren

Sobald der Benutzer seine Eingabe übermittelt und das Modell ausgefüllt ist, müssen wir vor der Verwendung sicherstellen, dass die Eingabe des Benutzers gültig ist. Dies wird durch die Validierung der Benutzereingaben anhand einer Reihe von Regeln erreicht. Wir geben diese Validierungsregeln in der Methode rules() an, die ein Array von Regelkonfigurationen zurückgeben soll.

class LoginForm extends CFormModel
{
    public $username;
    public $password;
    public $rememberMe=false;

    private $_identity;

    public function rules()
    {
        return array(
            array('username, password', 'required'),
            array('rememberMe', 'boolean'),
            array('password', 'authenticate'),
        );
    }

    public function authenticate($attribute,$params)
    {
        $this->_identity=new UserIdentity($this->username,$this->password);
        if(!$this->_identity->authenticate())
            $this->addError('password','错误的用户名或密码。');
    }
}

Nach dem Login kopieren

Der obige Code gibt an: username und password sind erforderlich, password sollte To authentifiziert werden soll, sollte rememberMe ein boolescher Wert sein.

rules() Jede zurückgegebene Regel muss das folgende Format haben:

array('AttributeList', 'Validator', 'on'=>'ScenarioList', ...附加选项)

Nach dem Login kopieren

wobei AttributeList（特性列表） ist eine Liste von Features, die durch diese Regel überprüft werden müssen. Validator（验证器） gibt die Art der durchzuführenden Überprüfung an sollte auf eine Liste von Szenarios angewendet werden; zusätzliche Optionen sind ein Array von Name-Wert-Paaren, die zum Initialisieren der Eigenschaftswerte des entsprechenden Validators verwendet werden. on

Es gibt drei Möglichkeiten,

in Validierungsregeln anzugeben. Validator

Erstens kann

der Name einer Methode in der Modellklasse Validator sein, genau wie im obigen Beispiel. Die Verifizierungsmethode muss die folgende Struktur haben: authenticate

/**
 * @param string 所要验证的特性的名字
 * @param array 验证规则中指定的选项
 */
public function ValidatorName($attribute,$params) { ... }

Nach dem Login kopieren

Zweitens kann

sein a Der Name der Validator-Klasse Validator Wenn diese Regel angewendet wird, wird eine Instanz der Validator-Klasse erstellt, um die eigentliche Validierung durchzuführen. Zusätzliche Optionen in den Regeln werden verwendet, um die Attributwerte der Instanz zu initialisieren. Validator-Klassen müssen von CValidator erben.

Drittens kann

ein Alias einer vordefinierten Validatorklasse Validator sein. Im obigen Beispiel ist der Name ein Alias für CRequiredValidator, der verwendet wird, um sicherzustellen, dass der zu validierende Eigenschaftswert nicht leer ist. Hier ist die vollständige Liste der vordefinierten Validator-Aliase: required

: Alias für CBooleanValidator , um sicherzustellen, dass das Attribut einen CBooleanValidator::trueValue- oder CBooleanValidator::falseValue-Wert hat. boolean
: Alias für CCaptchaValidator, der sicherstellt, dass der Attributwert dem im CAPTCHA angezeigten Bestätigungscode entspricht. captcha
: Alias für CCompareValidator, der sicherstellt, dass eine Eigenschaft einer anderen Eigenschaft oder Konstante entspricht. compare
: Alias für CEmailValidator, der sicherstellt, dass das Attribut eine gültige E-Mail-Adresse ist. email
: Alias von CDefaultValueValidator, der den Standardwert des Attributs angibt. default
exist: CExistValidator 的别名，确保特性值可以在指定表的列中可以找到。
file: CFileValidator 的别名，确保特性含有一个上传文件的名字。
filter: CFilterValidator 的别名，通过一个过滤器改变此特性。
in: CRangeValidator 的别名，确保数据在一个预先指定的值的范围之内。
length: CStringValidator 的别名，确保数据的长度在一个指定的范围之内。
match: CRegularExpressionValidator 的别名，确保数据可以匹配一个正则表达式。
numerical: CNumberValidator 的别名，确保数据是一个有效的数字。
required: CRequiredValidator 的别名，确保特性不为空。
type: CTypeValidator 的别名，确保特性是指定的数据类型。
unique: CUniqueValidator 的别名，确保数据在数据表的列中是唯一的。
url: CUrlValidator 的别名，确保数据是一个有效的 URL。

下面我们列出了几个只用这些预定义验证器的示例：

// 用户名为必填项
array('username', 'required'),
// 用户名必须在 3 到 12 个字符之间
array('username', 'length', 'min'=>3, 'max'=>12),
// 在注册场景中，密码password必须和password2一致。
array('password', 'compare', 'compareAttribute'=>'password2', 'on'=>'register'),
// 在登录场景中，密码必须接受验证。
array('password', 'authenticate', 'on'=>'login'),

Nach dem Login kopieren

3. 安全的特性赋值

在一个类的实例被创建后，我们通常需要用最终用户提交的数据填充它的特性。这可以通过如下块赋值（massive assignment）方式轻松实现：

$model=new LoginForm;
if(isset($_POST['LoginForm']))
    $model->attributes=$_POST['LoginForm'];

Nach dem Login kopieren

最后的表达式被称作 块赋值（massive assignment），它将 $_POST['LoginForm'] 中的每一项复制到相应的模型特性中。这相当于如下赋值方法：

foreach($_POST['LoginForm'] as $name=>$value)
{
    if($name 是一个安全的特性)
        $model->$name=$value;
}

Nach dem Login kopieren

检测特性的安全非常重要，例如，如果我们以为一个表的主键是安全的而暴露了它，那么攻击者可能就获得了一个修改记录的主键的机会，从而篡改未授权给他的内容。

检测特性安全的策略在版本 1.0 和 1.1 中是不同的，下面我们将分别讲解：

1.1 中的安全特性

在版本 1.1 中，特性如果出现在相应场景的一个验证规则中，即被认为是安全的。例如：

array('username, password', 'required', 'on'=>'login, register'),
array('email', 'required', 'on'=>'register'),

Nach dem Login kopieren

如上所示， username 和 password 特性在 login 场景中是必填项。而 username, password 和 email 特性在register 场景中是必填项。于是，如果我们在 login 场景中执行块赋值，就只有 username 和 password 会被块赋值。因为只有它们出现在 login 的验证规则中。另一方面，如果场景是 register ，这三个特性就都可以被块赋值。

// 在登录场景中
$model=new User('login');
if(isset($_POST['User']))
    $model->attributes=$_POST['User'];

// 在注册场景中
$model=new User('register');
if(isset($_POST['User']))
    $model->attributes=$_POST['User'];

Nach dem Login kopieren

那么为什么我们使用这样一种策略来检测特性是否安全呢？背后的基本原理就是：如果一个特性已经有了一个或多个可检测有效性的验证规则，那我们还担心什么呢？

请记住，验证规则是用于检查用户输入的数据，而不是检查我们在代码中生成的数据（例如时间戳，自动产生的主键）。因此，不要为那些不接受最终用户输入的特性添加验证规则。

有时候，我们想声明一个特性是安全的，即使我们没有为它指定任何规则。例如，一篇文章的内容可以接受用户的任何输入。我们可以使用特殊的 safe 规则实现此目的：

array('content', 'safe')

Nach dem Login kopieren

为了完成起见，还有一个用于声明一个属性为不安全的 unsafe 规则：

array('permission', 'unsafe')

Nach dem Login kopieren

unsafe 规则并不常用，它是我们之前定义的安全特性的一个例外。

1.0 中的安全特性

在版本1.0中,决定一个数据项是否是安全的,基于一个名为 safeAttributes 方法的返回值和数据项被指定的场景. 默认的,这个方法返回所有公共成员变量作为 CFormModel 的安全特性,而它也返回了除了主键外, 表中所有字段名作为 CActiveRecord的安全特性.我们可以根据场景重写这个方法来限制安全特性 .例如, 一个用户模型可以包含很多特性,但是在 login 场景.里,我们只能使用 username 和 password 特性.我们可以按照如下来指定这一限制 :

public function safeAttributes()
{
    return array(
        parent::safeAttributes(),
        'login' => 'username, password',
    );
}

Nach dem Login kopieren

safeAttributes 方法更准确的返回值应该是如下结构的 :

array(
   // these attributes can be massively assigned in any scenario
   // that is not explicitly specified below
   'attr1, attr2, ...',
     *
   // these attributes can be massively assigned only in scenario 1
   'scenario1' => 'attr2, attr3, ...',
     *
   // these attributes can be massively assigned only in scenario 2
   'scenario2' => 'attr1, attr3, ...',
)

Nach dem Login kopieren

如果模型不是场景敏感的(比如,它只在一个场景中使用,或者所有场景共享了一套同样的安全特性),返回值可以是如下那样简单的字符串.

'attr1, attr2, ...'

Nach dem Login kopieren

而那些不安全的数据项,我们需要使用独立的赋值语句来分配它们到相应的特性.如下所示:

$model->permission='admin';
$model->id=1;

Nach dem Login kopieren

4. 触发验证

一旦模型被用户提交的数据填充，我们就可以调用 CModel::validate() 出发数据验证进程。此方法返回一个指示验证是否成功的值。对 CActiveRecord 模型来说，验证也可以在我们调用其 CActiveRecord::save() 方法时自动触发。

我们可以使用 scenario 设置场景属性，这样，相应场景的验证规则就会被应用。

验证是基于场景执行的。 scenario 属性指定了模型当前用于的场景和当前使用的验证规则集。例如，在 login场景中，我们只想验证用户模型中的 username 和 password 输入；而在 register 场景中，我们需要验证更多的输入，例如 email, address, 等。下面的例子演示了如何在 register 场景中执行验证：

// 在注册场景中创建一个  User 模型。等价于：
// $model=new User;
// $model->scenario='register';
$model=new User('register');

// 将输入的值填充到模型
$model->attributes=$_POST['User'];

// 执行验证
if($model->validate())   // if the inputs are valid
    ...
else
    ...

Nach dem Login kopieren

规则关联的场景可以通过规则中的 on 选项指定。如果 on 选项未设置，则此规则会应用于所有场景。例如：

public function rules()
{
    return array(
        array('username, password', 'required'),
        array('password_repeat', 'required', 'on'=>'register'),
        array('password', 'compare', 'on'=>'register'),
    );
}

Nach dem Login kopieren

第一个规则将应用于所有场景，而第二个将只会应用于 register 场景。