Drupal è un gran bel giocattolino, un framework ben fatto per costruire robusti portali assai versatili. Però quando hanno scritto il file .htaccess, si sono dimenticati di alcune cosine che prima o poi tornano utili….
Vediamo insieme come scrivere un file .htaccess che risolve i vari problemi che si incontrano nella realizzazione e nella messa online di un prodotto che usa Drupal.
I problemi che risolvo tramite regole in .htaccess sono 3:
- Protezione di cron.php da accessi esterni.
- Gestione dei 404 per alcuni tipi di file.
- Gestione dei limiti di memoria di PHP.
N°1 – cron.php è utile per effettuare le manutenzioni automatiche di Drupal, però tutti quelli che capiscono che si tratta di un Drupal possono eseguire il cron.php semplicemente chiamando www.mysite.com/cron.php. Questo introduce potenziali problemi di sicurezza, non è bello sapere che sconosciuti ti eseguono il cron……. :)
Questo il codice necessario:
<Files "cron.php"> Order Deny,Allow Deny from all Allow from localhost Allow from 127.0.0.1 Allow from 192.168.1.* <--- IP della tua rete </Files>
N°2 -Drupal fin dalla versione 4.6 ha un problema nella gestione della mancanza di alcuni tipi di file come .gif, .js, .jpg, .png .ico, etc… questo problema si palesa quando si usa il modulo customerror. Nel caso manchi un qualsiasi file nel template, anche una immagine di background dichiarata nel CSS, Drupal riconosce la mancanza di un file come una pagina 404. Questo è notevolmente seccante. Il tutto si risolve con una gestione a priori di questi errori. Se questo problema si presenta anche su altri file (.svg?) basta aggiungerlo!
Questo il codice che ho inserito:
<FilesMatch "\.(png|gif|jpe?g|s?html?|css|js|cgi|ico|swf|flv|dll)$">
ErrorDocument 404 "<html><head><title>404 Not Found</title>
</head><body><h1>Not Found</h1><p>The requested URL was not found on$
</FilesMatch>
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/files/
RewriteCond %{REQUEST_URI} \.(png|gif|jpe?g|s?html?|css|js|cgi|ico|swf|flv|dll)$
RewriteCond %{REQUEST_URI} !^404.%1$
RewriteRule ^(.*)$ 404.%1 [L]
# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
N°3 – Infine gestione di PHP. Drupal è un pò affamato di risorse, specialmente se usato con views belle complicate e se si utilizza le GD per resize di foto giganti (oltre 1600×1200). La richiesta minima è di 32Mb, in caso di GD bisogna portarlo ad almeno 96Mb. Queste impostazioni non sono quasi mai quelle di default, quindi dobbiamo andare a modificare (sovrascrivere dinamicamente) le impostazioni del php.ini. Nel caso si abbia un hosting su Aruba, non funziona il metodo .htaccess ma funziona quello di creare un php.ini nella root dell’installazione e inserendo i valori come se fosse il php.ini originale.
Il codice che si utilizza nell’htaccess è questo:
php_value max_execution_time 400 php_value max_input_time 400 php_value memory_limit 96M php_value upload_max_filesize 20M php_value post_max_size 25M
L’unico limite importante è il memory_limit, gli altri sono a vostra discrezione :)
Infine vi metto in allegato il file .htaccess completo per utilizzarlo con le vostre installazioni di Drupal. Io l’ho testato su Drupal 6.14. Ma non vedo perchè non dovrebbe funzionare anche sulle versioni successive della 6.x.
Tags: 404, 6.x, customerror, Drupal, errore, hosting, htaccess, website
[...] già discusso dell’htaccess di Drupal qui, tutte le regole impostate in quell’htaccess di esempio funzionano, ad eccezione dei php_set, [...]
Perché su Aruba non funziona con .htaccess ?
Ti risulta che in generale la modifica di drupal/.htaccess su Aruba sia problematica? In effetti io ho un sacco di rogne …
Grazie.
Andrea
Mi risulta che Aruba non consente di creare .htaccess con tanta disinvoltura….. io ho usato un metodo carogna…. ho utilizzato la funzione cartella con password di Aruba che trovi nel backend di admin.aruba.it. Lui ti genera un .htaccess e .htpasswd per quella funzione…. io ho aperto l’htaccess generato da Aruba e l’ho modificato a piacimento… funziona già meglio.
Per la sovrascrittura delle variabili del php.ini invece devi usare il metodo del file apposito nella root del sito.
In ogni caso Aruba e Drupal non mi sembrano molto adatti a convivere…. tipo il cron.php come fai a temporizzarlo sul crontab?
[...] su Come preparare un prodotto digitale per la stampa tipografica.Andrea Mancini su .htaccess fatti bene per Drupal 6Andrea su .htaccess fatti bene per Drupal 6Installare Drupal 6.x su OVH | Bisonte_biscottato su [...]
Buon giorno
Sono alla disperata ricerca di una soluzione dal momento che non ho mai utilizzato Drupal ma mi tocca fare la manutenzione di un sito internet fatto appunto con Drupal e pubblicato con Aruba. Da circa 1 mese non riesco piu’ a modificare o creare le pagine del sito usando l’interfaccio grafica semplificata del sito stesso, ovvero immettendo la username e password.
Per esempio ogni volta appunto che cerco di creare una pagina nuova mi torna l’avviso “Non disponete delle autorizzazioni per visualizzare questa pagina.” In parole povere ogni volta che faccio qualcosa è come se mi resettasse le permission.
Ho contattato Aruba che mi ha detto di inserire la stringa a:1:{s:5:”roles”;a:1:{i:0;s:1:”2″;}} nel tabella”users” e il record relativo alla login “admin” modificando l’ultima voce della riga “admin”, relativa alla colonna “data”.
Ma ho fatto notare che la stringa era già inserita. A questo punto mi hanno risposto che:
“Gentile cliente,
allo stato attaule i permessi dell’utente admin nella tabella users sono diverse da quelli presenti a fine Novembre.
Abbiamo eseguito un ulteriore test e in questo momento nemmeno inserendo abilitando tutti i permessi con la stringa:
a:0:{}
è possibile abilitare l’utente admin alla scrittura dei contenti.
Tutto questo, unitamente al fatto che il Drupal installato è molto datato, ci porta a pensare che la disabilitazione dei permessi e l’impossibilità a ripristinarli siano frutto di un attacco verso Drupal effettuato sfruttando le vulnerabilità di una versione non aggiornata.
Per una sua maggiore sicurezza la invitiamo ad effettuare un cambio della password di gestione inerente la login@aruba.it accedendo presso il nostro sito on line all’indirizzo
https://hosting.aruba.it/areaclienti/CambioPassword/CambioPassword_Richiesta.asp
La nuova Password deve mantenere i seguenti criteri:
- lunghezza compresa fra 8 e 13 caratteri;
- formato alfanumerico (deve quindi contenere sia lettere che numeri)
- diversa dalle password utilizzate in precedenza
Per cambiare le credenziali del MySQL, invece, faccia riferimento al seguente link:
http://kb.aruba.it/KB/a1111/cambio-password-database-mysql-e-ms-sql.aspx?KBSearchID=0
In merito alla problematica di Drupal, Le consigliamo di eliminare l’installazione attualmente presente e partire con una installazione ex-novo con l’ultima versione disponibile..
Rimaniamo a Sua disposizione per ulteriori chiarimenti.
A questo punto mi chiedo: cosa posso fare? Come dicono, in che modo posso eliminare l’installazione presente di Drupal e farne una nuova? A me sembra piuttosto che possa essere un problema con qualche file php (la versione usata è la Php5 5.2.16. Sinceramente son convinto non che c’entri Drupal in tutto questo.
Se prima il sito web funzionava correttamente escluderei un problema legato all’hosting e sarei orientato verso problemi di hacking o di corruzione di files o database. Escluderei la questione della PHP Version in quanto Drupal 6.x è garantito al 100% con la 5.2. Semmai ci sono piccoli problemi con la 5.3 ma solo con alcuni moduli esterni.
Le indicazioni che ti ha dato Aruba sono corrette e sono in sostanza il massimo dell’intervento possibile sul discorso Permessi e Ruoli.
La prova migliore è quella di scaricare tutto il sito web e tutto il database e montare tutto in un server web locale. Così da poter effettuare controlli più accurati e escludere al 100% problemi legati alle impostazioni dell’hosting.