Quando lasciate all’utente la possibilità di inserire un testo o un commento, che poi andrà a salvarsi nel vostro database, dovete assicurarvi che alcuni caratteri particolari (come gli apostrofi) non vadano a danneggiare la query, provocando degli errori sconfortanti.
Questo può avvenire intenzionalmente (l’utente, cioè, è consapevole del danno e sta cercando di attaccare volontariamente il vostro database; il termine tecnico è query injections), ma anche casualmente: in tal caso la colpa sarà solo nostra.
Per evitare simili disastri, ci vengono in soccorso due funzioni native del PHP:
– addslashes()
aggiungerà il backslash (\) davanti agli apici (‘), doppi apici (“) e ai backslash (\) presenti nella stringa passata. Dovrà essere usata prima di salvare le stringhe nel database.
– stripslashes()
farà il procedimento inverso, togliendo i backslash davanti ai suddetti caratteri e dovrà essere usata una volta estratta la stringa del database e prima di stamparla a video.
Un esempio:
1 2 3 4 |
$stringa="Questa è una stringa di prova con l’apostrofo"; $stringa2=addslashes($stringa); echo $stringa2; // darà come risultato "Questa è una stringa di prova con l\’apostrofo" echo stripslashes($stringa2); //darà come risultato la stringa iniziale |
Facciamo un passo in avanti.
Il php.ini del nostro Apache ha al suo interno la direttiva magic_quotes_gpc
(la sigla “gpc” sta per “get post cookies”). Quando questa è impostata sul valore “on”, non avremo bisogno di usare la funzione addslashes()
nel salvare le nostre stringhe nel database, perché ci penserà autonomamente il server ad aggiungere i backslashes in tutti i valori GET, POST o COOKIES.
Per correttezza, devo sconsigliare l’uso di questa direttiva per due motivi:
1) In genere i server hanno di default la direttiva a on, ma può capitare in caso di trasferimento del sito di trovarci di fronte a un server con la direttiva impostata a off. In questo caso, dovremmo aggiungere manualmente la funzione addslashes()
alle nostre stringhe, perdendo inutilmente del tempo.
2) La direttiva è deprecata in PHP5 e sarà del tutto rimossa con PHP6 per ragioni di efficienza.
Un uso migliore e più performante è avvalersi della funzione mysql_real_escape_string()
. L’unico problema nel suo uso è che se la direttiva magic_quotes_gpc
è attiva, ci sarà un doppio inserimento di slash ai caratteri pericolosi.
Un modo per ovviare al problema è creare uno script che, a seconda del caso, usi o meno la funzione mysql_real_escape_string(
). A questo scopo ci tornerà utile un’altra funzione, get_magic_quotes_gpc()
, che per l’appunto controlla se la direttiva è attiva:
1 2 3 4 |
if(get_magic_quotes_gpc()) return mysql_real_escape_string(stripslashes($string)); else return mysql_real_escape_string($string); |
In questo modo qualsiasi stringa passata avrà lo slash davanti ai caratteri pericolosi.
Dove solo ricordarvi di applicare la funzione stripslashes()
quando i dati saranno recuperati dal database.
Avevo il problema ma non dappertutto e rischiavo di diventare pazzo. Grazie a questo articolo ho capito che deve essere a causa di magic_quotes_gpc in php.ini.
Grazie
Figurati, sono contento che ti sia servito 😉