info su htmlentities()

[.Kurt]

capisco ma non sono convinto..intanto grazie!

L'unica azione leggittima sarebbe quella di limitarsi a controllare il contenuto del testo che si vuole salvare nel database e decidere se rifiutarlo o meno. E' troppo corto? Troppo lungo? Contiene parolaccie? Contiene tag html? Ma comunque sia non devi modificarlo, per tutti i motivi che chumkiu ti ha ben esposto. Lo vincoleresti ad un solo utilizzo, e questo è un errore sia logico che pratico. Perchè se un giorno volessi inviare quei dati in un posto che non sia una pagina html non potrei farlo. Ad esempio, se volessi inviarli via email? Dovrei ricordarmi che li ho codificati in una certa maniera, in qualche modo li ho adattati solo ed esclusivamente per le pagine html, e dovrei lavorare per riconvertirli al loro stato originario prima di poterli inviare. E se i filtri che ho utilizzato per salvare quei dati avessero una mancanza? Mi accorgo solo successivamente che "<script>" non è permesso, ma "< script>" si. Cosa faccio? Modifico tutti i dati del database per fare in modo che i dati rientrino negli schemi dei nuovi filtri? O ancora, decido di salvare tutti i nomi degli utenti nella mia tabella "users". Prima di salvare il nome dell'utente, che verrà successivamente stampato nella pagina html, decido di trasformare tutti i corrispondenti caratteri speciali nelle relative entità. Successivamente, al momento del login, decido di recuperare tutti i dati dell'utente partendo dal suo nome. Come faccio la query? SELECT * FROM users WHERE username = 'xxx'; Ma tutti i nomi utente li ho salvati codificandoli in una determinata maniera. ... WHERE username = 'Federico<91>' non recupererà nessun dato, dovrei effettuare lo stesso tipo di conversione che ho usato per salvare i dati anche per recuperarli successivamente. Roba da pazzi.

Non sei ancora convinto?

[chumkiu]

Tra l'altro ci è successo proprio di recente.


Il content management aziendale era solito inserire manualmente l'entità & shy; nelle parole troppo lunghe (è una entità che spezza la parola in quel punto se vi è necessità, in alcune lingue è vitale ).


Questo è un caso borderline perché non vi è un modo pulito per dare questa informazione al dato. Fatto sta che è dal 2006 che lo inseriscono. Dalla settimana scorsa, questi stessi dati servono per un supporto tv (chi l'avrebbe immaginato nel 2006?), forniti via REST, che ovviamente non ha la minima idea di cosa sia questo & shy; e lo visualizza in mondovisione così com'è scritto.

E' un granello di sabbia... ma i granelli di sabbia possono rompere certi meccanismi

EDIT: fico. Sparisce anche dal forum se la scrivo

#

[leaf]

no ok dovrei essere convinto..oggi non sono riuscito a fare delle prove quindi ora ipotizzo..nel database ho una lettera accentata e un apostrofo..prima di stamparli in una tabella li passo dentro htmlentities (come mi state dicendo di fare per i motivi x)..cosa mi esce?
comunque gentilissimi davvero
L.

[.Kurt]

cosa mi esce?

Il comportamento di htmlentities ormai lo conosci: http://php.net/manual/it/function.htmlentities.php. L'apostrofo (') viene convertito in & #039; (ma solo impostando correttamente il secondo argomento della funzione, di default non li modifica).

echo htmlentities("èòàù"); // restituisce èòàù

[chumkiu]

Un altro piccolo consiglio.
Fatti una funzione tua che utilizza la funzione htmlentities con gli opportuni flags e charset. Così non devi specificarli ogni volta (e se cambi charset è più facile aggiornare il codice.

Qualcosa tipo:

function escape($text) { return htmlentities($text,ENT_COMPAT,'UTF-8');  }

echo escape("èòààò");

[leaf]

scusate se non ho più ruisposto ma avevo un problema più grave
comunque ok, ho fatto la funzione escape, sembra ok..la sto testando sui valori estratti dal db ad esempio

td>Numero Tessera</td>
                <td><?php echo escape($col[1]) ?></td>

grazie per i chiarimenti!! mi sto prendendo un sacco con l'aspetto "sicurezza" web
ciao,
Leaf