DematVr Forum

Salve, rinnovando la premessa che non programmo in PHP, ho notato che la gestione perlomeno di accenti, virgolette doppie e semplici non è corretta in quanto nel database, correttamente definito con campi utf8, finiscono i caratteri di escape che vengono usati in html.
Esempio (inventato):
ist. "Salò d'Alba" così
finisce nel database, tabella "(prefisso)tbl_specializzazioni", campo "denominazione"
ist. "Salò d'Alba" cos&igrav
Questo comporta numerosi problemi:
- il trattamento dei dati in altro modo risulta difficile in quanto il contenuto non è "normale"
- se il campo non è abbastanza ampio avviene un troncamento, che es. in questo caso interessa parte dell'escape finale html con bizzarri risultati in visualizzazione
Non so come si faccia in php (io finora ho usato solo ruby on rails ed era gestito automaticamente) ma è necessario usare funzionalità che convertano in scrittura e riconvertano in lettura.

La conversione dei caratteri speciali è un problema che ci sta assillando da molto. Purtroppo non c'è mai stato il tempo di prenderlo di petto per risolverlo una volta per tutte. Devo dire che la soluzione della codifica html è risultata fino ad ora la più 'stabile'. Magari ora con più calma cercheremo di risolvere anche quei problemi che hai citato.

Se poi tu avessi un po' di tempo e voglia per cimentarti con il php ...
Ogni aiuto è gradito.

_________________
Pietro

Ok, analizzando il vostro codice mi pare di capire che in funzioni.php usate function stringa_html($parametro = '', $metodo = '') per "disinfestare" le stringhe da eventuali attacchi di tipo sql-injection, ma facendo così le trasformate in html, il che vogliamo evitare.
Da quel che ho capito il modo corretto per procedere in php è forse un po' meno comodo ma diverso e più sicuro (e che rocorda a grandi linee il modo di operare di rails).
Si tratta di non costruire mai le istruzioni sql aggiungendo le stringhe di input al comando, ma di creare sempre query parametrizzate e passare i valori di input come parametri.
Vedo anche dal repository git che state passando al collegamento sql con "mysqli" (ottimo)

pertanto es. nel file agg_spe.php

$deno = stringa_html('denomin');
$idsp = stringa_html('idspecializzazione');
$sql="UPDATE tbl_specializzazioni SET denominazione='$deno' WHERE idspecializzazione=$idsp";
etc.

diventa:
(con $con = l'oggetto della connessione mySQLi come da vostro git repository credo)

$deno = $_GET['denomin'];
$idsp = $_GET['idspecializzazione'];

if ($stmt = $con->prepare("UPDATE tbl_specializzazioni SET denominazione = ? WHERE idspecializzazione = ?")) {

// Associa le variabili ai parametri con il tipo opportuno (in questo caso, stringa s e intero i)
$stmt->bind_param("si", $deno, $idsp);

// Execute the statement.
if($stmt->execute())
{
print("\n<FONT SIZE='+2'> <CENTER>Modifica eseguita</CENTER> </FONT>");
}
else
{
print("\n<FONT SIZE='+2'> <CENTER>Modifica non eseguita</CENTER> </FONT>");
}

// Close the prepared statement.
$stmt->close();
}

Un lavoro un po' tedioso ripassarsi tutto il codice ma prima è meglio è. Es. nella mia scuola molti studenti hanno il cognome con lettere accentate, idem il nome di alcuni plessi hanno accenti o apostrofi...
Saluti
Marco

mmenaz ha scritto:
> Ok, analizzando il vostro codice mi pare di capire che in funzioni.php usate function
> stringa_html($parametro = '', $metodo = '') per "disinfestare" le stringhe
> da eventuali attacchi di tipo sql-injection, ma facendo così le trasformate in html,
> il che vogliamo evitare.
> Da quel che ho capito il modo corretto per procedere in php è forse un po' meno
> comodo ma diverso e più sicuro (e che rocorda a grandi linee il modo di operare di
> rails).
> Si tratta di non costruire mai le istruzioni sql aggiungendo le stringhe di input al
> comando, ma di creare sempre query parametrizzate e passare i valori di input come
> parametri.

Questo vale in una situazione ottimale! In realtà ormai tutto il codice è fatto con l'inserimento delle stringhe all'interno dei comandi e ripassare il codice significherebbe praticamente riscrivere tutto (qualche mese di lavoro?).
La tua analisi su come dovrebbe essere scritto il codice con mysqli è sostanzialmente corretta ma per il momento lo scopo è solo quello di eliminare le funzioni mysql che sono 'deprecated'. Magari in tempi più tranquilli si procederà alla riscrittura del codice con i prepared statement.
> Es. nella
> mia scuola molti studenti hanno il cognome con lettere accentate, idem il nome di
> alcuni plessi hanno accenti o apostrofi...
>

La situazione con alunni e plessi con l'apostrofo o gli accenti è abbastanza diffusa e, con la soluzione dell'html, fino ad ora non ha creato particolari problemi. Abbiamo in previsione di effettuare dei cambiamenti nella struttura e lunghezza dei campi di testo proprio per evitare eventuali problemi.
Se dalle prove da te effettuate risulta qualche problema particolare (in situazioni di utilizzo normale) facci sapere.

_________________
Pietro

Se volete, previo accordo privato su modalità e tempi, mi occupo io di modificare il codice almeno per le anagrafiche principali che non credo vengano toccate (perlomeno nel campo descrittivo) al di fuori della gestione tabelle o al massimo l'import csv, e mi riferisco alle tabelle dei plessi, alunni ed insegnanti.
Ripeto, prima si fa e meno "pattume" finisce nelle tabelle. Non vorrei trovarmi con dati che se esportati es. in csv per essere elaborati con Calc mi compaiono con tutti i tag html.
Vedo da git che state modificando il metodo in molte form da get a post, altra cosa da fare senz'altro quando si modificano i dati. Aspetto qualche giorno che il codice si stabilizzi? Intanto approfondisco github, perché finora ho usato git solo in locale, magari è facile fare un branch online dedicato e darmi accesso per le modifiche di cui fare merge successivamente.
Saluti e buon lavoro
Marco

Ho rilasciato la correzione per registrare solo i caratteri utf-8 e non più html.
La funzione elimina_apici usa la funzione html_entity_decode($stringa, ENT_QUOTES, 'UTF-8'); per convertire i caratteri html in utf-8.

Per ora cerco di ripassare nel codice tutte le insert e le update che usano le stringhe per sfruttare la elimina_apici.
La visualizzazione delle stringhe nelle pagine rimane invariata.

_________________
Renato