Compago

...free knowledge

 
  • Increase font size
  • Default font size
  • Decrease font size
Home Manuali Utilità Aliases, Redirecting, e Rewriting con Apache

Aliases, Redirecting, e Rewriting con Apache

E-mail Stampa PDF

Sommario

Introduzione

Quando il web server Apache riceve una richiesta, solitamente il file di contenuto che viene fornito al client proviene da una directory predefinita (DocumentRoot). A volte però potrebbe capitare che i file di contenuto siano in una cartella diversa, per esempio, se si volesse mettere a disposizione degli utenti del sito alcuni documenti presenti nel server, sarebbe più conveniente non spostarli dalla loro posizione, piuttosto lasciarli dove stanno e fare in modo che il web server se li vada a prendere. Per fare questo tipo di cose abbiamo a disposizione tre tecniche:

  • Aliasing che "mappa" un determinato URL su una particolare directory.
  • Redirecting che "mappa" un URL su di un altro URL
  • Rewriting che usando il modulo using mod_rewrite altera in qualche modo l' URL.

Dove per mappare si intende collegare la richiesta di un URL ad un particolare contenuto.

Mappare una URL su di una directory

Problema
Vogliamo fornire dei contenuti presenti in una directoy che sta fuori dal DocumentRoot.

Soluzione

Alias /mio-prefisso /percorso/altra/directory


Spiegazione

In questo caso se un utente digita /mio-prefisso come URL gli verranno forniti i files che stanno nella directory /percorso/altra/directory.
Per esempio una richiesta come http://esempio.com/mio-prefisso/prova.html verrà fornito il file /path/to/other/directory/prova.html.

Questo stesso effetto lo potevamo ottenere creando un semplice link simbolico dalla main document directory alla cartella voluta e attivando le direttive Options +FollowSymLinks1
Comunque usando la funzione Alias si riesce più facilmente a tenere traccia delle directories e dei contenuti.

E' probabile che ci sia la necessità di configurare i permessi necessari per poter accedere alle directory tramite il web server, raccomandiamo quindi di consultare la documentazione relativa (http://httpd.apache.org/docs/misc/security_tips.html#protectserverfiles) per configurare Apache a vietare l'accesso a tutti di default, al di fuori della DocumentRoot directory. Dopo di che per sovrascrivere questa direttiva con i giusti permessi per la cartella in questione inserire il seguente blocco nel file di configurazione:


Order allow,deny
Allow from all

Questo consentirà l'accesso alla directory specificata.
Notare che il comando Alias prende in considerazione i simboli "/", infatti, se impostassimo la direttiva

Alias /prova/ /www/documenti/prova/

Gli indirizzi URL che iniziano con /prova/ verrebbero correttamente indirizzati, mentre quelli con la stringa /pprova no. Questo è un problema perché se l'utente digita http://esempio.com/prova avrebbe u errore del tipo 404, se invece digita http://esempio.com/prova/ con lo slash "/" finale invece verrebbe indirizzato all directory esatta.

Per evitare ciò basta creare un Aliases senza slash finali su entrambi gli argomenti.

Infine, assicurarsi che, se il primo argomento ha uno slash finale, allora lo deve avere anche il secondo. Per esempio:

 Alias /icons/ /usr/local/apache/icons

Una richiesta per http://esempio.com/icons/test.gif implica che Apache fornisca come contenuto il file /usr/local/apache/iconstest.gif piuttosto che quello che volevamo, cioè /usr/local/apache/icons/test.gif.

Note
[1] Vedi documentazione per le direttive opzionali http://httpd.apache.org/docs/mod/core.html#options.

Vedi anche
http://httpd.apache.org/docs/mod/mod_alias.html

Creare un nuovo URL per un contenuto preesistente

Problema
Vogliamo accedere tramite web server ad una directory preesistente usando un nome diverso.

Soluzione
Usare una direttiva Alias nel file di configurazione httpd.conf:

Alias /nuovourl /www/htdocs/vecchiourl

Spiegazione
Anche se la funzione Alias è usata solitamente per mappare un URL su una directory esterna alla DocumentRoot, questo non è affatto obbligatorio. Infatti ci sono molti casi in cui potremo volere accedere ad un contenuto ma con un nome diverso.
Come esempio potremo prendere il caso in cui il nome di una cartella del sito è stata modificato, ma io voglio che i miei utenti dall'esterno ci possano accedere usando sempre lo stesso nome. Quindi aggiungo un Alias che per una richiesta con il vecchio nome vada a reindirizzare al richiesta sulla nuova cartella.
bisogna ricordare che un Alias ha effetto solo sulla parte locale dell'URL (la parte /casa/mia.txt dell'intero indirizzo http://esempio.com/casa/mia.txt) e non ha effetto sulla parte hostname dell'URL (la parte http://esempio.com/ ). Per modificare o lavorare con questa dell'indirizzo URL, è necessario ricorrere alle altre funzioni Redirect o Rewrite.

Dare ad ogni utente un proprio URL

Problema
Vogliamo dare ad ogni utente del sistema un proprio spazio web.

Soluzione
Se vogliamo che i siti web degli utenti siano sotto la loro home directory, dobbiamo aggiungere questo la file di configurazione httpd.conf :

 UserDir public_html 

Oppure inserisci tutte le directory dei siti web degli utenti sotto una cartella principale:

UserDir /www/users/*/htdocs

Oppure se avete installato il modulo mod_perl potete anche fare qualcosa di più complicato, come il seguente script da aggiungere sempre al file httpd.conf:


my %forbid = map { $_ => 1 } qw(root postgres bob);
opendir H, '/home/';
my @dir = readdir(H);
closedir H;
foreach my $u (@dir) {
next if $u =~ m/^\./;
next if $forbid{$u};
if (-e "/home/$u/public_html") {
push @Alias, "/$u/", "/home/$u/public_html/";
}
}

Spiegazione
La prima soluzione è la più semplice e la più utilizzata. Con questa direttiva tutti gli utenti sul vostro sistema sono in grado di creare una cartella chiamata public_html nella loro home directory e metterci del contenuto web. Il loro spazio web sarà accessibile tramite URL iniziando la stringa con una tilde (~), seguita dal loro username.
Così, un utente chiamato pippo accederebbe al suo sito web personale con l'indirizzo http://www.esempio.com/~pippo/
Se Apache è stato installato da una distribuzione standard, il file di configurazione di default includerà degli esempio riguardanti questo argomento. Contiene anche una sezione  riguardante la cartella /home/*/public_html, con le varie opzioni e permessi abilitati. Se cene fosse il bisogno basta eliminare il segno di commento in modo da limitare l'accesso ai siti web. Un esempio di questa sezione potrebbe essere:


AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

Order allow,deny
Allow from all


Order deny,allow
Deny from all

Cercate di essere sicuri di qualsiasi direttiva abilitiate prima di procedere.

La seconda soluzione differisce nell'argomento della direttiva UserDir, perché gli viene passato come un percorso completo e non viene interpretato come come home directory dell'utente, ma come un particolare percorso.
Il simbolo * nel percorso è rimpiazzato dal nome utente. Per esempio, http://esempio.com/~rossi/ è tradotto come /www/users/rossi/htdocs. Questa struttura di cartelle ha bisogno comunque di essere configurata in maniera simile al precedente esempio.

La terza soluzione richiede il modulo mod_perl e fornisce un "mappaggio" alias per tutte le cartelle superiori sotto la gerarchia / home (solitamente le cartelle degli utenti). Differisce dalle altre soluzioni perché non include il simbolo tilde; quindi l'utente rossi avrebbe accesso al suo spazio web con http://esempio.com/rossi/ invece che con http://esempio.com/~rossi/ ma la posizione sul server del contenuto rimarrebe sempre /home/smith/public_html.
In ogni caso le cartelle in questione e il loro percorso devono poter essere leggibili da Apache (solitamente l'utente apache è identificato come nobody o www o httpd), così come i file in esse contenuti devono avere il permesso di essere eseguiti.
Ha bisogno del permesso di esecuzione anche l'elencazione dei file nella directory.
quindi per l'utente pippo, le cartelle "/","/home","/home/pippo" e "/home/pippo/public_html" hanno bisogno del permesso di esecuzione e l'ultima anche quello di lettura.
Per un sistema Unix, dovremo usare i seguenti comandi:

chmod o+x / /home /home/pippo
chmod o+rx /home/pippo/public_html

Per i permessi di lettura:

chmod 644 /home/pippo/public_html/*

Se usate la prima soluzione si dovrebbero impostare i permessi per molti utenti e solitamente si finisce sempre per consentire a tutti gli stessi permessi. Per questo motivo bisognerebbe informare i vari utenti di non mettere dei file personali in una cartella che chiunque dall'esterno potrebbe leggere, se le lo facessero che impostassero in maniera diversa i permessi di lettura

Il vantaggio di usare la seconda soluzione sta proprio nel fatto che i file dello spazio web starebbero in una cartella fuori dalla loro "home", con una sicurezza maggiore per i file personali.

L'ultima soluzione è completamente diversa e avendo installato il modulo mod_perl, consente di configurare Apache dinamicamente. Infatti, usando il contenitore all'interno del file di configurazione http.conf è possibile aggiungere le direttive in modo dinamico all'avvio del server.
All'avvio del server Apache, il codice riportato di sopra controlla la cartella /home/ e per tutti gli utenti che hanno una directory public_html crea un Alias specifico.
Il vantaggio rispetto alle precedenti è di non dover scrivere il simbolo "~" prima del nome utente, così che l'utente pippo per accedere al suo spazio web deve scrivere solo http://www.esempio.com/pippo/.
La lista %forbid in cima al codice fornito ci da un elenco di utenti per i quali è bene non creare l'alias, per motivi di sicurezza o altro.
Come negli esempi precedenti il codice dovrebbe anche essere accompagnato da una sezione che abilita all'accesso in lettura le cartelle /home/*/public_html.

Creare più Alias con una singola direttiva

Problema
Vogliamo mappare più URL su di una directory usando una sola direttiva.

Soluzione
Usare la funzione AliasMatch nel file di configurazione http.conf per avere una corrispondenza con una espressione regolare:

AliasMatch ^/pupp(y|ies) /www/docs/small_dogs

Spiegazione
La direttiva AliasMatch consente l'uso delle espressioni regolari per creare una corrispondenza tra URL e cartelle, permettendo una maggiore flessibilità. 
Nell'esempio precedente l'indirizzo che inizia con /puppy (es.www.esempio.com/puppy), oppure con /puppies, verrà diretto sul contenuto nella directory /www/docs/small_dogs.
Per avere informazioni riguardo l'uso delle espressioni regolari in Apache leggere il relativo articolo presente in questo sito.
In modo analogo funziona la direttiva ScriptAliasMatch al posto della classica AliasMatch, infatti con la direttiva:

ScriptAliasMatch ^/([sS]cripts?|cgi(-bin)?)/ /www/cgi-bin/

si riesce a mappare nella stessa cartella /www/cgi-bin/ tutte le richieste che iniziano con /script/, /scripts/, /Script/, /Scripts/, /cgi/, e /cgi-bin/, inoltre fa si che tutti i file presenti in questa cartella sia trattati come programmi CGI.

Un esempio un po' più complicato ma che aiuta a chiarire l'uso delle espressioni regolari:

AliasMatch (.*)/cod_(..)/(.*)/(.*).(html|htm|php) /var/www/sitoweb/mydep/$2/$4.$5

Vediamo di analizzare tutte le sue parti iniziando dall'espressione (.*) che sta per "tutte le possibili combinazioni di caratteri", dato che il punto indica un carattere qualsiasi e l'asterisco indica che può essere ripetuto zero o più volte, quindi l'alias entrerà in gioco quando come prima condizione incontrerà la combinazione /cod_ seguita da 2 caratteri (..).
Ricordare anche che le parentesi servono a considerare la parte della stringa in ingresso come una entità e che verrà memorizzata di volta in volta nelle variabili $1, $2, $3 etc... , quindi per esempio la variabile $1 conterrà tutto quello che viene trovato prima della serie di lettere /cod_ mentre $2 conterrà le due lettere consecutive alla suddetta sottostringa e così via.

(.*)/cod_(..)/(.*)/(.*).(html|htm|php)  
 $1       $2   $3   $4        $5

La condizione però non è ancora completa infatti occorre che la stringa in ingresso prosegua con uno "/" seguito da qualsiasi altra cosa, dopo di che un altro "/", ancora una serie indistinta di caratteri, che in teoria rappresentano il nome del documento html o php o htm e che troveremo memorizzato nella variabile $4, mentre le possibili estensioni sono elencate usando il separatore | che impone che solo una di essere debba essere presente per soddisfare la condizione ed infine queste sono anche racchiuse tra parentesi tonde in modo da conservare il valore trovato in $5.

Ora se tutta la condizione mostrata nella prima parte viene soddisfatta allora l'alias procede con l'instradamento della richiesta verso un preciso documento situato in una determinata directory identificata anche dalle parti della richiesta originaria.

La stringa finale manterrà sicuramente il nome ("$4.$5") le due lettere "(..)" indicheranno la sotto directory e la directory base la impostiamo direttamente "/var/www/sitoweb/mydep/".

Quindi, considerando come DocumentRoot "/var/www/sitoweb", e richiedessi questa pagina:

http://www.mywbesite.com/mydocumentatio/category/test.php?id=43&action=edit

non rispettando la condizione andrebbe a prendere il documento:

/var/www/sitoweb/mydocumentatio/category/test.php

Se invece l'url fosse:

http://www.mywbesite.com/mydocumentatio/cod_en/category/test.php?id=43&action=edit

rispetterebbe la condizione per l'alias e il documento richiesto sarebbe:

/var/www/sitoweb/mydep/en/test.php

La parte di query finale (?id=43&action=edit) in tutti i casi sarebbe invariata.

Creare una cartella CGI per ogni utente

Problema
Vorremo  che ogni utente avesse la propria directory CGI nella quale mettere i propri script piuttosto che dare a tutti accesso alla stessa cartella.

Soluzione
Inserire il seguente codice nel file di configurazione httpd.conf:


Options ExecCGI
SetHandler cgi-script

Spiegazione
Non si potrebbe usare la direttiva ScriptAlias perché per ogni utente il primo argomento da passare alla funzione sarebbe diverso per ogni utente. Anche usando ScriptAliasMatch sarebbe impossibile, dato che il secondo argomento deve essere uan stringa costante.
La soluzione proposta fa si che per ogni utente inserisca i propri scripts CGI nella proprio spazio web.
I file accessibili con indirizzo URL tipo:

http://www.example.com/~username/cgi-bin/

saranno trattati come scripts CGI.
Se avete abilitato suexec , i programmi CGI verranno eseguita dalla cartella target usando come utente quello specificato nell'URL. Per esempio se un utente accedesse al sito con http://www.esempio.com/~pippo/cgi-bin/esempio.cgi verrebbe eseguito come utente pippo.

Reindirizzamento(Redirecting) verso un altro indirizzo

Problema
Vogliamo che una particolare richiesta URL venga reindirizzata verso un altro server.

Soluzione

Usare la direttiva Redirect nel file di configurazione httpd.conf, e fornire un percorso assoluto(URL) come secondo argomento:

Redirect /esempio http://www.altro.server/nuova/posizione


Spiegazione

Mentre con la direttiva Alias viene mappato un indirizzo URL verso una cartella nel filesystem locale, con la direttiva Redirect viene mappato un URL verso un altro URL, solitamente su di un altro server.
Il secondo argomento è un URL completo e viene restituito al client (browser), il quale ne tiene conto facendo una seconda richiesta questa volta verso il nuovo indirizzo URL.
E' anche importante sapere che questa direttiva conserva le informazione del percorso iniziale. Infatti, per una richiesta del tipo http://primo.server/esempio/test.html si verrebbe rediretti alla pagina http://www.secondo.server/nuovo/posizione/test.html.
I reindirizzamenti possono essere anche selettivi, infatti inserendo alcune parole chiave, tra la direttiva e il suo primo argomento, si può selezionare un particolare tipo di redirect.
Tutti i reindirizzamenti hanno la funzione di informare il client della nuova posizione di un determinato contenuto; i tipi differenti di reindirizzamento però hanno la capacità di informare sulla posizione futura del contenuto.

  • temp
    Il reindirizzamento con temp è usato quando il documento non è al momento disponibile in quella posizione, ma è previsto che lo si possa trovare li in futuro. Così il client ricorda che l'URL usando nella richiesta originale e la riusa per una richiesta futura.
  • permanent
    Un reindirizzamento permanente indica che non solo non è più possibile trovare il documento nella posizione originale, ma il client non dovrebbe più cercarla li in futuro.
  • gone
    Questa parola chiave indica che un documento non più nella posizione originale e non dovrebbe più essere richiesto. Differisce da un errore del tipo 404 Not Found nel fatto che si ammette che un tempo il documento era in quella posizione e ora non più, e questo non è considerato un errore, diversamente dallo stato 404.
  • seeother
    questo tipo di redirect dice al client che il documento non esiste più nella posizione originale, ma che ora è possibile trovarlo modificato in una posizione diversa.
    Per esempio se io facessi una richiesta come http://esempio.com/capitolo2.html e il server mi rispondesse col redirect seeother verso un nuovo link http://miolibro.com/edizione-2/capitolo2.html questo significherebbe non solo che il contenuto richiesto ha cambiato posizione ma che il capitolo 2 cercato è stato rimpiazzato dalla sua seconda edizione.

Di default, se non è specificata nessuna parola chiave, il reindirizzamento viene inteso come temp.
Qui sotto potete trovare qualche esempio dei vari formati della direttiva, incluso il codice dello stato HTTP in caso voleste usare un documento di errore (ErrorDocument) per personalizzare la risposta del server:

# questo equivale ad una risposta con codice 302.
#
Redirect /foo.html http://esempio.com/under-construction/foo.html
Redirect temp /foo.html http://esempio.com/under-construction/foo.html
RedirectTemp /foo.html http://esempio.com/under-construction/foo.html
#
#questo equivale ad una risposta con codice 301
#
Redirect permanent /foo.html http://esempio.com/relocated/foo.html
RedirectPermanent /foo.html http://esempio.com/relocated/foo.html
#
# Questo dice all client che il vecchio URL non c'è più, ma
# è stato rimpiazzato con uno nuovo. Restituisce il codice 303
#
Redirect seeother /foo.html http://esempio.com/relocated/bar.html
#
# Restituisce il codice 410, dicendo al client che il documento è stato
# intenzionalmente rimosso e non sarà ripristinato.
# Notare che questo non è un absoluteURL.
#
Redirect gone /foo.html

 

Reindirizzare più URL verso lo stesso indirizzo

Problema
Vogliamo reindirizzare un certo tipo di richieste verso un unico indirizzo URL. Per esempio che le richieste per /pesca o /pesce siano reindirizzate verso http://pesca.esempio.com/.

Soluzione
Usare la funzione RedirectMatch nel file di configurazione httpd.conf per creare una corrispondenza con le espressioni regolari:

RedirectMatch ^/pesc[ae] http://pesce.esempio.com

Spiegazione
Questa soluzione permette al server di reindirizzare tutte le richieste che iniziano con /pesc seguite da una a o da una e verso l'indirizzo http://pesce.esempio.com. In questo modo le informazioni riguardanti il percorso verranno preservate, per cui se fosse richiesta la pagina http://vecchio.server/pesca/cernia.html il server reindirizzarebbe verso http://pesce.esempio.com/cernia.html.
Per avere informazioni riguardo l'uso delle espressioni regolari in Apache leggere il relativo articolo presente in questo sito.

Permittere gli URL Case-Insensitive

Problema
Vogliano che le richieste URL siano valide sia con le lettere maiuscole che con le lettere minuscole.

Soluzione

Usare il modulo mod_speling per far diventare gli URL case-insensitive:

CheckSpelling On


Spiegazione

Il modulo mod_speling fa parte della distribuzione standard di Apache ma non è abilitato di default, così è necessario abilitarlo esplicitamente.
Come vantaggi avremo anche che il server, grazie a questo modulo, aiuterà l'utente a trovare un indirizzo simile a quello richiesto, nel caso quest'ultimo non fosse disponibile ("not found" error).
Una volta che il modulo mod_speling è stato installato possiamo attivarlo su una singola directory oppure su un virtual host oppure sull'intero web server usando al direttiva CheckSpelling ON.

Sostituire una stringa nella richiesta URL

Problem
Vogliamo sostituire la stringa1 con la stringa2 in tutte le richieste URI.

Soluzione

RewriteCond %{REQUEST_URI} "stringa1"
RewriteRule "(.*)stringa1(.*)" "$1stringa2$2" [N,PT]

Spiegazione
L'opzione [N] significa che Apache deve riprocessare l'URL riscritto. Questo verrà ripetuto fino a che la condizione di rewrite (RewriteCond) non è più vera. In questo caso, quindi, finchè l'indirizzo conterrà la "stringa1" che voglio sostituire.
L'opzione [PT] fa si che il risultato della sostituzione venga ripreso da Apache per le successive elaborazioni della richiesta una volta che la riscrittura è terminata.

Riscrivere il percorso con argomenti CGI

Problema
Vogliamo inviare dei parametri per uno script CGI (CGI QUERY_STRING) come se fossero un indirizzo URL.

Soluzione

Per esempio potremo usare una regola di riscrittura in questa maniera:

RewriteEngine on
RewriteRule ^/libro/([^/]*)/([^/]*) /cgi-bin/libro.cgi?autore=$1&titolo=$2 [PT]

naturalmente questo è solo un esempio, ognuno dovrebbe personalizzarla per le proprie esigenze.

Spiegazione

Uno dei motivi per volere una cosa del genere è ad esempio avere un modo più semplice di inserire dei parametri nelle richieste URL. Infatti per un utente è molto più facile scrivere e ricordare un indirizzo così riscritto. Infatti, la regola di riscrittura dellìesempio di sopra permette di trasformare una richiesta del tipo http://www.esempio.com/libro/pippo/animali in http://www.esempio.com/cgi-bin/libro.cgi?autore=pippo&titolo=animali.
L'opzione [PT] nella direttiva indica ad Apache di continuare a processare la richiesta anche dopo averla modificata; senza questa opzione il web server tratterebbe l'URL richiesto come il nome di un file e non lo riconoscerebbe come uno script CGI che viene richiamato con i sui parametri. Permette inoltre a successive direttive RewriteRule di continuare eventuali modifiche al URL.
Se l' URL da riscrivere è stato già modificato come "query string", allora è necessario cambiare l'opzione [PT] con [QSA,PT], dove QSA sta per "query string add" e che implicherà l'aggiunta della stringa di query dell'URL originale  anche nel risultato finale.

Per maggiori informazioni leggere i seguenti documenti:
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://httpd.apache.org/docs/1.3/misc/rewriteguide.html
http://httpd.apache.org/docs/2.2/rewrite/

Vietare l'accesso a richieste non riferiti direttamente al sito

Problema
Vogliamo evitare che altri siti web usino nelle loro pagine le immagini (o altri tipi di documenti) presenti nel nostro sito.
Quindi le nostre immagini dovranno essere accessibili solo per le richieste dirette al nostro sito.

Soluzione

Inserire nel file di configurazione httpd.conf le seguenti direttive:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !=""
RewriteCond %{HTTP_REFERER} "!^http://miosito.com/.*$" [NC]
RewriteCond %{REQUEST_URI} "\.(jpg|gif|png)$"
RewriteRule .* - [F]

Spiegazione
Questa soluzione consiste in una serie di direttive RewriteCond, che controllano se il documento è una immagine (naturalmente potete specificare i tipi file che vi interessa proteggere) e se l'immagine è richiesta da un documento all'interno del vostro sito oppure se è incluso dentro la pagina residente.
Se tutto questo viene accertato allora un altro sito sta rubando le vostre immagini e va fermato.
La prima condizione verifica che il mittente sia specificato. Alcuni client non mandano informazioni sul mittente e alcuni browser possono essere configurati per non mandarlo.
Se noi negassimo tutti le richieste senza un mittente specificato, finiremo per negare un bel po di richieste valide; per questo motivo le lasciamo passare.
Per quelle che invece il mittente ce l'hanno dovremo controllare se il mittente arriva dal nostro sito o meno. Se vengono da un sito esterno continuo a controllare se il tipo di file richiesto è un file immagine.
Se il file non è un immagine, come per esempio un file HTML, allora permettiamo l'accesso da un sito esterno, ma se invece risultasse una immagine (nell'esempio di sopra sono considerate immagini solo i file .jpg, .gif e .png) allora tutte le condizioni sarebbero rispettate e la risposta alla richiesta sarebbe  un Forbidden (proibito) da parte del nostro server, usando l'opzione [F].

Riscrittura URI basandosi sulle query

Problema
vogliamo tradurre un URI in un altro basandosi sulla stringa di query del primo.

Soluzione

Inserire nel file di configurazione httpd.conf le seguenti direttive:

RewriteCond "%{QUERY_STRING}" "^user=([^=]*)"
RewriteRule "/utenti" "http://%1.utenti.esempio.com/" [R]

Spiegazione
La direttiva mod_rewrite non considera la stringa di query come parte del URI (Uniform Resource Identifiers) ai fini del matching e della riscrittura, per questo motivo abbiamo la necessità di occuparcene separatamente.
Nel esempio di sopra la richiesta http://esempio.com/utenti?user=pippo verrebbe tradotta in http://pippo.users.esempio.com/
L'opzione [R] fa in modo che il modulo mod_rewrite mandi il browser all URL costruito dalla direttiva RewriteRule.

Reindirizzare tutto o parte del vostro server verso SSL

Problema
Vogliamo che alcune parti del sito non-SSL sia reindirizzate verso l'area sicura.

Soluzione

Possiamo reindirizzare qualsiasi richiesta sulla porta 80 con la seguente direttiva:

RewriteCond "%{SERVER_PORT}" "^80$"
RewriteRule "^(.*)$" "https://%{SERVER_NAME}$1" [R,L]

Possiamo reindirizzare alcuni particolari URL verso l'area sicura:

RewriteRule "^/normale/sicuro(/.*)" "https://%{HTTP_HOST}$1" [R,L]

Possiamo controllare che la variabile HTTPS sia impostata:

RewriteCond %{HTTPS} !=on
RewriteRule "^(/sicuro/.*)" "https://%{HTTP_HOST}$1" [R,L]

Oppure, possiamo semplicemente usare la direttiva Redirect nella sezione http del file di configurazione httpd.conf affinchè la richiesta URL venga trattata come HTTPS:

Redirect / https://sicuro.esempio.com/

Siate sicuri che questa direttiva sia inclusa nella sezione http e non in quella https , altrimenti le richieste https avrebbero dei loop.

Spiegazione
La prima soluzione fa si che tutte le richieste sulla porta 80 (normalmente è la porta per le connessioni HTTP non criptate) siano reindirizzate verso lo stesso indirizzo sul server, ma con accesso SSL. Notare l'uso del SERVER_NAME; perché si tratta si un reindirizzamento completo.

La seconda soluzione fa si che tutte le parti del sito sotto l'indirizzo http://miohost/normale/sicuro devono essere reindirizzati verso l'area SSL all'indirizzo https://myhost/.

Notare che i percorsi SSL e quelli non-SSL sono diversi, per mantenerli modificandone solo l'http con https allora usate la terza soluzione.

 

Reindirizzare il dominio generico verso un sotto-dominio

Problema
Vogliamo che le richieste fatte al dominio esempio.org vengano reindirizzate verso www.esempio.org

Soluzione

Possiamo reindirizzare qualsiasi richiesta sul dominio generico verso il sottodominio con la seguente direttiva:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^esempio\.org(.*)$ [NC]
RewriteRule ^ http://www.esempio.org%1%{REQUEST_URI} [L,R=301]

Spiegazione
Come prima cosa attivo il modulo per l'operazione di reindirizzamento.
La seconda direttiva imposta la condizione per cui: se l'host richiesto (%{HTTP_HOST}) rispetta l'espressione regolare in cui non appare un sottodominio allora esegui il reindirizzamento dichiarato nella direttiva seguente. ([NC] sta per case insensitive, riferito al match dell'espressione regolare).
Infine la regola che aggiunge il sottodomino all'host richiesto.
Da notare che il pattern imposto è "^", cioè l'inizio dell'indirizzo da riscrivere; sarebbe più corretto se il pattern fosse stato ".*$", cioè tutta la stringa, ma data la clausola [R] finale, l'indirizzo verrebbe riscritto comunque.
Proprio perché l'indirizzo viene ricreato interamente occorre the quello nuovo sia completo "http://blahblah...". 
La clausola finale [L,R=301] sta per Last, cioè termina il processo di rewrite e forza i reindirizzamento fornendo un codice 301, ovvero il contenuto è stato spostato ad un altro indirizzo permanentemente.

Concludendo, faccio presente che ci potrebbero essere tante soluzioni per lo stesso problema.In questo caso le seguenti dichiarazioni sono equivalenti:

RewriteCond %{HTTP_HOST} ^(esempio\.org.*)$ [NC]
RewriteRule ^ http://www.%1%{REQUEST_URI} [L,R=301]

oppure

RewriteCond %{HTTP_HOST} ^(esempio\.org.*)$ [NC]
RewriteRule ^.*$ http://www.%1%{REQUEST_URI} [L,R=301]

o addirittura

RewriteCond %{HTTP_HOST} !^www\. [NC] 
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

dove si verifica che il sotto-dominio non inizia per www e solo allora esegue la sostituzione; questo va bene fino a quando non avete effettivamente altri sotto-domini, altrimenti potrebbe causare dei problemi.

Se volessimo fare il contrario, cioè inviare le richieste da www.esempio.org a esempio.org, allora potremo usare una regola di questo tipo:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]

Per dettagli sulla configurazione di Apache usando anche la stringa di query leggete questo.

Ultimo aggiornamento ( Mercoledì 07 Dicembre 2011 14:49 )  
Loading

Login




Chiudi