¿Funciona correctamente la función filter_input de PHP?

me trataron función integrada de PHP: filter_input()¿Funciona correctamente la función filter_input de PHP?

var_dump(filter_var('[email protected]', FILTER_VALIDATE_EMAIL));

Salida:

string (19) "john.doe @ gmail.com"

Luego probé la última versión de Zend Framework (1.11.3):

$validator = new Zend_Validate_EmailAddress(); 
if ($validator->isValid('[email protected]')) { 
    echo 'OK'; 
} else { 
    foreach ($validator->getMessages() as $message) { 
      echo "$message\n"; 
    } 
}

Salida:

'john.doe.' no se puede comparar con el formato de punto-átomo
'john.doe.' no se puede comparar con el formato de cadena entrecomillada
'john.doe.' ya no es parte local válida dirección de correo electrónico 'john.doe. @ gmail.com'

O bien la función incorporada debe devolver FALSO o el método de Zend 'OK'.

Mi pregunta central es:
¿Cuál es la correcta?

Fuente

2011-02-23 user523736

Si quiere el mejor validador de correo php, vaya aquí: http://www.dominicsayers.com/isemail/ – rojoca

http://framework.zend.com/manual/en/zend.validate.set.html realmente no indica si están siendo estrictamente RFC o no, así que veamos la fuente.

En la fuente, _validateLocalPart() define la EBNF que están a juego en contra:

// Dot-atom characters are: 1*atext *("." 1*atext) 
    // atext: ALPHA/DIGIT/and "!", "#", "$", "%", "&", "'", "*", 
    //  "+", "-", "/", "=", "?", "^", "_", "`", "{", "|", "}", "~" 
    if (preg_match('/^[' . $atext . ']+(\x2e+[' . $atext . ']+)*$/', $this->_localPart)) {

Parece que definitivamente se quedan estricta a que - por lo que la parte local no pueden comenzar o terminar con un punto.

El patrón anterior es exactamente el mismo que en la especificación RFC2822: http://www.ietf.org/rfc/rfc2822.txt - y el bloque de documentación isValid en Zend/Validar/EmailAddress.php hace referencia a ella como el uso de 2822.

lo tanto, si quieres ser compatible con RFC2822 , Zend_Validate_EmailAddress lo está haciendo bien, y es probable que filter_input lo esté haciendo fuera de especificaciones.

Fuente

2011-02-23 17:25:12 Justin

Puede ser simplemente que el Zend_Engine se ajuste estrictamente al RFC (que tiene 3 millas de largo, para los correos electrónicos). Sospecho que, estrictamente hablando, los períodos son caracteres permitidos, pero un período justo antes de que la posición @ no esté permitida, por lo que ese es probablemente el problema.

Voy a suponer que gmail todavía permitirá el envío de john.doe. @ Gmail.com. Si ese es el caso, la pregunta se trata más bien de si realmente desea coincidir estrictamente con el RFC, o simplemente ser permisivo en las direcciones de correo electrónico permitidas para los casos en que no dañe su sistema.

Si le preocupa la inyección sql, enlace sus variables en sql & escapé de su html, porque no hay garantía de que una coincidencia estricta del rfc realmente evitará tales problemas.

Si le preocupan los correos electrónicos que pueden enviarse o recibirse, le aconsejo que simplemente los envíe con la expectativa de recibirlos o que configure un sistema de confirmación de correo electrónico opcional utilizando un enlace de confirmación.

Si le preocupa la inyección de encabezado de correo electrónico, esa es una buena razón para usar una biblioteca de correo electrónico al enviar correo, supongo que zend tiene una robusta.

TooLongDidn'tRead; mi consejo es:

Sea permisivo. (por lo tanto, use la opción que sea más permisiva, en este caso filter_input)
Compruebe si un correo electrónico funciona enviando el correo electrónico, es casi la única prueba verdadera.
html-escape & sql-ata todo cuando sea el momento de usarlo en html o sql, y no confíe en nada que pueda venir del mundo peligroso más allá cada vez que lo use.
No utilice el php mail explotable(), utilice una biblioteca que evitará la inyección de encabezado de correo.

Fuente

2011-02-23 16:02:12 Kzqai

Si bien no dio una respuesta exacta a la pregunta, definitivamente me puso en el camino correcto y usted cubrió todos los campos posiblemente problemáticos. Me convenciste de que mi pregunta no era lo suficientemente exacta. Debería haber sido: "** ¿Cuál es el adecuado para un problema específico?" ** "¡Gracias! Yo votaría si pudiera :) – user523736

También depende de la versión de PHP que tenga. PHP 5.2.14 y posteriores (así como 5.3) tienen una expresión regular actualizada (ver the commit to the PHP source code). PHP 5.2.13RC2 y siguientes tienen la expresión regular anterior. Consulte también Bug #49576.

Fuente

2011-02-24 00:53:23 cmbuckley

Sí, lo siento por perderme eso en mi primer post. PHP Version 5.3.1 – user523736

Mi error. Parece que la expresión regular actualizada no llega a la rama 5.3 hasta 5.3.3RC1. – cmbuckley

¿Funciona correctamente la función filter_input de PHP?

Respuesta

Cuestiones relacionadas