Issues

ZF-4352: Zend_Validate_Alpha / Zend_Validate_Alnum CAST to string

Description

{{$v = new Zend_Validate_Alpha();

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

expected result:

invalid

actual result:

valid

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; } }}

Comments

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.

Sorry, I mistook to write.

Correct : Zend_Validate_Digits also returns 'valid' against array.

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".

Hi, Christopher. I reopen this issue for you.

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

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; }

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.

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