Aldolat.it — Post con tag Htaccess

La direttiva Order in Apache

aldolat@gmail.com (Aldo Latino) — Sun, 06 Aug 2023 10:25:24 +0200

Uno dei punti fondamentali¹ da comprendere per il controllo del proprio server Apache è la direttiva Order, quella in cui vediamo Allow,Deny o Deny,Allow. Non è di immediata comprensione ma, una volta capito il meccanismo che sta alla base, non dovrebbe risultare difficile applicarla con relativa semplicità.

Poniamo il caso che abbiamo queste direttive nel nostro file .htaccess:

<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Allow from foo.example.
</Directory>

Quello su cui questo post si concentra è la riga che inizia con Order. Questa direttiva dice ad Apache in quale ordine deve applicare le successive direttive Deny e Allow, vale a dire se prima l’una o l’altra. Nel caso in esempio, l’ordine è prima quelle Deny e poi quelle Allow. L’ordine è importante perché in Apache l’ultima direttiva ha priorità sulle precedenti.

Detta in modo semplice quelle righe significano:

nega (Deny) a tutti l’accesso alla directory /www;
permettilo (Allow) a chi proviene dall’indirizzo IP 192.168.0.100 e a chi abbia indirizzo IP che comincia con 123.456.;
permettilo (Allow) a chi proviene dal dominio example.org o da example.com;
permettilo (Allow) a chi proviene dal dominio foo.example. di qualsiasi TLD.

Se, invece, invertissimo l’ordine della direttiva Order da Order Deny,Allow a Order Allow,Deny, l’effetto sarebbe di bloccare tutti. Avremmo infatti che Apache leggerebbe così:

permetti l’accesso all’indirizzo IP 192.168.0.100 e a chi abbia…;
permetti l’accesso al dominio example.org…;
ecc…
nega a tutti l’accesso.

La regola finale avrebbe la prevalenza sulle precedenti, finendo così per bloccare tutti.

L’ordine con cui le direttive sono scritte nel blocco di codice non ha invece alcuna influenza.² Potremmo anche scriverle così:

<Directory "/www">
    Order Deny,Allow
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Deny from all
    Allow from foo.example.
</Directory>

In ogni caso Apache leggerà e applicherà in blocco prima tutte le direttive Deny e poi tutte quelle Allow. In linea generale, Jeff Starr³ consiglia di tenere queste due regole di base:

Quando si vogliono bloccare specifici indirizzi, usare Order Allow,Deny, quindi la direttiva Allow from all e a seguire le direttive Deny from .... Ad esempio:
```
<Directory "/www">
    Order Allow,Deny
    Allow from all
    Deny from 192.168.0.100
</Directory>
```
Quando si vogliono permettere specifici indirizzi, usare Order Deny,Allow, quindi la direttiva Deny from all e a seguire le direttive Allow from .... Ad esempio:
```
<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100
</Directory>
```

Bibliografia

The Apache Software Foundation, Apache Module mod_access_compat.
Ben Laurie – Peter Laurie, Apache: The Definitive Guide, O’Reilly & Associates, 2001.
Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023.

«Getting the order and syntax of these directives is critical to their operation». Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023, p. 123. ↩︎
«The order in which lines appear in the configuration files is not significant — all Allow lines are processed as one group, all Deny lines are considered as another, and the default state is considered by itself». Cfr. The Apache Software Foundation, Apache Module mod_access_compat, par. “Order Directive”. ↩︎
Jeff Starr, op. cit., p. 123. ↩︎

L'articolo La direttiva Order in Apache è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Reindirizzamenti con htaccess

aldolat@gmail.com (Aldo Latino) — Sun, 01 May 2022 10:18:47 +0200

Uno degli aspetti più intriganti che mi è capitato nella mia avventura di migrazione da WordPress a Hugo è quella dei reindirizzamenti dei post da un permalink a un altro.

Nella precedente installazione di WordPress la struttura dei permalink era la seguente:

https://www.aldolat.it/<ANNO>/<CATEGORIA>/<TITOLO-DEL-POST>/

In Hugo ho deciso di cambiarla togliendo <CATEGORIA>/ dall’indirizzo e premettendovi posts/:

https://www.aldolat.it/posts/<ANNO>/<TITOLO-DEL-POST>/

lasciando così la stessa struttura in cui sono organizzati file e directory nel mio filesystem.

Chiaramente questo significa che il vecchio indirizzo non funziona più e genera un errore 404. Ma è possibile intervenire con una regola nel file .htaccess piuttosto semplice. Eccola.

RedirectMatch 301 ^/(\d{4})/(.*)/(.*)/$ https://www.aldolat.it/posts/$1/$3

Questo è quello che fa la regola, la quale utilizza mod_alias, il sistema più semplice per reindizzare cose, rispetto a mod_rewrite, più potente ma un pelo più complesso:

RedirectMatch: attiva mod_alias per il reindirizzamento.
301: applica una stato HTTP di Moved Permanently.
^/(\d{4})/(.*)/(.*)/$: contiene la stringa da cercare. In questo caso si tratta di una regex che in sostanza dice questo: trova una stringa che inizia (^) con /(quattro numeri) e prosegue con due parti contenenti qualsiasi carattere e delimitate con slash (/) e queste due parti sono la parte finale della stringa ($). Fate attenzione alle parentesi tonde, in quanto queste saranno considerate da mod_alias come variabili che si possono usare per il reindirizzamento. Le variabili saranno numerate sequenzialmente da mod_alias a partire da 1.
https://www.aldolat.it/posts/$1/$3: reindirizza ciò che hai trovato all’indirizzo indicato, sostituendo le variabili $1 e $3 in questo modo:
1. $1: fa riferimento al primo gruppo di parentesi tonde, vale a dire (\d{4});
2. $3: fa riferimento al terzo gruppo di parentesi tonde, vale a dire (.*).

Il risultato sarà quindi che un indirizzo del tipo:

<https://www.aldolat.it/2012/news/htaccess-made-easy/>

verrà reindirizzato a:

<https://www.aldolat.it/posts/2012/htaccess-made-easy/>

L'articolo Reindirizzamenti con htaccess è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Redirigere la chiamata a file non esistenti

aldolat@gmail.com (Aldo Latino) — Sun, 15 Mar 2015 10:05:12 +0000

Restando in tema di file .htaccess, condivido con voi qualche modifica che ho introdotto recentemente dopo aver dato uno sguardo al registro degli errori del mio hosting provider. Tra le righe presenti notavo che si tentava si accedere ripetutamente al file favicon.ico sia cercandolo nella directory radice del sito (dove non è presente) sia in altre posizioni, nonostante la chiamata al file favicon.ico era correttamente generata nell’HTML dal tema in uso.

Per questo motivo ho aggiunto alcune righe in .htaccess, in modo da dirigere la ricerca del file in questione.

Il file favicon.ico

Ecco cosa ho aggiunto nel file di configurazione di Apache:

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/percorso/a/favicon\.ico [NC]
    RewriteCond %{REQUEST_URI} favicon\.ico [NC]
    RewriteRule .* http://www.example.com/percorso/a/favicon.ico [R=301,L]
</IfModule>

Queste righe fanno le seguenti operazioni:

controllare se è presente il modulo mod_rewrite in Apache;
attivare il motore di rewrite;
porre la prima condizione: l’URL richiesto non è quello del file favicon.ico corretto;
porre la seconda condizione: l’URL contiene la stringa favicon.ico;
avviare la regola: indirizza la richiesta alla posizione corretta e applica uno status HTML 301 “Moved permanently”.

Così, ad esempio, uno qualsiasi dei seguenti indirizzi:

http://www.example.com/files/favicon.ico
http://www.example.com/tag/apache/favicon.ico

viene indirizzato a:

http://www.example.com/percorso/a/favicon.ico

dove è presente fisicamente il file.

Altri file

Il file favicon.ico non è il solo ad essere vittima di questa ricerca errata, ma anche robots.txt, sitemap.xml e humans.txt. Possiamo quindi aggiungere anche queste righe, dove ogni blocco di righe si riferisce a uno specifico file:

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/robots\.txt [NC]
    RewriteCond %{REQUEST_URI} robots\.txt [NC]
    RewriteRule .* http://www.domain.tld/robots.txt [R=301,L]
</IfModule>
<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/sitemap\.xml [NC]
    RewriteCond %{REQUEST_URI} sitemap\.xml [NC]
    RewriteRule .* http://www.domain.tld/sitemap.xml [R=301,L]
</IfModule>
<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/humans\.txt [NC]
    RewriteCond %{REQUEST_URI} humans\.txt [NC]
    RewriteRule .* http://www.domain.tld/humans.txt [R=301,L]
</IfModule>

Potete trovare l’argomento spiegato più in dettaglio nel libro di Jeff Starr, .htaccess made easy, A practical guide for administrators, designers & developers, Perishable Press, 2013, di cui vi ho già parlato in questo precedente post.

Photo courtesy: peterstuartmill, Senza titolo, CC0 Public Domain.

L'articolo Redirigere la chiamata a file non esistenti è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Bloccare l’accesso al file wp-login.php

aldolat@gmail.com (Aldo Latino) — Sat, 31 Jan 2015 20:35:00 +0000

È da molti mesi che riscontro tentativi continui di accesso non autorizzato alla dashboard di WordPress: qualcuno/qualcosa tenta senza sosta di indovinare il nome utente dell’amministratore e della sua password. Me ne accorgo dalle segnalazioni che mi arrivano tramite il plugin Limit login attempts.

Il plugin, che pare non essere più mantenuto (e per questo motivo cerco un’alternativa), fa bene il suo lavoro ma, nonostante ciò, non è bello per me ricevere tutte quelle email giornaliere da parte sua. Per cui ho deciso di risolvere alla base il problema.

Negare l’accesso

Poiché l’azione che si tenta è quella di autenticarsi, la via di ingresso è il file wp-login.php: è sufficiente quindi bloccare l’accesso a questo file. Bloccare l’accesso al file significa, però, che neanche noi riusciremo a entrare nella dashboard di WordPress: dovremo quindi permettere l’accesso al nostro indirizzo IP.

Basta aggiungere poche righe al file .htaccess presente nella directory radice del proprio dominio:

<Files ~ "wp-login.php">
Order Deny,Allow
Deny from all
Allow from 12.
</Files>

Con queste righe stiamo dicendo ad Apache di bloccare l’accesso al file wp-login.php a tutti (Deny from all) tranne a coloro il cui indirizzo IP inizia con 12. (Allow from 12.). Chiaramente questo numero è quello che interessa a me, per cui dovete conoscere con quale range di indirizzi generalmente il vostro provider vi fa accedere ad Internet. Se avete un indirizzo IP statico, potete aggiungerlo per intero:

Allow from 123.123.123.123

A coloro il cui indirizzo IP non inizia con 12. o non è quello esatto che avete definito, Apache restituirà un errore 403 “Accesso negato”, che eventualmente potete anche personalizzare, se il vostro hosting provider ve lo permette.

Una volta messe in opera quelle righe, il log del server mostrerà qualcosa del genere:

[Sat Jan 31 02:10:30 2015] [error] [client 5.196.253.201] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 02:10:31 2015] [error] [client 5.196.253.201] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 02:32:18 2015] [error] [client 192.240.201.20] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 02:32:18 2015] [error] [client 192.240.201.20] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:02:45 2015] [error] [client 104.143.23.249] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:02:46 2015] [error] [client 104.143.23.249] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:28:20 2015] [error] [client 173.232.118.182] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:28:21 2015] [error] [client 173.232.118.182] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:29:33 2015] [error] [client 198.23.134.163] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:29:33 2015] [error] [client 198.23.134.163] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:33:08 2015] [error] [client 37.59.75.59] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:33:08 2015] [error] [client 37.59.75.59] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:36:43 2015] [error] [client 88.251.177.222] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php
[Sat Jan 31 03:39:33 2015] [error] [client 151.80.69.186] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/

con la conferma che Apache sta bloccando gli accessi (client denied by server configuration). E le email di Limit login attempts sono terminate.

I motori di ricerca

Per evitare errori di scansione dei motori di ricerca ho inserito nel file robots.txt due righe che evitino la scansione delle pagine legate all’autenticazione, ad esempio:

User-agent: *
Disallow: /wp-login.php
Disallow: /wp-login.php?action=register

Chiaramente quanto sopra forse non è la soluzione migliore al problema, ma devo dire che sta funzionando bene per me ed è di facilissima implementazione.

L'articolo Bloccare l’accesso al file wp-login.php è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

htaccess made easy

aldolat@gmail.com (Aldo Latino) — Mon, 24 Dec 2012 17:51:10 +0000

La copertina di .htaccess made easy.

Chiunque abbia un blog o un sito qualsiasi su un proprio dominio avrà avuto forse a che fare con il famigerato file .htaccess o quantomeno ne avrà sentito parlare. Questo file, di cui anche in questo blog qua e là si è parlato, è quello che permette di modificare la configurazione del proprio server a livello di singole directory. È talmente potente da permetterci tantissime operazioni sulle funzionalità di Apache e tutti possono trarre beneficio da semplici modifiche su un file di testo. Certamente è bene sapere cosa si sta facendo perché un solo carattere sbagliato potrebbe mandare in errore un intero dominio. Le pubblicazioni in merito non mancano, ma ve ne voglio segnalare una in particolare.

.htaccess made easy è l’ultima fatica di Jeff Starr, profondo conoscitore di Apache e — come già si saprà — anche di WordPress. Il suo libro, disponibile sia in versione PDF che su carta, copre tantissime circostanze in cui un amministratore potrebbe trovarsi: reindirizzamento, personalizzazione, ottimizzazione, sicurezza, SEO. È una guida pratica, da consultazione, da tenere a portata di mano. È scritto in inglese ma lo stile è semplice e graficamente accattivante, ricco di consigli e note a margine. Qualche giorno fa, ad esempio, dovevo rendere disponibile pubblicamente una directory su un dominio. Il server era configurato per negare il listing delle directory. È bastata una riga di .htaccess per farlo:

Options All +Indexes

Il libro è venduto dallo stesso Jeff in un suo sito dedicato e attualmente la versione digitale in PDF costa 20 dollari, anziché 25. Come dicevo è disponibile anche la versione stampata, in offerta attualmente al costo di 40 dollari.

Per vedere quali argomenti affronta, si può scaricare il PDF demo, che contiene tutto il sommario. Ecco alcun screenshot tratti da questo file:

Consigliato vivamente!

L'articolo htaccess made easy è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Aggiornare .htaccess al nuovo indirizzo di FeedBurner

aldolat@gmail.com (Aldo Latino) — Fri, 23 Jan 2009 09:40:15 +0000

I feed principali di questo blog sono gestiti da FeedBurner che, come saprete, è stata acquisita da Google. Proprio ieri, leggendo alcune pagine del servizio, mi sono ricordato che a breve tutti i feed sarebbero stati spostati verso il nuovo indirizzo, se non erro entro la fine di febbraio prossimo. Mi sono deciso dunque a trasferire subito i feed, visto che Google dava la possibilità di farlo. Il passaggio è stato assolutamente indolore: solo per un paio di feed ho atteso qualche minuto in più perché essi fossero di nuovo raggiungibili.

In questo passaggio ho dovuto aggiornare anche alcune regole presenti nel mio .htaccess, in particolare quella che mi reindirizza le richieste di abbonamento ai feed verso FeedBurner e quella che mi protegge dall’hotlinking. Vi riporto le modifiche eseguite perché magari vi può tornare utile.

FeedBurner

L’URL di FeedBurner cambia: dal vecchio http://feeds.feedburner.com si passa a http://feeds2.feedburner.com seguito dal nome scelto per il feed. Se usate .htaccess per reindirizzare i feed, cambiate le righe relative. Ecco un esempio di un blocco di regole:

### INIZIA REDIRECT DEI FEED DI WORDPRESS VERSO FEEDBURNER ###
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]
## POSTS
RewriteRule ^feed/*$ http://feeds2.feedburner.com/miei-articoli [L,NC,R=302]
## COMMENTI
RewriteRule ^comments/feed/*$ http://feeds2.feedburner.com/miei-commenti [L,NC,R=302]
## TAG
RewriteRule ^tag/mio-tag/feed/*$ http://feeds2.feedburner.com/mio-tag [L,NC,R=302]
## CATEGORIE
RewriteRule ^category/mia-categoria/feed/*$ http://feeds2.feedburner.com/mia-categoria [L,NC,R=302]
</IfModule>
### FINISCE REDIRECT DEI FEED DI WORDPRESS VERSO FEEDBURNER ###

Rispetto a quanto scrissi tempo fa, ho apportato qualche piccola modifica. Anzitutto ho riunito le due righe di esclusione dal redirect dello stesso servizio FeedBurner (riga 4). Poi, alle righe 6, 8, 10 e 12 notate il nuovo indirizzo cui redirigere chi si abbona. Ho infine aggiunto un esempio su come reindirizzare chi si volesse abbonare a un vostro particolare tag oppure a una delle categorie. Occhio a personalizzare correttamente l’URL del vostro feed originale (quello di sinistra) con l’URL del feed corrispondente su FeedBurner. Penso non ci siano dubbi su come farlo. 🙂

Hotlinking

Anche qui, se avete implementato questa preziosa regola, dovete intervenire. Se avete usato il mio precedente suggerimento, cambiate queste righe

RewriteCond %{HTTP_REFERER} !^http://www.feedburner.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://feeds.feedburner.com/vostro-nick$ [NC]

con queste

RewriteCond %{HTTP_REFERER} !^http://www.feedburner.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://feedburner.google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://feeds2.feedburner.com/.*$ [NC]

Vi riporto un esempio completo di regola di hotlinking, in modo da fugare dubbi su come scriverle:

### INIZIA PROTEZIONE HOTLINK ###
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} .(gif|jpe?g?|png)$                     [NC]
# Sostituire mio-dominio con il proprio dominio (solo il nome senza estensione)
RewriteCond %{HTTP_REFERER} !^https?://([^.]+.)?mio-dominio.           [NC]

# Permette a  FeedBurner di accedere alle immagini
RewriteCond %{HTTP_REFERER} !^http://www.feedburner.com/.*$            [NC]
RewriteCond %{HTTP_REFERER} !^http://feedburner.google.com/.*$         [NC]
RewriteCond %{HTTP_REFERER} !^http://feeds2.feedburner.com/.*$         [NC]

# Permette a Google Reader di accedere alle immagini
RewriteCond %{HTTP_REFERER} !^http://www.google.com/reader/view/.*$    [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com/reader/m/view/.*$  [NC]

# Permette ai motori di ricerca di accedere alle immagini
RewriteCond %{HTTP_REFERER} !search?q=cache                            [NC]
RewriteCond %{HTTP_REFERER} !google.                                   [NC]
RewriteCond %{HTTP_REFERER} !yahoo.                                    [NC]

# Permette che solo questa immagine venga visualizzata
# (modificare l'indirizzo sottostante con quello corretto)
RewriteCond %{REQUEST_URI}  !^/percorso-a/mia-immagine.png$            [NC]

# Decommentare la riga 32 se non si vuole far visualizzare nulla
# e commentare la riga 38
# RewriteRule .(gif|jpe?g?|png)$ -                                 [F,NC,L]

# Oppure se si vuole far visualizzare una immagine,
# inserire qui il link (quella inserita nella regola col Request_URI)
# oppure ancora se si preferisce reindirizzare a una immagine esterna al proprio spazio
# inserirne il link
RewriteRule .(gif|jpe?g?|png)$ http://www.mio-dominio.it/percorso-a/mia-immagine.png [R,NC,L]
</ifModule>
### FINISCE PROTEZIONE HOTLINK ###

Ho commentato tra le righe i vari passaggi che penso siano chiari. Per verificare che la protezione dall’hotlinking funzioni a dovere, recatevi qui e inserite nel campo apposito l’URL di una delle immagini che avete nel vostro blog. Prima di premere su “Check Link” svuotate la cache del browser, altrimenti vedrete l’immagine prelevata dal vostro disco.

L'articolo Aggiornare .htaccess al nuovo indirizzo di FeedBurner è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

3 funzioni per WordPress senza l’uso di alcun plugin

aldolat@gmail.com (Aldo Latino) — Fri, 02 Jan 2009 11:48:30 +0000

WordPress, splendida piattaforma open source orientata al blogging, consente di estenderne le potenzialità installando plugin per uno specifico scopo. Installare un plugin è spesso l’unica soluzione per poter avere una particolare funzione, necessaria nel nostro blog; ma in tanti casi è sufficiente mettere mano al codice del nostro tema per poter implementare la stessa identica funzione senza installare nulla di aggiuntivo (come ho più volte scritto: qui, qui e qui). Ecco 3 esempi.

Visualizzare data e ora dell’ultima modifica

Credo sia utile per i nostri lettori sapere se un articolo è stato modificato dalla loro ultima visita, specie se un blog tratta argomenti di natura tecnica. L’autore potrebbe commettere un errore nel riportare codice o altro, per cui il lettore saprebbe se l’articolo è stato rivisto o no.

Ecco il codice PHP che potete incollare nel punto del vostro tema dove volete appaia l’informazione (generalmente è utile nella sezione “postmetadata”. Da notare che l’informazione apparirà soltanto se l’articolo è stato modificato.

<?php
  $x = get_the_time('U');
  $m = get_the_modified_time('U');
  if ($m != $x) {
    echo 'Ultima modifica: '; the_modified_time('j F Y H,i');
  }
?>

Le righe 2 e 3 interrogano il database sulle due date di creazione e modifica dell’articolo e le assegna a due variabili. La riga 4 controlla se le due date sono diverse; se sono diverse, visualizzerà la riga 5.

Visualizzare citazioni a caso

Se vi piace poter visualizzare alcune citazioni nel vostro sito, scelte a caso tra una serie preimpostata, allora queste poche righe vi saranno utili.

Create un file di puro testo dove inserire le vostre citazioni. Scrivete una citazione in ogni riga, ad esempio:

Citazione 1
Citazione 2
Citazione 3
e così via...

La funzione, infatti, preleverà a caso una di queste righe e le mostrerà nella pagina. Salvato il file, caricatelo via FTP nel vostro server.

Ora copiate queste righe:

<?php
$file  = "http://www.example.com/citazioni/citazioni.txt";
$quote = file($file);
echo $quote[array_rand($quote)];
?>

e prima di incollarle, modificate il valore della variabile $file alla riga 2, mettendo l’URL corretto che punta al file di testo. Incollate le righe di codice nel file del tema dove volete che appaiano le citazioni (generalmente l’header.php o sidebar.php o footer.php), salvatelo e provatelo.

Redirigere i propri feeds su FeedBurner

Attenzione! L’URL di FeedBurner è cambiato! Leggi questo post in cui scrivo anche come adattare .htaccess.

Se volete delegare FeedBurner per la gestione del vostro feed WordPress, potete utilizzare il plugin ufficiale FeedSmith (che ho usato anch’io fino a qualche tempo fa), oppure potete evitarlo modificando il vostro file .htaccess, che, come sapete, fornisce istruzioni locali al server Apache.

Ecco il codice:

### INIZIA IL REDIRECT DEL FEED WORDPRESS VERSO FEEDBURNER ###
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
  RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
  # ARTICOLI
  RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/miofeed1 [R=302,NC,L]
  # COMMENTI
  RewriteRule ^comments/feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/miofeed2 [R=302,NC,L]
  ### FINISCE IL REDIRECT DEL FEED WORDPRESS VERSO FEEDBURNER ###
</IfModule>

Assicuratevi di modificare nelle righe 7 e 9 la dicitura miofeed1 e miofeed2 con il nome corretto che avete creato in FeedBurner. Con queste regole, delegherete FeedBurner per la gestione dei feed degli articoli e dei commenti. Se non volete redirezionare il feed dei commenti, potete eliminare (o commentare con un # ad inizio riga) le righe 8 e 9.

Fonte: Perishable Press, con qualche modifica alle righe di codice.

L'articolo 3 funzioni per WordPress senza l’uso di alcun plugin è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

WordPress e htaccess

aldolat@gmail.com (Aldo Latino) — Fri, 22 Aug 2008 14:58:36 +0000

Sto cominciando ad interessarmi ad htaccess che, come sapete, consente di impostare le regole per l’accesso alle directory presenti nel proprio spazio sul server web. Se volete, ad esempio, impedire momentaneamente l’accesso ai file del vostro sito o volete impedire l’hotlinking delle vostre immagini o volete impedire l’accesso a chi proviene da un particolare sito che vi linka… potete farlo impostando le regole specifiche nel file .htaccess presente (si spera) nella root del vostro blog/sito. Sono tantissime le cose che potete impostare: qui me ne sono appuntate alcune che condivido con voi. Ovviamente per fare una determinata operazione si può scrivere una regola in un modo o in un altro: l’importante è ottenere lo stesso effetto.

È un argomento del tutto nuovo per me e, per questo, mi sono documentato un po’ in rete: ho trovato estremamente interessante il blog di Perishable, una vera miniera! Potete dare un’occhiata anche al tag htaccess dei miei bookmark su Delicious.

Il titolo di questo articolo, forse, non è appropriatissimo, visto che le regole che si impostano qui valgono per qualunque sito anche non gestito da questo CMS.

L’.htaccess di WordPress

Quando installiamo WordPress per la prima volta, dovremmo trovare automaticamente un nuovo file nella nostra root chiamato .htaccess, contenente le regole di base. Qualora non ci fosse (molto strano), WordPress ne genera uno se andiamo nella pagina Permalink del pannello di amministrazione e facciamo clic su Salva le modifiche, anche senza aver modificato nulla. WordPress, in questo caso:

se il file esiste, aggiunge le sue regole in coda;
se il file non esiste, ne genera uno.

Ecco le regole che imposta:

# BEGIN WordPress
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Impediamo l’hotlinking

L’hotlinking è, in parole dure, un furto di banda. Capita che qualche blogger sia interessato ad un nostro articolo e faccia copia e incolla dell’articolo, portandosi dietro anche il codice che linka ad una eventuale nostra immagine che risiede nel nostro server. In questo modo, quando si visualizza l’immagine nel suo blog, questa viene prelevata dal nostro sito, utilizzando dunque banda nostra.

Per impedire ciò aggiungiamo queste regole al file .htaccess:

### PROTEZIONE HOTLINK ###
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_REFERER}     !^$
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$ [NC]
  RewriteCond %{HTTP_REFERER}     !^https?://([^.]+\.)?dominio\. [NC]
  RewriteRule \.(gif|jpe?g?|png)$ - [F,NC,L]
</ifModule>

Vediamo cosa significano le righe:

La prima riga è un commento.
La seconda controlla che mod rewrite sia presente sul server.
La terza abilita il motore di rewrite.
La quarta permette le richieste di referer che non specifichino il file dell’immagine.
La quinta controlla che il file richiesto esista.
La sesta controlla quale sia la parte finale del file richiesto.
La settima permette le richieste provenienti da “dominio”.
L’ottava è l’azione da eseguire: dà un errore 403 se viene richiesto uno dei file elencati.
La nona chiude il processo.

Queste righe possono essere aggiunte al file .htaccess che già avete nella vostra root. Ovviamente, sostituite “dominio” con quello vostro. Ad esempio, se il vostro sito si trova a http://www.miosito.it, dovrete inserire solo “miosito” al posto di “dominio”. Potete anche aggiungere altre estensioni oltre quelle già inserite: eventualmente modificate sia la 6a che la 8a riga. Per fare una prova se avete inserito correttamente le regole, potete andare qui e inserire l’indirizzo di una immagine presente nel vostro sito. Prima di premere il pulsante, però, svuotate la cache del browser, altrimenti vedrete ugualmente l’immagine, perché il browser la preleva da lì.

Se invece di servire un errore 403 volete far visualizzare una immagine specifica, sostituite la riga n. 8 con queste due:

RewriteCond %{REQUEST_URI} !^/hotlink\.jpg$ [NC]
RewriteRule \.(gif|jpe?g?|png)$ http://www.vostrosito/hotlink.jpg [R,NC,L]

cambiando /hotlink nella prima riga con la posizione dell’immagine da visualizzare e http://www.vostrosito/hotlink.jpg con l’URL dell’immagine desiderata.

Ecco un esempio di applicazione:

L’immagine originale a sinistra veniva prelevata direttamente dal mio spazio e, applicando queste regole, ecco cosa viene visualizzato al suo posto (immagine a destra).

Chiaramente, sta a voi usare con prudenza questo sistema, siate consapevoli di quello che fate e siate responsabili. Evitate di far visualizzare immagini che turbino la sensibilità di chi può commettere un errore e di chi visita il sito di chi l’errore lo compie.

Aggiunta di eccezioni

Ovviamente queste regole bloccano qualunque sito che prelevi le immagini dal vostro spazio, compresi servizi legittimi come Google Reader, FeedBurner, i motori di ricerca e magari il planet del vostro progetto opensource. Per evitare che ciò avvenga inseriamo le regole che consentano a specifici servizi di accedere ai file bloccati.

La riga di eccezione è questa:

RewriteCond %{HTTP_REFERER} !^url-sito$ [NC]

per cui basta sostituire url-sito con la URL e avrete finito. Eccovi alcuni esempi:

FeedBurner

RewriteCond %{HTTP_REFERER} !^http://www.feedburner.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://feeds.feedburner.com/vostro-nick$ [NC]

Google Reader

RewriteCond %{HTTP_REFERER} !^http://www.google.com/reader/view/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com/reader/m/view/.*$ [NC]

Motori di ricerca

RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !yahoo\. [NC]

Con questo sistema potete inserire tutti i siti che vi interessano. Ad esempio, la riga di eccezione per il planet di ubuntu-it potrebbe essere così:

RewriteCond %{HTTP_REFERER}  !^https?://([^.]+\.)?planet.ubuntu-it\. [NC]

Le righe vanno inserite dopo la 7a, cioè sotto al primo referer abilitato (cioè il vostro sito).

Reindirizzamento temporaneo

Potrebbe tornarci utile redirigere il traffico entrante, anche solo momentaneamente, verso una pagina ben precisa del nostro sito o verso una pagina esterna. Ad esempio, se stiamo facendo lavori di manutenzione sul sito e non vogliamo renderlo disponibile, possiamo inserire una regola temporanea nell’.htaccess, per poi toglierla (o commentarla) quando avremo finito. Lo stesso risultato può ottenersi comodamente con un plugin, ma credo che con questo sistema si soddisfi di più il nostro desiderio di capire come funzioni un servizio web. L’essere o mostrarsi più geek non centra nulla qui: penso sia più istruttivo mettere mano con competenza e serietà ad htaccess che usare un plugin che dovrebbe ottenere lo stesso effetto.

Ecco la regola:

### REINDIRIZZAMENTO TEMPORANEO ###
<Limit GET POST PUT>
  order deny,allow
  deny from all
## AGGIORNARE IL SEGUENTE NUMERO IP CON QUELLO ATTUALMENTE VOSTRO!! ##
  allow from 123.45.6.789
</LIMIT>
ErrorDocument 403 /vostro-file.html
<Files vostro-file.html>
  order allow,deny
  allow from all
</Files>

Attenzione alle righe da sostituire: quella col numero IP del vostro PC e del file html (2 volte) dove volete siano reindirizzati i vostri visitatori.

Reindirizzamento per chi proviene da un particolare dominio

Se per un motivo qualsiasi non vogliamo ricevere visite indirizzateci da un particolare dominio, possiamo aggiungere questa regola:

### REINDIRIZZAMENTO PER CHI PROVIENE DA UN DOMINIO ###
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} .*dominio.it.*
  RewriteRule (.*) http://www.dominio.com [R=301,L]
</IfModule>

Sostituite dominio.it con il dominio di chi vi linka e http://www.dominio.com con l’URL del sito dove volete reindirizzare chi arriva a voi da quel sito.

Anche in questo caso, usate con prudenza il reindirizzamento, siate consapevoli di quello che fate e siate responsabili. Evitate il reindirizzamento a siti che turbino la sensibilità di chi vi visita.

Se avete intenzione di inserire regole per htaccess nei commenti a questo articolo, credo che WordPress sostituirà alcuni caratteri. Usate un servizio Pastebin oppure discutiamone nel forum.

L'articolo WordPress e htaccess è uno scritto di aldolat.it. Rispettane le condizioni di licenza.