WordPress 2.6 include un supporto migliore per visitare la sezione di amministrazione via SSL.

Questa funzione ha bisogno che i cookie di autorizzazione siano inviati esclusivamente attraverso sessioni HTTPS (cifrate).
Per permettere questa possibilità, lasciando la possibilità di visitare il pannello di amministrazione tramite HTTP (in chiaro), WordPress 2.6 passa da un unico cookie ad una impostazione a 3 cookie.

Nelle versioni precedenti WordPress impostava un cookie. Questo cookie era consegnato tramite tutte le pagine del blog sia attraverso connessioni SSL che tramite connessioni in chiaro ed insicure. Era consegnato alla homepage del blog ed alle pagine di amministrazione. Fornire un cookie nelle pagine esterne di WordPress permette di mostrare, ad esempio, i link di logout per l’utente. Per supportare adeguatamente l’SSL, WordPress deve essere in grado di inviare il cookie di autenticazione esclusivamente attraverso sessioni SSL. Se WordPress avesse continuato con un singolo cookie e l’avesse reso più sicuro inviandolo solamente tramite sessioni SSL, quel cookie non avrebbe funzionato in homepage in quanto la maggior parte della gente non visita la propria homepage tramite SSL. Così, WordPress non sarebbe stato in grado di mostrare le informazioni dello stato dell’utente corrente.

Per porre rimedio a questo, WordPress 2.6, separa i cookie di “accesso” e “autenticazione”. Il cookie di accesso è inviato per tutte le pagine del blog attraverso sessioni SSL e non e non può essere usato per accedere alle pagine di amministrazione. Questo cookie indica semplicemente che uno specifico utente è connesso. Il cookie di accesso non può esser usato per effettuare modifiche al blog.

Il cookie di autenticazione, invece, è inviato solo per l’area di amministrazione e può essere usato per effettuare modifiche al blog. Se si effettua il login via HTTPS, il cookie di autenticazione sarà inviato solo per sessioni SSL. Se dunque si effettua il login via HTTPS e poi si visita il pannello di amministrazione tramite HTTP, sarà necessario effettuare un nuovo login per ricevere un cookie di autenticazione non-SSL. Di default, è possibile visitare la pagina di amministrazione sia via HTTP che HTTPS. Se si vuol far si che tutte le sessioni di amministrazione avvengano via HTTPS, è necessario aggiungere la seguente riga al file wp-config.php:

define(’FORCE_SSL_ADMIN’, true);

Questo bloccherà ogni accesso non-SSL al blog. Significa che non sarà mai inviato un cookie di autenticazione in chiaro. Se si vuole far si che i login avvengano via SSL per prevenire che il nome utente e la password vengano inviate in chiaro ma permettere che gli utenti scelgano se usare l’HTTP o l’HTTPS per visitare il pannello di amministrazione, è necessario aggiungere questa riga al file wp-config.php:

define(’FORCE_SSL_LOGIN’, true);

Questo fa si che non tutti i cookie siano inviati via SSL. Gli utenti possono scegliere tra la sicurezza di una sessione HTTPS e la velocità di una sessione HTTP. Se si vuol evitare questa possibilità e forzare l’uso di sessioni HTTPS, bisogna usare FORCE_SSL_ADMIN.

Con questi nuovi cookie sono necessarie delle nuove chiavi segrete. WordPress 2.5 ha introdotto una SECRET_KEY come mezzo per aggiungere un po’ di sicurezza aggiuntiva durante la creazione del cookie. Se si vuole usare il supporto SSL con la versione 2.6, sarà necessario impostare le chiavi segrete per la sicurezza dei cookie. Se non intendete invece utilizzare il supporto SSL, è sufficiente rimanere con la propria SECRET_KEY. Ecco un esempio di come sarebbero le definizioni delle nuove chiavi segrete:

define ( 'AUTH_KEY', 'metti qui la tua sequenza random');
define ( 'SECURE_AUTH_KEY', 'metti qui la tua sequenza random');
define ( 'LOGGED_IN_KEY', 'metti qui la tua sequenza random');

Dovreste cambiare questi esempi con sequenze di caratteri uniche, preferibilmente random. Ogni chiave dovrebbe essere diversa. Per ricevere un set di chiavi random semplicemente da copiare ed incollare nel file wp-config.php andate qui. Ancora una volta, se non si si intende utilizzare l’SSL, si può continuare ad usare la SECRET_KEY che si ha già dalla versione 2.5 di WordPress.

In linea di massima, tutto questo dovrebbe essere invisibile ai plugin ed ai temi. Ci sono però alcuni temi che inviano richieste POST e AJAX a file dentro la cartella dei temi. I cookie di autenticazione sono inviati solo per la cartella wp-admin e quella wp-content/plugins, così i file aperti direttamente da wp-content/themes non vedranno il cookie. I temi dovrebbero inviare le loro richieste POST e AJAX tramite i file admin-post.php e admin-ajax.php. C’è un piccolo articolo nel codex su come i temi ed i plugin dovrebbero gestire le loro richieste POST e AJAX.

I plugin potrebbero anche creare link che non sono prefissati correttamente con “https”. Qualsiasi contenuto in una pagina cifrata deve arrivare attraverso un link HTTPS per evitare gli avvisi del browser circa contenuti parzialmente cifrati. WordPress 2.6 introduce cinque nuove funzioni che si occupano di gestire il protocollo giusto quando si caricano CSS, JavaScript e altri file in una pagina di amministrazione cifrata. Queste funzioni sono: site_url(), admin_url(), includes_ur(), plugins_url(), e content_url(). Ognuna accetta una path “relativa” rispettivamente per i link site, admin, include, plugins e contents. Per esempio per collegarsi a wp-content/plugins/foo/foo.php basta usare plugins_url(‘foo/foo.php’). I plugin che caricano CSS o JavaScript tramite link relativi non hanno bisogno di usare queste funzioni. I link relativi utilizzeranno automaticamente il protocollo corretto.

Emanuele

PS: libera traduzione di quanto scritto da Rayn, sviluppatore di WordPress, se doveste notare qualche inesattezza non esitate a segnalarmela. 🙂