Archivi tag: mod_rewrite

Apache e mod_rewrite: redirect automatico per i dispositivi di tipo mobile

Scenario

Un sito Web, chiamiamolo per semplicità www.domain.com, che prevede due versioni: una per i desktop computer (e simili) e l’altra per i dispositivi mobile (smartphone, tablet, ecc.).

In particolare, i dispositivi mobile devono essere reindirizzati automaticamente su una landing page (choose.domain.com) e da questa pagina consentire all’utente di scegliere quale versione del sito visualizzare.

Soluzione

La soluzione da me implementata prevede l’identificazione dei client mobile (basata fondamentalmente sullo User Agent), il redirect degli stessi verso la landing page (mediante mod_rewrite) ed il settaggio di un cookie per “ricordare” la versione del sito che l’utente ha scelto di visualizzare (ovviamente fino a quando il cookie non scadrà o verrà rimosso volutamente dall’utente stesso).

mod_rewrite_logoMa bando alle ciance ed ecco la configurazione:

#Redirect per Iphone, Ipad, Android
 RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android" [NC]
 RewriteCond %{QUERY_STRING} !^full=true$ [NC]
 RewriteCond %{HTTP_COOKIE} !^.*full.*$ [NC]
 RewriteRule ^(.*)$ http://choose.domain.com [R=301,L]
RewriteCond %{QUERY_STRING} ^full=true$ [NC]
 RewriteCond %{HTTP_COOKIE} !^.*full.*$ [NC]
 RewriteRule .* - [co=full:true:.domain.com:7200:/]

Analizziamola direttiva per direttiva. Con:

RewriteCond %{HTTP_USER_AGENT} "iPhone|iPad|Android" [NC]

verifico che lo User Agent del visitatore contenga una delle keyword elencate (ed intervallate da semplici OR logici), ovvero iPhone, iPad ed Android.

Successivamente mi accerto che il link contattato dall’utente non contenga la querystring ?full=true

RewriteCond %{QUERY_STRING} !^full=true$ [NC]

il punto esclamativo (!) all’inizio della rewrite condition indica la negazione. Verifico inoltre che sul browser dell’utente non vi siano cookie contenenti la stringa full:

RewriteCond %{HTTP_COOKIE} !^.*full.*$ [NC]

Infine, se tutte e 3 le condizioni fin’ora elencate sono vere (le rewrite conditions elencate una dopo l’altra prevedono l’AND implicito), eseguo un redirect permanente (HTTP 301) sulla landing page:

RewriteRule ^(.*)$ http://choose.domain.com [R=301,L]

Nel caso in cui, invece, il link contattato dall’utente contenga la querystring ?full=true:

RewriteCond %{QUERY_STRING} ^full=true$ [NC]

ed il browser da egli utilizzato non presenti cookie che rechino la keyword full:

RewriteCond %{HTTP_COOKIE} !^.*full.*$ [NC]

salvo nel suddetto browser un cookie che ricordi la sua scelta, ovvero quella di visualizzare il sito in versione desktop (full), fino a quando il cookie stesso non sarà scaduto (dopo 7200 minuti, ovvero 5 giorni):

RewriteRule .* - [CO=full:true:.domain.com:7200:/]

dove la flag di mod_rewrite utilizzata è banalmente CO, la cui sentassi è la seguente:

[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly]

che ho utilizzato nella forma ridotta:

[CO=NAME:VALUE:DOMAIN:lifetime:path]

Infine, la flag [NC] utilizzata al termine di ciascuna rewrite condition, consente di non fare distinzione tra caratteri maiuscoli e minuscoli (NC, infatti, sta per NO CASE).

Per ora è tutto, alla prossima.

Apache mod_rewrite sui link generati da sarg

Recentemente ho avuto a che fare con uno scenario piuttosto complesso, in cui gli utenti della LAN riescono a navigare sul Web grazie all’intermediazione di un proxy, nella fattispecie di Squid.

Ora, per facilitare la vita ai net admin, esiste un tool particolare che si integra alla perfezione con Squid e permette di analizzare il traffico generato da ciascun utente, in modo da poter osservare eventuali comportamenti ambigui e monitorare le loro attività sul Web. Tale software prende il nome di sarg, acronimo di Squid Analysis Report Generator.

Fin qui tutto chiaro, peccato però che i vari utenti si autentichino al proxy sfruttando NTLM e che il proxy identifichi gli spazi presenti negli username con la notazione ASCII, ovvero con %20. Quindi, nel momento in cui clicco su un link generato da sarg, del tipo:

nome%20cognome

il server apache che mi risponde interpreta il %20 come uno spazio, ragion per cui anzichè provare ad aprirmi il link:

http://proxy.dominio.com/sarg/nome%20cognome

cercherà di visualizzare il link

http://proxy.dominio.com/sarg/nome cognome

rispondendomi picche. Come fare dunque per risolvere tale problematica? Semplice, sfruttando il mod_rewrite messo a disposizione da Apache.

In particolare, tale feature consente di modificare al volo le URL richieste dall’utente, permettendo la sostituzione del %20 con un backslash, il carattere di escape , il quale serve proprio ad indicare al Web server che il %20 va interpretato in modo letterale e non come uno spazio.

Ma passiamo ai fatti. Per prima cosa identifichiamo la directory in cui è installato sarg, che per la distro CentoOS 5.0 è /var/www/sarg.

Posizioniamoci ora nella directory relativa al file di configurazione di apache, ovvero /etc/httpd/conf ed apriamo tale file di configurazione (httpd.conf) in scrittura:

[root@proxy conf]# vi httpd.conf

Verifichiamo che sia presente la direttiva:

LoadModule rewrite_module modules/mod_rewrite.so

e che non sia commentata.

Adesso inseriamo le seguenti direttive per la directory in cui si trova sarg:

<Directory "/var/www/sarg">

Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

</Directory>

In realtà, quello che ci interessa è abilitare l’ovverride per la directory di sarg, in modo da consentire il corretto funzionamento del mod_rewrite.

Posizioniamoci adesso nella dir relativa a sarg e creiamo il file .htaccess:

[root@proxyint sarg]# vi .htaccess

e successivamente inseriamo all’interno del file le seguenti direttive:

RewriteEngine On

RewriteRule ([^ ]+) ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3%20$4 [R=301,L]

RewriteRule ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3 [R=301,L]

RewriteRule ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2 [R=301,L]

Adesso verifichiamo che il mod_rewrite funzioni correttamente. Per fare ciò creiamo una directory all’interno di /var/www/sarg e chiamiamola pro%20va:

[root@proxyint sarg]# mkdir pro%20va

Infine, proviamo ad accedere a tale directory mediante il nostro browser, digitando nella barra degli indirizzi la seguente URL:

http://proxy.dominio.com/sarg/pro%20va

Se il server Web vi risponde con un errore 404 (page not found), vuol dire che il mod_rewrite non sta funzionando. Viceversa, se la directory pro%20va è vuota ed il browser vi risponde con la pagina Index of /sarg/pro%20va, vuol dire che tutto sta funzionando alla perfezione (noterete anche la presenza nella URL del backslash codificato in ASCII, ovvero %25).

Da questo momento in poi, ogni volta che proverete ad accedere alle statistiche generate da sarg, verrete correttamente reindirizzati alla pagina che state cercando.

A presto.