ZF-4352: Zend_Validate_Alpha / Zend_Validate_Alnum CAST to string

Issue Type: Bug Created: 2008-09-22T12:26:20.000+0000 Last Updated: 2009-06-08T13:44:47.000+0000 Status: Resolved Fix version(s): - 1.9.0 (31/Jul/09)

Reporter: Christopher Vogt (cvogt) Assignee: Thomas Weidner (thomas) Tags: - Zend_Filter

  • Zend_Validate

Related issues: Attachments:


$v = new Zend_Validate_Alpha();

echo $v->isValid( array('%&$!!') ) ? 'valid' : 'invalid';

expected result:


actual result:


The reason is, that _Alpha and _Alnum cast the validation target to string in the line $valueString = (string) $value;. I think a validator should never cast the value it validates without examining the type. It should rather check if the value has an expected type. So the line $valueString = (string) $value; should be replaced by something like if( is_int($value) ){ $valueString = (string) $value; } elseif( is_string($value) ) { $valueString = $value; } else { return false; }


Posted by old of Satoru Yoshida ( on 2008-10-07T00:28:49.000+0000

I think fear of inconsistency between these modules and another Zend_Validate_* (and Zend_Filter_*) modules if we carry out as this report.

For example , Zend_Validate_Digits also returns 'invalid' against array.

Posted by old of Satoru Yoshida ( on 2008-10-07T00:32:12.000+0000

Sorry, I mistook to write.

Correct : Zend_Validate_Digits also returns 'valid' against array.

Posted by Christopher Vogt (cvogt) on 2008-10-08T05:06:24.000+0000

The current Zend_Validate_Alpha / Zend_Validate_Alnum behavior is clearly broken in my eyes. People use these classes to validate their input and they expect that Alpha or Alnum strings to be valid. Arrays are neither neither strings, nor does Alpha or Alnum make sense for them.

If you fear inconsistency this means the bug could be in other Classes as well. However this does not mean that not fixing it makes the situation any better. It should be fixed in every broken class then. Besides, I cannot replicate Zend_Validate_Digits validating an array as valid.

Fixing this bug does not break backwards compatibility in my eyes. I don't see any reason for not fixing it and I strongly oppose against "Won't Fix".

Posted by old of Satoru Yoshida ( on 2008-10-08T23:00:32.000+0000

Hi, Christopher. I reopen this issue for you.

I will be happy if more useful idea will come on there.

Posted by Christopher Vogt (cvogt) on 2008-10-09T03:40:16.000+0000

Thanks :).

I would take a white-listing approach for types and return false for all types not white-listed. The question is what should be on the white-list.

string: yes object: rather yes, maybe only if it implements __toString ? integer: yes, but only for Alnum boolean: maybe yes for backwards-compatibility? NULL: maybe yes for backwards-compatibility? float: maybe yes for Alnum for backwards-compatibility? (because: (string) 1.0 === "1") array: no resource: no

The implementation could be like the following at the beginning of the isValid method:

if( !is_string($value) && !is_int($value) && !etc. ){ return false; }

Posted by Nils Bujny (budcha) on 2009-04-04T10:26:55.000+0000

Hi, stumbled today into this "bug".

Used Zend_Validate not for user input from Forms etc, but for field validation before its saved in the Storage Engine. My UnitTest failed, where i expected failure from the Zend_Alnum class, because the validation was successful. "The Coder" can (shouldnt, but ...) write something like this: $wrongData = array(); $role = new Role(); $role->setName($wrongData);

Through the (string) cast the empty Array becomes "Array", even the empty string check is in this case useless ...

My Solution, for compatibility would be to make a static flag if my projects wants to use STRICT validation. (disable cast if STRICT). (And this for all Zend_Validate_* Classes), Or put this flag in the Zend_Validate constructor.

$valueString = Zend_Validate::STRICT ? $value : (string) $value;

or $valueString = $this->validateStrict ? $value : (string) $value;

something like this. my best regards.

Posted by Thomas Weidner (thomas) on 2009-06-08T13:44:47.000+0000

Fixed with r15951. Please test this fix hard to prevent possible problems for the next release.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.