PHP's Built in Input filtering: Pro or Against?
Moderator: General Moderators
PHP's Built in Input filtering: Pro or Against?
So I've found this article pretty much by mistake: http://devzone.zend.com/node/view/id/1113
Read the article AND the comments there, and share your thoughts...
Are you pro PHP's built in input filtering or against?
Read the article AND the comments there, and share your thoughts...
Are you pro PHP's built in input filtering or against?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
I really can't pass judgment, since I haven't actually used input filter for a serious project yet.
I have two disagreements with it though:
I have two disagreements with it though:
- Being PHP 5.1+ is a major downer, since most projects have already developed their own in-house filtering solutions, and it's difficult to swap filter out for something else (no OO means no polymorphism!) (you could try reimplementing filter in PHP-space, but that's no fun).
- The documentation doesn't state exactly what the behavior of the sanitizing and validating filters is, giving PHP-space equivalent functionality. This makes most of the filters a sort of mystery meat: what exactly is an email as defined by FILTER_VALIDATE_EMAIL? They're probably not going by the RFC... But this is not an actual disagreement with the code. Just the docs.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I can really vote for a number of reasons:
1. Yet another filtering library is fine -- but people have to use it.
2. A better idea is to make best practices the easy thing to do by making choke points, like database libs and where output is sent to the response, where filtering is the natural thing to do (good-bye echo()?).
3. It is not OO
4. There should be some reasonable implementation for newbies and a more controllable one for advanced developers
5. And some controllable way to implement/remove across the board filters for the request, response and output to subsystems.
1. Yet another filtering library is fine -- but people have to use it.
2. A better idea is to make best practices the easy thing to do by making choke points, like database libs and where output is sent to the response, where filtering is the natural thing to do (good-bye echo()?).
3. It is not OO
4. There should be some reasonable implementation for newbies and a more controllable one for advanced developers
5. And some controllable way to implement/remove across the board filters for the request, response and output to subsystems.
(#10850)
Yeah, that's what I thought too.timvw wrote:The api for booleans is cluttered...
Where? I mean... as a comment to the article? here on PHPDN? on the php.net site? Becasue I searched on these 3 and didn't find any 'luke'.timvw wrote:But i already posted that(Use the search luke)
By the way, I'm against:
1. This whole idea leaves you without much control.
2. The syntax is really ugly. As someone posted as a comment to the article:
P.S I liked the "STUPID_FOUR_WORDS_CONSTANTS" thingyJust my 5 cents. I think that idea of standard variable filtering is good, but the syntax is realy ugly. Are you sure there can't be no other to creating filters not using functions with 4 parameters one of which is an array itself and two other are some STUPID_FOUR_WORDS_CONSTANTS.
viewtopic.php?p=342183Oren wrote:Where? I mean... as a comment to the article? here on PHPDN? on the php.net site? Becasue I searched on these 3 and didn't find any 'luke'.timvw wrote:But i already posted that(Use the search luke)
OO is the way to go in my opinion. I am in a class that acts as a web design team. I am experienced in PHP, but my fellow classmates are new to it. So far every book supplied to them for aid in PHP has nothing on OOP. I always insist on OOP programing. I am glad I am the project leader to ensure it is done with OOP
. But my vote is against, I would also prefer to write my own validation and filtering procedures.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
I neither way inclined. It's a default extension so whoever is installing has a few options. My main concern is whether PHP developers will work with the extension or against it. Evidence to date is that folk will repeat the mistakes of the past and simply add some code to pretend it doesn't exist. After watching for a while now I think adoption is going to be very difficult...
. The extension C source isn't very long so it's surprisingly easy to follow how everything works in there.
I wish it were OO though - I do find that a bit of a stinker but I suppose that's off the point of its original goal.
They use the same Regex as a component from PEAR - it claims to be RFC compliant but I suspect it's a bit more restrictive than that based on the regex length and a number of tests done in the past. Of course there are likely few regex's capable of covering the entire RFC anywayThey're probably not going by the RFC...
I wish it were OO though - I do find that a bit of a stinker but I suppose that's off the point of its original goal.
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
Personally, I will look into the Zend Framework "Zend_Input_Filter" when it is more mature.. At least then the email check may work (didn't last time I looked).
I agree that when you are looking at legacy data, changing it may cause problems, but when building from scratch it may be worth looking into along with TDD etc, etc, etc (so many new possibilities, so little time).
I agree that when you are looking at legacy data, changing it may cause problems, but when building from scratch it may be worth looking into along with TDD etc, etc, etc (so many new possibilities, so little time).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
As far as I am aware the ZF remains without an email regex. Last I checked they were discussing a very loose form outside the scope of the RFC. Not sure I agree with that - there'll always be a few exceptional users wondering why a login form is insisting their email is wonky
.
Zend_Filter_Input is now being challenged by some new Rule based classes - see Zend_Filter and Zend_Validate. All they need now is a filter manager and I can dump all that repetitive Zend_Filter_Input usage which seems to take up have the code I write for a controller action...
Zend_Filter_Input is now being challenged by some new Rule based classes - see Zend_Filter and Zend_Validate. All they need now is a filter manager and I can dump all that repetitive Zend_Filter_Input usage which seems to take up have the code I write for a controller action...
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Yes, but Zend_Filter and Zend_Validate still accept a single value instead of a container (e.g http request) -- so you need one per variable. That's pretty silly considering that each request var only as one or two filters or rules. It is easier to just call the filters and rules directly which just gets you back to Filter_Input's procedural style.
(#10850)
i really dislike the procedural approach of that extension - so a big "DISLIKE" from me (:
another thing that makes a bit nervous is
Chris
another thing that makes a bit nervous is
cheers“Another example: FILTER_VALIDATE_EMAIL say this is email: “franta@centrum.cz”@seznam.cz is valid. A this “vfranta@centrum.cz”@seznam.cz (added letter v) not. Is this corrent? I don’t think so. But I cannot corect this behaviour in PHP.”
It must a be a bug, the regexp is not perfect (which email regexp is…:). You can “fix” it using your own regexp.
Chris