Opened 2 years ago
Last modified 16 months ago
#16867 reopened enhancement
Where is it appropriate to use filter_var
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | General | Version: | 3.2 |
| Severity: | normal | Keywords: | westi-likes needs-patch |
| Cc: | dkikizas@… |
Description
Now that we require PHP 5.2 we have access to a whole plethora of new functions. One of those is filter_var. It seems like this could be useful for things like validating and filtering E-Mail addresses, URLs, IPs, etc. (there are plenty of [php.net/manual/en/filter.filters.php filters]).
This was brought up in #15379 where nacin said:
Those can be buggy. We could potentially leverage it internally but we need to watch out for vulnerabilities and what not across PHP versions.
I mostly wanted this to be the place where we decide what could benefit from it and what shouldn't.
Change History (8)
comment:2
in reply to:
↑ 1
aaroncampbell — 2 years ago
Replying to scribu:
I'm not sure that's a fair assessment. We obviously use a TON of PHP functions without much worry as to dealing with PHPs bugs, and when PHP bugs have plagued us we've dealt with them. If we can say that this particular function (or some of it's specific filters) are considerably more prone to bugs, or even that there are several versions of PHP that we will be supporting with known issues, then maybe we could justify ignoring them. I just want to make sure we've considered their possible advantages such as red-lining the whole is_email function.
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from new to closed
- Type changed from defect (bug) to enhancement
Think its safe to close this as maybelater.
- Keywords westi-likes needs-patch added; 2nd-opinion removed
- Milestone set to Future Release
- Resolution maybelater deleted
- Status changed from closed to reopened
- Version set to 3.2
I think we can consider using this for a few small situations where it is likely to be safe and stable to use and gives better performance than our current solutions:
- IP Address filtering - faster than the regular expression based solution we have now
- is_email - better coverage than our current solution.
If someone was to create a patch for this that would be great - this includes creating a new IP address sanitisation wrapper function to replace the duplicated preg_ code we have at the moment.
comment:6
SergeyBiryukov — 17 months ago
Related: #18658
Worth mentioning that it is possible to compile PHP with --disable-filter. Same deal as JSON. Need to be careful about compatibility here.

I guess it boils down to this: do we want to handle our own bugs or PHPs? :)