|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #49274 filter_var() should accept objects without fatal error
Submitted: 2009-08-16 22:09 UTC Modified: 2010-05-05 17:37 UTC
From: Assigned: pajoye (profile)
Status: Closed Package: *General Issues
PHP Version: 5.3SVN-2009-08-16 (SVN) OS: *
Private report: No CVE-ID: None
 [2009-08-16 22:09 UTC]
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);

throws a fatal error because stdClass can't be converted into a string.  filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-17 09:32 UTC]
Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string.
 [2009-08-17 11:45 UTC]
don't know, that's up to the developers to decide, don't you think?
 [2009-08-17 13:13 UTC]
This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner.
 [2009-08-17 13:27 UTC]
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));

all work without error.

class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));

works without error.

Only filter_var with an object that doesn't implement __toString fails with an error.  Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani.
 [2009-08-17 13:48 UTC]
As StdClass has no __toString implementation (obviously), it can't be converted to string.

I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API.

I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon).
 [2009-08-17 13:52 UTC]
the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString().  I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler.  The performance should be about the same (dismal).
 [2009-08-17 13:55 UTC]
it is indeed valid for all objects but it is still an edge case.

A check for IS_OBJECT + tostring() existence could be easy enough and with almost no impact(perf impact is null on the existing application). If you have some time to write one, go ahead.
 [2009-08-17 21:59 UTC] should do it. I did not not test more than the test case here.
 [2009-09-05 17:35 UTC]
Automatic comment from SVN on behalf of pajoye
Log: - fix #49274, filter_var does not accept object without a toString implementation
 [2009-09-05 17:37 UTC]
I will close it as soon as it gets merged in 5.3.1, if the RM agrees.
 [2009-10-09 17:32 UTC]
Automatic comment from SVN on behalf of pajoye
Log: - Merge: fix #49274, filter_var does not accept object without a toString implementation
 [2010-05-05 17:37 UTC]
-Status: Assigned +Status: Closed -Package: Feature/Change Request +Package: *General Issues
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Mar 09 11:01:23 2021 UTC