Dubbi su mysql_escape_string e magic_quotes_gpc

[bigrattle]

Salve, passo subito al nocciolo...

Duqnue, prendo un valore da un campo e lo metto in una variabile che poi passo al database. la variabile la inizializzo così:
$text1 = mysql_escape_string($_POST['text1']);

e quando la devo stampare la richiamo in questo modo:
$text1 = stripslashes($myrow["text1"]);


Ho visto che nel database il testo premette un backslash ad apici e doppi apici. Cosa che credo sia giusta. Mi incuriosisce però il fatto che al momento di inviare i valori al database, cioè subito dopo aver cliccato sul pulsante submit, nelle caselle del form si vedano tre backslashes. cioè, credo, uno per gli apici e l'altro forse per un backslash che credo aggiunga il server. Ho fatto un controllo ed ho visto che l'opzione magic quotes è così settata:

magic_quotes_gpc On On
magic_quotes_runtime Off Off
magic_quotes_sybase Off Off

Cosa mi conviene fare dunque? lascio o tolgo mysql_escape_string?


Altra questione... in un campo input di tipo text, pur assegnando alla variabile il record del database filtrato con stripslashes (cioè: $titolo = stripslashes($myrow["titolo"]) quando il testo incontra un doppio apice si interrompe. L'unico modo per poterlo vedere completo è utilizzare htmlentities. Questo mi succede soltanto nel campo "text" e non per esempio nella textarea (forse perché la textarea è quella dell'editor tinymce, ma non andiamo troppo fuori argomento). E' normale che debba utilizzare htmlentities?
E DOVE è meglio utilizzarlo? Direttamente nel input ( <input type="text" name="title" id="title" value="<?php echo htmlentities($title) ?>" /> oppure quando inizializzo la variabile?

[piero.mac]

qui trovi le risposte:

http://forum.html.it/forum/showthrea...ostid=10166292

[bigrattle]

grazie per la segnalazione, piero.mac!
non sono riuscito però a capire la questione riguardante htmlindentities... che al momento è l'unico modo che ho di visualizzare correttamente il campo di testo. Dimenticavo di dire che nel caso specifico pesco quei valori dal database per editarli in una pagina di edit (ecco perché poi ne stampo il valore nella casella che ho chiamato titolo)

[bigrattle]

dopo aver letto la pillola segnalatami da piero.mac torno a chiedervi aiuto (la questione del campo di testo non l'ho risolta ancora, ma forse c'è qualche errore che ora mi sfugge)... vorrei quindi tornare alla pillola e chiedervi se facendo così faccio bene...
(nel db non appare nessun backslash ora)

	  $titolo = ($_POST['titolo']);
	  $text1 = ($_POST['text1']);
      	  $text2 = ($_POST['text2']);
	  
	  
	  if(get_magic_quotes_gpc())
		{
	  $titolo =  stripslashes($titolo);
	  $text1 =  stripslashes($text1);
          $text2 =  stripslashes($text2);
		}
		
	  $titolo = mysql_real_escape_string($titolo);
	  $text1 = mysql_real_escape_string($text1);
          $text2 = mysql_real_escape_string($text2);

La connessione al db la faccio dopo così:

$result = mysql_query("INSERT INTO prova_tab (dtime, titolo, text1, text2) VALUES (NOW(), '$titolo', '$text1','$text2')" ,$connect);

devo correggere qualcosa?

[bigrattle]

scusate, faccio un up (promesso, sarà l'unico in una settimana, anche se lo sto facendo forse troppo presto)

[piero.mac]

Originariamente inviato da bigrattle
scusate, faccio un up (promesso, sarà l'unico in una settimana, anche se lo sto facendo forse troppo presto)

stai chiedendo conferma di una cosa che puoi provare da te.

Prendi quello che ti dico nel senso giusto, cioe' non di critica vanesia ma di suggerimento. Se lo provi e funziona per le tue necessita' allora va bene. Se non e' perfettamente corretto allora non funziona. Chi ti legge non conosce il contesto e il tuo progetto od il tuo scenario di lavoro per cui definire una cosa sintatticamente corretta non significa che sia allo stesso tempo funzionale.

Auguri.

[bigrattle]

si, hai ragione, indubbiamente. in effetti mi chiedevo solo se usando questa sintassi stessi rispettando il giusto ordine di applicazione della funzione mysql_real_escape_string... valida sia con magiq_quotes settate sia su on che su off.
nel db i dati arrivano senza backslashes, considerando che il tutto è per pochi utenti controllati (un piccolo gestionale per alcune pagine soltanto) non dovrei avere problemi...
quello che non sapevo se era giusto è l'ordine in cui faccio il collegamento al db, o meglio, ho letto nella pillola che mi hai segnalato che mysql_real_escape_string ha come secondo parametro la connessione al db... parametro che io non ho messo...
grazie per le risposte la pazienza e buon fine settimana

[bigrattle]

dimenticavo... quello che non funziona è sempre quel campo input text che ha bisogno di htmlidentities per stampare correttamente...

[bigrattle]

mannaggia, mi sto esprimendo male... una notte lunga ed insonne alle spalle non aiuta certo...
provo a riepilogare la situazione relativa a questo input, di tipo text.

il contenuto viene pescato dal database (che ora non ha alcun backslash come già detto). quando incontra un doppio apice la stringa si interrompe (cosa che non succede nelle textarea).

Se stampo il contenuto della variabile da un'altra parte questo appare completo.
E' solo lì che si interrompe...

Per ovviare alla cosa utilizzo la funzione già ricordata (htmlentities) ma non so se è una scelta giusta.

[piero.mac]

La scelta puo' essere giusta.

Devi considerare che alcuni caratteri possono avere piu' di una funzione. Per esempio proprio apici e doppi apici ma anche il backslash \ possono avere sia funzione di controllo che funzione di stringa. Ovvio che bisogna identificare correttamente quando e' controllo e quando e' stringa. Per questo ci sono i caratteri chiamati di escape che precedendo un carattere ascii ne definiscono la funzione.

Ovvio che se invece del carattere ascii (es " ) tu metti l'equivalente come entita' html non hai piu' il problema di gestire l'escape. Ma non solo, htmlentities converte tutti i possibili caratteri in entità HTML e superi cosi' anche le diversita' del character set. Cosa che normalmente fanno gli editor online (es.: fckeditor) basta controllare il codice sorgente che realizzano.

Altro esempio: mysql_real_escape_string() provvede ad aggiungere il corretto carattere di escape alle stringhe in relazione al tipo di connessione e database utilizzato per le stringhe che devono essere immesse nella tabella. Ovviamente dopo l'inserimento l'escape non ha piu' ragione di esistere e difatti viene eliminato dal campo della tabella.

le magic_quote_gpc (gpc sta per GET, POST, COOKIE) provvedono ad inserire automaticamente questi caratteri a scopo anche preventivo di possibili sql injection, ma questi escape possono anche essere "diversi" o non "servire" al nostro scopo. Quindi da qui viene prima di tutto la necessita' di rimuoverli nel caso ci fossero e poi utilizzare mysql_real_escape_string per inserire quelli corretti.

Conviene o non conviene inserire nella tabella le stringhe convertite da htmlentities ??? beh! io dico dipende... se devo fare delle ricerche sul contenuto dovro' passare delle stringhe convertite visto che mi ricerchera' solo caratteri ascii, ma se devo solo stamparle non dovro' convertirle ogni volta... diciamo che "forse" sarebbe meglio inserire il testo cosi' com'e' senza entita html. Personalmente ritengo che dipenda da come si struttura il progetto.


Mi perdonino i puristi per il linguaggio approssimativo e discorsivo utilizzato ma la sostanza e' quella descritta.