Recentemente mi è capitato di dover far puntare un dominio web ad un dominio diverso e renderlo trasparente (o quasi) all'utente...
Motivazioni
Esistono molti portali web che permettono a chiunque di creare siti web attraverso semplici wizard, cito per esempio..
- Wix - http://it.wix.com/
- Google Sites - https://sites.google.com/?pli=1
- Weebly - http://www.weebly.com
- WordPress - https://it.wordpress.com
associando normalmente un sotto dominio del portale oppure una sotto cartella dello spesso.
Per citare un esempio pratico, porto il caso del sito http://www.viaggiatoreda2soldi.it.
Creato con diversi portali le uri associate erano :
- con Wix:http://viaggiatoreda2soldi.wix.com/
- con Webbly: http://viaggiatoreda2soldi.weebly.com/
- con Google Sites: https://sites.google.com/site/viaggiatoreda2soldi/
ovviamente per motivi di SEO e pratici di comunicazione non sono propriamente consoni. Per risolvere questo problema, una volta acquistato il dominio www.viaggiatoreda2soldi.it si è creato un proxy sul web server ospitante il dominio, e per mantenere le URI delle pagine, si è utilizzato il modulo di RewriteRole di Apache Web Server. Si è scelto un proxy invece di un redirect per mantenere sulla barra degli indirizzi del browser, il dominio principale e non quello del sito del portale con cui lo si è creato.
Configurazioni
Utilizzando Apache Web Server, si è creato un virtual host ad hoc. Ipotizzando che il sito web sia stato creato sul portale Wix, di seguito la configurazione del virtual host
#Casching delle richieste su disco, tranne i cookie CacheIgnoreHeaders Set-Cookie CacheEnable disk / #Proxy con rewrite url P, QSA per gestire i parametri ProxyRequests On RewriteEngine On RewriteRule ^/(.*) http://viaggiatoreda2soldi.wix.com/$1 [P,QSA] #Logging per lo sviluppo RewriteLog /tmp/tmp_rewrite.log RewriteLogLevel 9 Quando si fa da proxy, è consigliabile utilizzare la cache (mod_cache) per rendere le risposte più veloci, in questo caso la configurazione prevede il salvataggio su disco e l'esclusione del salvataggio dei cookie.
Si è scelto di abilitare il proxy ed utilizzarlo attraverso il modulo RewriteRule, dopo averli abilitati (ed averli inclusi mod_proxy, mod_rewrite), utilizzarlo attraverso la configurazione P, nel dettaglio la riga :
RewriteRule ^/(.*) http://viaggiatoreda2soldi.wix.com/$1 [P,QSA]significa:
- per tutte le richieste www.viaggiatoreda2soldi.it/pagina contatta http://viaggiatoreda2soldi.wix.com/pagina
- quando contatti il sito remoto, usa la modalità proxy (P)
- se ci sono dei parametri, accoda anche quelli (QSA)
Il modulo RewriteRule è spesso usato per convertire uri poco chiare in vere uri parlanti per poter meglio indicizzare i siti nei motori di ricerca. Durante gli sviluppi è anche possibile aggiungere un log e settare il suo livello di verbosità.
Se è stato scelto il portale di google per la creazione del sito, il proxy deve fare le richieste in https, ecco come potrebbe essere il file di configurazione del virtual host
SSLProxyEngine On RequestHeader set Front-End-Https "On" ProxyRequests On RewriteEngine OnRewriteRule ^/site/viaggiatoreda2soldi/(.*) / RewriteRule ^/(.*) https://sites.google.com/site/viaggiatoreda2soldi/$1 [P,QSA] dopo aver incluso ed abilitato il modulo mod_ssl, poichè si usa un proxy, è necessario abilitare l'header della richiesta del protocollo https, che ingloberà la pagina richiesta. In questo esempio una ulteriore difficoltà (riscontrata solo in fase di sviluppo) è stata la sotto cartella richiamata dal portale (/site/viaggiatoreda2soldi/ ) e sempre inglobata nelle uri, pertanto si è deciso di fare due regole, una sul server e l'altra con il proxy.
Problemi di cookie ? Dopo esserti adeguato alla UE Cookie Law non funziona più?
Un cookie vien creato sul nome del dominio preso dal valore "Host" nell'header della chiamata HTTP, se a livello applicativo è stato creato sul dominio da sostituire, l'applicativo non funzionerà. Di norma nell'header finisce quello che sostituisce e non quello sostituito. Di seguito ecco come è possibile impostarlo.
RequestHeader set Host "viaggiatoreda2soldi.wix.com"
ProxyPreserveHost On
Conclusioni
La soluzione scelta potrebbe non essere ottimale in quanto si è riscontrato che facendo da proxy ed utilizzando come tecnologia la riscrittura delle uri delle pagine, di fatto i link all'interno delle pagine rimangono invariati con quelle del portale che ha creato il sito. Nel web 3.0 potrebbe non essere piacevole condividere la pagina su un social e vedersi la uri del portale invece del proprio dominio ufficiale.
Una prima soluzione potrebbe essere quella di fare delle sostituzioni nell'html della pagina sfruttando il proxy ed il modulo mod_substitute dal dominio del portale con quello ufficiale, aggiungendo la configurazione
Substitute "s|viaggiatoreda2soldi.wix.com|www.viaggiatoreda2soldi.it|i"
mah spesso non si risolve il problema, probabilmente per uno di questi motivi :
il framework che permette la condivisione è gestito dal provider che permette la creazione del sito e nelle configurazioni ha messo il suo dominio
la richiesta di condivisione parte dal client (normalmente si usa del javascript) e non essendoci il proxy di mezzo non vi è sostituzione.
Infine, per lo stesso scopo, spesso alcuni gestori di siti web propongono la soluzione "Frame forwarding" , una pagina html simile a questa :
<HTML><HEAD><TITLE>www.viaggiatoreda2soldi.it</TITLE></HEAD><FRAMESET ROWS="*,0"><FRAME SRC="http://viaggiatoreda2soldi.wix.com/" NORESIZE><NOFRAMES> Your browser does not support frames. </NOFRAMES></FRAMESET></HTML>ma molti browser, soprattutto degli smartphone, non supportano il frame tag e si rischia di non avere tutto il sito funzionante.