Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Auth Form Adapter post-query validation inoperable when using mis-matched form and db-field names #439

toomuchpete opened this Issue · 2 comments

2 participants


When field names in a form match those in a database, and a validator is present, the Form adapter correctly removes the fields that will be validated post-query from the query string.

When field names in the database do not match the form fields, and they are specified per the docs like this:

    'customer' => array(
        'adapter' => 'Form',
        'model' => 'Customers',
        'fields' => array('username' => 'login.username', 'password' => 'login.password'),
        'scope' => array('active' => true)

Validation rules placed on the 'username' or 'password' fields will not cause the 'login.username' or 'login.password' fields to be removed from the query, which means you cannot use post-query validation (like Password::check()) on either of those fields.

It is clearly intended for post-query validation to work with mismatched field names, as the docs even reference this scenario: "each validator can be defined as any PHP callable, and must be keyed using the name of the form field submitted (if form and database field names do not match)." But it doesn't mention that in that case, the field will not be removed from the query.

Fix for this issue would need to go into the Form adapter around like 330, and would need to take into account the names of the fields to remove from the query rather than just using a one-liner array_diff.


Replacing line 329 in the Auth Form adapter with the following code resolves this issue:

        $additionalFieldsToRemove = array();
        foreach (array_keys($this->_validators) as $v) {
            if (isset($this->_fields[$v])) {
                $additionalFieldsToRemove[$this->_fields[$v]] = true;
        $conditions = $this->_scope + array_diff_key($data, ($this->_validators + $additionalFieldsToRemove));

But note in some strange situations where form field 'FieldA' matches up with database field 'FieldB' and vice versa, the wrong conditions may be passed. A more robust solution is probably called for.


Nice. Thanks @rmarscher for the patch/test and @toomuchpete for the report.

@nateabele nateabele closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.