2011-04-26 13 views
10

Cuando vincula parámetros a la instrucción SQL, puede proporcionar el tipo de parámetro como PDO::PARAM_STR. Si no lo hace, escriba valores predeterminados en PDO::PARAM_STR. ¿Cuáles pueden ser las razones para establecer específicamente el tipo de cada parámetro? PDO :: PARAM_STR funciona con cualquier parámetro, como sé al menos en MySQL. Creo que incluso con PDO :: PARAM_STR se puede usar incluso con columnas BLOB.Razones para escribir fuertemente los parámetros en PDO?

PDO :: PARAM_STR no introduce ninguna inyección de SQL porque todavía tiene consultas preparadas.

Respuesta

7

Usando PARAM_STR pasa a trabajar siempre en valores de columna ya que MySQL implicitly converts values to the correct type where it can, pero fracasará por ejemplo, en esta consulta:

$limit = 1; 

$dbh->prepare("SELECT * FROM items LIMIT :limit"); 
$dbh->bindParam(":limit", $limit, PDO::PARAM_STR); 
    // Will throw "You have an error in your SQL syntax..." 

uno debe utilizar absolutamente PARAM_INT en su caso - para casos como el de arriba, y prepararse para motores de bases de datos que no sean mySQL que pueden ser más estrictos en lo que esperan.

+0

+1 de mí, excelente ejemplo. No es solo la inyección de SQL lo que debe evitarse, mostrar mensajes de error crudos de MySQL al usuario no es realmente atractivo ni profesional, por lo que el desarrollador ** debe ** aplicar siempre la seguridad de tipo. –

+0

@ N.B. para mí es muy aburrido Prefiero el código conciso sobre la repetición de este enlace una y otra vez –

+0

¿Demasiado aburrido para hacer qué? –

5

personalmente no veo ningún motivo, siempre y cuando usted tiene este atributo activo:

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); 

así, sería detectar caso limitará automáticamente

todos modos prefiero definir el tipo en un marcador de posición, no en la función de enlace.

Sin embargo, mi experiencia con PDO no es tan fuerte. Simplemente lo probé y decidí volver al sencillo mysql.

Cuestiones relacionadas