[Reager]

Om inte SQL när man använder PHP skiljer sig från vanlig SQL så kan det vara värt att påpeka att det är felaktig SQL oxå.

$sql = "INSERT INTO tblIngrediens SET ingrediens='$xingrediens'";

Ser ut som en blandning mellan INSERT och UPDATE. Den korrekta bör väl vara

$sql = "INSERT INTO tblIngrediens VALUES('" . $xingrediens ."')";

Såg inte att någon påpekat detta tidigare och det kan ju vara bra att veta

[tartareandesire]

Ursprungligen postat av Reager

Om inte SQL när man använder PHP skiljer sig från vanlig SQL så kan det vara värt att påpeka att det är felaktig SQL oxå.

$sql = "INSERT INTO tblIngrediens SET ingrediens='$xingrediens'";

Ser ut som en blandning mellan INSERT och UPDATE. Den korrekta bör väl vara

$sql = "INSERT INTO tblIngrediens VALUES('" . $xingrediens ."')";

Såg inte att någon påpekat detta tidigare och det kan ju vara bra att veta

Det går alldeles utmärkt att köra "update"-varianten också om man kör MySQL (PHP har inget med saken att göra) vilken jag själv rekommenderar då koden blir mer logisk och lättläst.

[Nerox]

Ursprungligen postat av Reager

Om inte SQL när man använder PHP skiljer sig från vanlig SQL så kan det vara värt att påpeka att det är felaktig SQL oxå.

$sql = "INSERT INTO tblIngrediens SET ingrediens='$xingrediens'";

Ser ut som en blandning mellan INSERT och UPDATE. Den korrekta bör väl vara

$sql = "INSERT INTO tblIngrediens VALUES('" . $xingrediens ."')";

Såg inte att någon påpekat detta tidigare och det kan ju vara bra att veta

Ska man vara petig ska du väll ha deklarerat vilke kolumner du sätte in värden i med

$sql = "INSERT INTO tblIngrediens (ingridiens)VALUES('" . $xingrediens ."')";

[Fia]

Jag har använt denna vid formulär inlägg till DB, går inte det lika bra?

function addslashes_deep($value)
{
$value = is_array($value) ?
array_map('addslashes_deep', $value) :
addslashes($value);
return $value;
}

också strippar jag det med en liknande function när jag hämtar det.

[dotvoid]

Som tartareandesire påpekar går det lika bra att använda INSERT...SET-syntaxen så länge man håller sig till MySQL. Ska du byta databas blir det jobbigare eftersom det inte följer SQL-standard(er). Men ärligt talat - hur ofta byter man databas? (Själv skulle jag iofs undvika just den syntaxen.)

Funktionen addslashes() är inte lika bra. Den har problem med multibyte-characters t ex. Till och med dokumentationen, http://se2.php.net/addslashes, säger att man bör använda mysql_real_escape_string() eller motsvarande för andra databaser istället för addslashes().

Jag har hört att addslashes() ska droppas från PHP6 men jag har inte kollat upp det själv.

[Fia]

Synd det var så smidigt att bara lägga functionen på $POST nu måste man ju gå in på varje sträng som ska in och lägga till mysql_real_escape_string(). Då har jag syselsättnig idag i alla fall.......
Eller skulle man kunna byta ut addslashes() mot mysql_escape_string() i functionen, Bara spånar lite, det får jag prova. Tack för all lärorik information.

[dotvoid]

Ja du skulle kunna byta ut addslashes() mot mysql_real_escape_string(). (Tänk bara på att databaskopplingen redan måste vara etablerad för att mysql_real_escape_string() ska fungera.)

[Fia]

Så här blev det.
function addslashes_deep($value)
{
$value = is_array($value) ?
array_map('addslashes_deep', $value) :
mysql_real_escape_string(trim($value));
return $value;
}

Så kör jag den här
$_POST = addslashes_deep($_POST);

Och vill man bli av med html oxå så

mysql_real_escape_string(strip_tags(trim($value))) ;

[danjel]

Tänk på att man man kanske vill använda $_POST variabler till annat än DB frågor efter att du kört addslashes_deep , tex skriva ut värden, maila eller liknande , så undvik helst denna princip framöver..
Som någon har sagt säkert redan i tråden, kör pdo prepared statements så slipper man alls bekymra sig om detta säkerhetshål

[tartareandesire]

Ursprungligen postat av danjel

Tänk på att man man kanske vill använda $_POST variabler till annat än DB frågor efter att du kört addslashes_deep , tex skriva ut värden, maila eller liknande , så undvik helst denna princip framöver..
Som någon har sagt säkert redan i tråden, kör pdo prepared statements så slipper man alls bekymra sig om detta säkerhetshål

Det går ju att tilldela andra variabler för det som behövs skrivas ut i så fall.