I’ve read the discussion and I really agree with Matthew first answer
(more below ) :
Matthew Weier O'Phinney-3 wrote:
Validation merely makes sure that the submitted data passes certain
rules. Filtering is for output -- to a database, to the screen,
whatever. You validate unfiltered data, and then filter it for your
output stream.
Another use for filtering is normalization -- taking input and modifying
it to fit a 'normal' specification. An example of this is taking a phone
number -- (800) 555-1212 -- and normalizing it for your database --
8885551212. You will often take a normalized value and filter it again
for display -- 800.555.1212.
Let's look at this:
If I have a filter, StripTags, and then a validator, NoTags, and run the
data through the filter prior to validating.... what's the point of the
validation then? you've already ensured that it will pass no matter
what.. but now when you return the data to the user, it looks unfamiliar
to them.
Better is to check for tags in the first place, and let the user know
they aren't allowed... or, allow them, but strip them out prior to
storing or displaying the information (to prevent XSS attacks, for
example).
Then Matthew changed it to pre-filter base on what I've been done in ZFI
For those who are interested:
The idea is to allow some normalization of data prior to sending it to
validation. The example given me was one of a username:
* Allow only 3-16 characters
and you get ' mweierophinneyzend ' as input... it would fail
validation, but likely shouldn't have. If the input were run through
StringTrim first, it would pass.
Basically, such normalization ensures that the data is *ready* for
validation.
It looks to me that only StringTrim fit the use case of pre-filtering
data. And I’m style convinced that post filtering is a better approaches. :)
--
Laurent Melmoux
Annecy, France
Amr Mostafa a écrit :
Hi Laurent,
While I don't have the answer to your question specifically, I know
that Zend_Form used to validate before filtering like you are
suggesting. But that was modified per this discussion:
http://www.nabble.com/Zend_Form_Element-validation-bug-tt15589810s16154.html
As a side note, I've done something very similar to the use case you
describe, and didn't run into this problem. The only difference I had
was that the filter converts the given date to a Zend_Date instance.
Which then runs through Zend_Validate_Date and it's has been working
fine. Think I got lucky there and I've even noticed it :)
Back to the discussion linked above, in one post I can tell that
Matthew acknowledged the important of a pre/postFilter.
Best Regards,
- Amr
On Sat, Mar 8, 2008 at 11:26 AM, Laurent Melmoux <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Matthew and every body,
First a use case:
On an i18n application the user can chose is preferred date format for
display and input.
Let's say 'dd/MM/YYYY'.
I n the backend I will need a validator to validate the date
format and
a filter to convert the date to a Mysql format 'YYYY-MM-dd'.
But here the validation against 'dd/MM/YYYY' won't work because
the date
will be filtered before validation. Well, an easy work around will
be to
validate against the 'YYYY-MM-dd' format but it sound not very
clean and
I could not use an error message saying the right format to use.
So I'm wondering if data should be filtered prior to validation. Is
there some security concern?
While I see some advantage to filter data, like removing white space,
before it is validated. It looks better to me to run it after the
validation and let know the user that is input is wrong. Then filter
data for formatting and security.
Best Regards,
--
Laurent Melmoux
Annecy, France
