Comportamento anomalo in Safari con tag IMG

(No Ratings Yet)

 Loading ...

Posted by redsend | Filed under BugFix

Oggi ho passato più di 6 ore per correggere un bug.

Scrivo questo post per aiutare quei poveri programmatori che si troveranno nella mia stessa situazione. Brevemente spiegherò i sintomi che venivano rilevati nell’applicazione web e poi vi illustrerò da cosa dipendeva il problema e come viene risolto.

I sintomi che si presentavano era un azzeramento anomalo della sessione, venivano resettate alcune variabili in sessione e rigenerati alcuni codici di controllo che quindi compromettevano il flusso tra le pagine web dell’applicazione. I cookie erano impostati correttamente e con durata infinita, quindi non poteva essere un problema di scadenza dei cookie. I file della sessione erano scrivibili e venivano correttamente aggiornati in altri casi e quindi non poteva essere un problema di permessi sui file della sessione, altrimenti l’errore si sarebbe presentato a monte. L’errore accadeva solo utilizzando Safari e con Firefox questo non accadeva, il che complicava ancora di più le cose perché trattandosi di sessioni PHP e quindi di script che vengono eseguiti lato server non aveva alcun senso che su un browser funzionasse mentre sull’altro no.

L’errore che era stato commesso era un tag immagine con l’attributo src uguale a stringa vuota (src=”" per intenderci).

In questo caso Firefox semplicemente eliminava l’immagine dal flusso HTML e quindi non accadeva nulla di strano, mentre Safari, il buono e caro Safari (sto cercando di trattenermi dal rompere tutto), cosa fà? Suppone che per qualche arcano motivo l’immagine inserita senza path si trovi nell’indirizzo della pagina php invocata e quindi effettua un secondo chiamata alla pagina che compromette tutto il funzionamento della sessione PHP e del flusso che stavano seguendo le pagine.

Per farmi capire meglio la pagina chiamata ad esempio era index.php e Safari trovando un tang IMG con src=”" sostituisce all’indirizzo dell’immagine index.php, quindi otteniamo una cosa del genere: src=”index.php”, in che corrisponde ad una seconda invocazione della pagina index.php che potrebbe, come nel mio caso, compromettere il flusso che si stava seguendo attraverso form etc… questo perché, ad esempio, nell’invocazione di index.php senza nessun parametro e sottomissione di form, veniva esegueto l’azzeramento della sessione…

Bhè ottimo lavoro da parte di quelli di Safari per questa emerita scelta progettuale… e spero di aver risparmiato tante ore di debug ad altri poveri programmatori che si troveranno in questa situazione.

Tags: bug > html > img > php > safari

Caratteri speciali & codifiche su php, mysql e javascript: la soluzione definitiva

(1 votes, average: 5,00 out of 5)

 Loading ...

Posted by raphe | Filed under Appunti, Programming

Il titolo del post è un po’ caotico ma non avevo idea di come scrivere qualcosa di più esplicativo.
Come per i post relativi alle sessioni, anche questo post ha l’obiettivo di essere un appunto per me per il futuro e un riepilogo di cose conoscenze acquisite nel tempo.

Dimentichiamoci delle funzioni htmlspecialchars, htmlentities, html_entity_decode, addslashes, escape, encodeURI, ecc…con una buona configurazione dei vari componenti potremo lavorare in modo trasparente!

Un po’ di teoria

La questione “caratteri speciali” è ben nota a chi si trova a sviluppare per il web, in giro per la rete ci sono centinaia di blog, forum e siti che suggeriscono modi per mostrare al meglio i caratteri accentati e ogni tipo di entità html. La difficoltà sta quasi sempre nell’uso di diverse codifiche nei vari componenti coinvolti (linguaggi di programmazione, database, browser, ecc.). Come prima cosa è bene, quindi, decidere all’inizio quale codifica utilizzare e portare avanti questa scelta in tutti i settaggi che verranno fatti in futuro.

UTF-8 è la codifica che andremo ad utilizzare (dato l’elevato numero di caratteri rappresentabili) ma il discorso vale per qualsiasi codifica vogliate usare.

Innanzitutto è bene sapere che anche i linguaggi di programmazione hanno diversi modi di rappresentare e gestire i caratteri speciali. Ne consegue che ad ogni passaggio da db a linguaggio e da linguaggio a browser si debbano fare delle conversioni. A questo proposito esistono numerose funzione di encoding e decoding in php, js, ecc.

Questa operazione è macchinosa e non scalabile (ci si deve ricordare ogni volta di convertire tutti i dati in transito). L’approccio che presenterò in questo post è diverso: utilizziamo i caratteri speciali per come sono senza convertirli in nessun modo utilizzando solo qualche settaggio e molta attenzione.

Passiamo alla pratica

Innanzitutto è bene iniziare con il database. Nel nostro caso stiamo lavorando su mysql quindi ricordiamoci di creare il database sul quale lavoreremo con collation utf8_general_ci (o altri tipi di utf8), di settare lo stesso valore anche per:

• connessione mysql;
• ogni tabella creata;
• ogni campo testuale di ogni tabella.

Dopo questo passo sappiamo per certo che il database è pronto a gestire dati UTF-8.

Ovviamente dovremo ora comunicare con il database. Per questo esempio utilizzerò la libreria PEAR::MDB2 (consiglio a tutti di lavorare con qualche libreria e non a mano, per avere alcuni automatismi e funzionalità aggiuntive). Nel caso di MDB2 dovremo solo ricordarci di settare il charset sulla connessione al db al primo utilizzo, con il seguente metodo:

$mdb2->setCharset(‘utf8′);

Ora sappiamo che ogni comunicazione (lettura e scrittura) con il database avverrà utilizzando utf8.

Fase seguente è l’inserimento dei dati da parte dell’utente. Ovviamente, come detto sopra, se codifichiamo i dati che l’utente inserisce dovremo poi decodificarli ad ogni utilizzo. Noi non lo faremo. Lasciamo inserire all’utente ogni tipo di carattere (àé!’^$%…) e mettiamolo in database “senza toccarlo”, possiamo farlo perché le tabelle e la connessione in utf-8 ce lo permettono.

Fatto questo nel database avremo i caratteri veri e propri e sarà più facile gestire la fase di visualizzazione. Proprio quest’ultima di solito crea problemi di conversione, soprattutto quando si lavora con javascript che codifica i caratteri speciali in modo diverso dalle entità html.

In fase di visualizzazione dovremo assicurarci che le pagine html generate abbiano anche esse la codifica settata ad utf-8 con l’utilizzo del tag meta, in questo modo:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />

Il testo estratto dal database sarà quindi mostrato direttamente nella pagina che, usando charset utf-8, mostrerà i caratteri speciali senza problemi.

Lo stesso vale se questi dati vengono passati a funzioni javascript per elaborarli o mostrarli: non sarà necessario nessuna chiamata a funzioni di decodifica perché javascript è in grado di visualizzare i caratteri speciali se passati esplicitamente.

Prima di concludere è  importante dire qualcosa relativa al fatto di lasciare inserire all’utente tutti i caratteri che vuole. Questo potrebbe essere un baco di sicurezza per la possibilità di inserire codice malevolo o tentare sql injection. Dal punto di vista delle injection saremo protetti dalla libreria in uso (perciò dovreste usarne una) che si occuperà di gestire le query in ingresso al meglio con opportuni escape – quando necessari – e uso di altre protezioni. Ciò significa che non dovremo fare l’escape di caratteri potenzialmente pericolosi come apice singolo (‘) o doppio apice (“), né lasciarlo fare ad apache. Un escape di questo tipo richiederebbe, infatti, l’unescape al momento della lettura di tutti dati e non avremmo risolto niente.

Per evitare che apache faccia l’escape automatico settiamo nel file php.ini tutte le direttive relative a magic_quotes a Off. In particolare:

magic_quotes_gpc = Off

A questo punto l’ultima cosa che ci resta da fare è evitare che l’utente inserisca codice malevolo nel database. Questo possiamo realizzarlo tranquillamente con l’utilizzo della funzione strip_tags di php. Ad ogni query di inserimento chiamiamo questa funzione che pulirà il testo dai tag inseriti. In visualizzazione non dovremo fare nulla…che era proprio il nostro obiettivo.

Tags: Appunti > caratteri speciali > codifica > entità > html > javascript > mysql > php > Programming > utf-8

Uso Shadowbox ed ho problemi con <input type="text">

(No Ratings Yet)

 Loading ...

Posted by redsend | Filed under BugFix, Programming

Negli ultimi progetti che stavo sviluppando sono passato ad utilizzare Shadowbox, uno dei tanti framework per visualizzare immagini, filmati, pagine html e tanto altro all’interno della pagina stessa con una simpatica animazione. Se non avete capito di cosa sto parlando, forse non vi interesserà neanche quello che dirò dopo… In tutti i casi se volete un esempio di quello che può fare Shadowbox potete vedere i tanti esempi presenti a questo indirizzo: esempi shadowbox.

Ora che avete visto di cosa si tratta sicuramente vi siete accorti di aver già incontrato da qualche parte qualcosa del genere…

Bando alle ciance…

Mi sono trovato ad utilizzare Shadowbox per visualizzare alcuni campi di input in cui doveva venire digitato del testo. Tutto avveniva visualizzato correttamente, solo quando andavo a digitare del testo all’interno non veniva visualizzato niente. Provando a tenere premuti prolungatamente i tasti che volevo digitare mi veniva visualizzato qualcosa, ma ovviamente ripetuto più volte visto che lo avevo tenuto premuto più del dovuto.

Ci ho perso un bel pò di tempo, prima di arrivare a questa soluzione:

enableKeys: false

la riga che vedete sopra và inserita nelle opzioni con cui inizializzate Shadowbox (per info vedi qui).

Cosa succedeva? Perchè non funzionava?

Shadowbox fornisce anche delle scorciatoie da tastiera per poter eseguire delle operazioni, come: cambiare immagine durante la visualizzazione di una galleria, mettere in pausa un filmato, chiudere la finestra, etc…. Per fornire questa funzionalità viene catturato l’evento javascript “keypress” ed elaborato. La cattura di questo evento impedisce che alla prima pressione di un tasto quest’ultimo venga visualizzato nel campo input. La soluzione a questo problema non fà altro che disattivare la funzionalità delle scorciatoie da tastiera per effettuare operzioni e quindi funziona tutto normalmente.

Tags: html > javascript > problema > shadowbox