Am 19.09.2011 16:55, schrieb Hank:
>>
>> what ugly style - if it is not numeric and you throw it to the database
>> you are one of the many with a sql-injection because if you are get
>> ivalid values until there you have done no sanitize before and do not here
>>
>>
> It's a matter of opinion. I never said the data wasn't sanitized (it is).
> But sometimes calculated values or bugs in PHP code end up with a null
> variable field. I was just suggesting the choice between two errors -- one
> syntax which will generate a hard failure of the query and likely whatever
> page, or a soft logical error, which won't. In either case, I have error
> trapping to catch both types of errors and alert me to them. I prefer the
> errors to be logical ones and not syntax errors.
>
>
>> $sql="INSERT into table VALUES (" . (int)$id . ",'" .
> mysql_real_escape_string($val) . "')";
>> or using a abstraction-layer (simple self written class)
>> $sql="INSERT into table VALUES (" . (int)$id . ",'" .
> $db->escape_string($val) . "')";
>
> I think what you posted is ugly "style" which makes reading the actual SQL
> in PHP code much harder to read and debug. The data validation should take
> place elsewhere long before it gets to constructing the SQL statement.it is not because it is clear that it is sanitized instead hope and pray thousands of layers somewhere else did it - for a inline-query the best solution, if you are using a framework you will never have the "insert into" at this place! what i meant as ugly is that you are somewhere writing an inline-query and are not sure if it is a number or not - so it is NOT sanitized before because if you tell me it is you sanitze does not work if you get a non-integer at this point and you sanitze-method has to throw the error long before if it is really working
signature.asc
Description: OpenPGP digital signature
