Re: Sanitize filters

On 04/10/2022 01:38, David Gebler wrote:

What about FILTER_VALIDATE_EMAIL which is notorious for being next to useless? [...] Seems to me like there could at the very least be a plausible case for some better [...] is_valid_email() etc. type functions in core to replace some of the filter API.

The "notorious" thing I know is that validating e-mail addresses is next to impossible because of multiple overlapping standards, and a huge number of esoteric variations that might or might not actually be deliverable in practice. If you think the implementation can be improved, that doesn't need a new is_valid_email() function, just a tested and documented patch to the existing one; if it can't be improved, then any new function will be just as useless. In practice, the most common typos don't result in invalid e-mail addresses anyway, just incorrect ones - "gamil.com" instead of "gmail.com", and so on. For those, you don't need to Validate or Sanitize; you need to Escape and Verify: escape what you're given (context-dependent, so necessarily part of an SMTP or API client library), attempt to send an e-mail, and wait for the user to verify they've received it. On 04/10/2022 02:29, Vasilii Shpilchin wrote:

filter_input() is the only alternative to accessing superglobal arrays directly. [...]

FILTER_SANITIZE_EMAIL - helps to clean up typical mess caused by copy-pasting an email. FILTER_SANITIZE_URI - similar thing but to URIs. FILTER_SANITIZE_NUMBER_FLOAT - nice since it provides a flag to control scientific notation

None of these sounds very useful to me, but I think that just confirms the biggest problem with the extension: it's trying to be everything to everyone, and ends up with a bewildering set of options as a result. I don't think any rewrite or replacement can ever avoid that problem, because it's inherent in the problem space. I have a draft proposal I might share soon for some "strict cast" functions, but even simple cases like "string to integer" could have a dozen different implementations which would all be equally "valid" according to some use case or opinion, so it's a bit of a quagmire. Regards, -- Rowan Tommins [IMSoP]