domenica 28 giugno 2009
Rewrite di caratteri con % nell'url, per link sbagliati
23:14 | 
Pubblicato da
Gordon Comstock
I Google Webmaster tools segnalavano qualche errore 404, con una serie di caratteri strani dopo la url corretta, rappresentati come di consueto in esadecimale preceduto dal simbolo di percento. Insomma, in questo modo:
URL del sito: abc.html
URL nei log: abc.html%20%B9
In pratica, qualcuno aveva linkato al sito aggiungendo per errore dei caratteri, o non chiudendo le virgolette del tag <a>. E naturalmente questo causava un 404.
Poco male, ho pensato: aggiungo un Redirect 301 e torna tutto a posto.
Niente da fare. Allora ho provato a fare unescape dei caratteri, perchè logicamente a Apache apparivano come caratteri, e non come sequenza di escape. Ma niente.
Okay, allora mod_rewrite. C'è un luogo che terrorizza tutte le Bene Gesserit -per me sono le rewrite rules. Ma se proprio devo lo faccio.
E ancora una volta, niente. Allora ho iniziato a cercare, qualcun altro avrà pure avuto lo stesso problema.
E alla fine ho trovato questo post: http://www.webmasterworld.com/forum92/3174.htm, la soluzione è nel penultimo messaggio.
La rewrite rule va applicata a {THE_REQUEST} che contiene ancora i caratteri in formato escaped. Grazie, Mr. Morgan!
URL del sito: abc.html
URL nei log: abc.html%20%B9
In pratica, qualcuno aveva linkato al sito aggiungendo per errore dei caratteri, o non chiudendo le virgolette del tag <a>. E naturalmente questo causava un 404.
Poco male, ho pensato: aggiungo un Redirect 301 e torna tutto a posto.
Niente da fare. Allora ho provato a fare unescape dei caratteri, perchè logicamente a Apache apparivano come caratteri, e non come sequenza di escape. Ma niente.
Okay, allora mod_rewrite. C'è un luogo che terrorizza tutte le Bene Gesserit -per me sono le rewrite rules. Ma se proprio devo lo faccio.
E ancora una volta, niente. Allora ho iniziato a cercare, qualcun altro avrà pure avuto lo stesso problema.
E alla fine ho trovato questo post: http://www.webmasterworld.com/forum92/3174.htm, la soluzione è nel penultimo messaggio.
La rewrite rule va applicata a {THE_REQUEST} che contiene ancora i caratteri in formato escaped. Grazie, Mr. Morgan!
Etichette:
domenica 21 giugno 2009
Php e accenti: caratteri strani nei form o da mysql. La codifica Utf8
Indipendentemente da quante volte l'avrò fatto, e ormai sono tante, ci casco sempre e mi scordo di convertire i caratteri dall'Utf8 a Unicode, o a entità HTML.
Il risultato sono lettere accentate che appaiono così: è
Il motivo è che il form, o magari il feed RSS o il database mysql dal quale arriva il testo hanno usato la codifica Utf8, mentre la pagina che le visualizza è in Unicode.
Quindi a futura memoria:
Che stampa correttamente 'è'. Possiamo fare un passo in più e scrivere:
Che invece di 'è' restituisce è ed è anche una saggia misura di sicurezza per evitare l'inserimento di HTML pericoloso. Soltanto, ricordiamoci di farlo prima di aggiungere i nostri tag html.
Ad esempio, se costruiamo una lista da un feed di twitter, all'interno del ciclo scriveremo qualcosa come:
invece di passare il risultato finale di $testo alle due funzioni. Perché a quel punto perderemmo gli '<li>' costruiti per ogni elemento.
Naturalmente, questo rallenta l'esecuzione perché sono necessarie tante chiamate a funzioni quanti sono gli elementi.
Il risultato sono lettere accentate che appaiono così: è
Il motivo è che il form, o magari il feed RSS o il database mysql dal quale arriva il testo hanno usato la codifica Utf8, mentre la pagina che le visualizza è in Unicode.
Quindi a futura memoria:
$stringa_da_ripulire='è';
utf8_decode ($stringa_da_ripulire);
Che stampa correttamente 'è'. Possiamo fare un passo in più e scrivere:
htmlentities (utf8_decode ($stringa_da_ripulire));
Che invece di 'è' restituisce è ed è anche una saggia misura di sicurezza per evitare l'inserimento di HTML pericoloso. Soltanto, ricordiamoci di farlo prima di aggiungere i nostri tag html.
Ad esempio, se costruiamo una lista da un feed di twitter, all'interno del ciclo scriveremo qualcosa come:
$testo.='<li>'.htmlentities (utf8_decode ($stringa_da_ripulire)).'</li>';
invece di passare il risultato finale di $testo alle due funzioni. Perché a quel punto perderemmo gli '<li>' costruiti per ogni elemento.
Naturalmente, questo rallenta l'esecuzione perché sono necessarie tante chiamate a funzioni quanti sono gli elementi.
sabato 20 giugno 2009
Problemi di permessi tra PHP e FTP
Se hai installato Wordpress, o Joomla, o magari scrivi i tuoi script PHP, ti sarà capitato di scontrarti con il problema dei permessi di scritture dei file.
CHMOD 755, cose del genere, su questo non scendo nei dettagli è pieno di tutorial e guide in proposito.
Il problema più comune è quando hai un server dove PHP gira -diciamo- come utente Nobody ma accedi ai file via ftp con il tuo acconto. I file creati dal PHP non puoi modificarli via FTP e viceversa perchè appartengono a utenti differenti .
O ti rassegni a cambiare i permessi entrando con l'utente root ogni volta, oppure rendi scrivibili i file da chiunque con un CHMOD 777, che è una falla di sicurezza grande come l'oceano atlantico.
Una semplice soluzione al problema è di mantenere distinti gli utenti, ma assegnare entrambi a un gruppo comune. In questo modo il tuo utente ftp condivide i permessi di gruppo, e può modificare o cancellare i file creati dal PHP.
Per fare questo, una volta ottenuti le credenziali di root scrivi:
Se vuoi sapere a quale gruppo appartiene l'utente, scrivi:
In pratica, diciamo che PHP gira come "nobody" e l'utente ftp è "addettoftp", con:
scopri il gruppo di nobody, probabilmente sempre nobody. Poi con:
Aggiungi a addettoftp un gruppo secondario di nobody, e puoi fare le modifiche che vuoi.
Potresti anche accorpare entrambi gli utenti in un gruppo comune, ma attenzione perchè l'utente del web server non è sicuro quanto il tuo utente ftp e non dovrebbe avere gli stessi previlegi.
NB, non sono un sistemista unix! Questo metodo funziona -ma come tutto in questo blog, lo pubblico come annotazione per me stesso, sperando sia utile anche ad altri. Commenti e correzioni sono benvenuti.
CHMOD 755, cose del genere, su questo non scendo nei dettagli è pieno di tutorial e guide in proposito.
Il problema più comune è quando hai un server dove PHP gira -diciamo- come utente Nobody ma accedi ai file via ftp con il tuo acconto. I file creati dal PHP non puoi modificarli via FTP e viceversa perchè appartengono a utenti differenti .
O ti rassegni a cambiare i permessi entrando con l'utente root ogni volta, oppure rendi scrivibili i file da chiunque con un CHMOD 777, che è una falla di sicurezza grande come l'oceano atlantico.
Una semplice soluzione al problema è di mantenere distinti gli utenti, ma assegnare entrambi a un gruppo comune. In questo modo il tuo utente ftp condivide i permessi di gruppo, e può modificare o cancellare i file creati dal PHP.
Per fare questo, una volta ottenuti le credenziali di root scrivi:
usermod -a -G nome_gruppo_php nome_utente_ftp
Se vuoi sapere a quale gruppo appartiene l'utente, scrivi:
groups nome_utente_php
In pratica, diciamo che PHP gira come "nobody" e l'utente ftp è "addettoftp", con:
groups nobody
scopri il gruppo di nobody, probabilmente sempre nobody. Poi con:
usermod -a -G nobody addettoftp
Aggiungi a addettoftp un gruppo secondario di nobody, e puoi fare le modifiche che vuoi.
Potresti anche accorpare entrambi gli utenti in un gruppo comune, ma attenzione perchè l'utente del web server non è sicuro quanto il tuo utente ftp e non dovrebbe avere gli stessi previlegi.
NB, non sono un sistemista unix! Questo metodo funziona -ma come tutto in questo blog, lo pubblico come annotazione per me stesso, sperando sia utile anche ad altri. Commenti e correzioni sono benvenuti.
Iscriviti a:
Post (Atom)
Feed RSS
Post
Tutti i commenti