SSL e cookie in WordPress 2.6

WordPress 2.6 include un ottimo supporto per utilizzare il lato amministrativo utilizzando SSL. Parte di questo supporto consiste nell’assicurarsi che i cookie di autorizzazione siano consegnati solo tramite sessione HTTPS codificate SSL. Per realizzare ciò permettendo comunque di utilizzare il lato amministrativo tramite una normale connessione http, 2.6 si sposta da una impostazione ad un solo cookie ad una impostazione a tre cookie.

Nelle precedenti versioni, WP impostava un solo cookie.  Questo cookie veniva consegnato a tutte le parti del vostro blog sia tramite una connessione sicura SSL che tramite una normale connessione insicura. Veniva consegnato dalla pagina principale del blog e dalle pagine amministrative. Consegnare un cookie dalla pagina principale permette a WP di visualizzare i link per la modifica in linea e quelli di logout per l’utente correntemente loggato. Per supportare correttamente SSL, WP necessita di della possibilità di limitare la consegna dell’auth cookie solo tramite sessioni sicure SSL. Se WP utilizzasse un solo cookie e lo consegnasse solo tramite connessioni sicure, questo cookie non verrebbe consegnato dalla pagina principale perché la maggior parte degli utenti non visita la pagina principale dei propri blog utilizzando SSL. Così che WP non sarebbe capace di visualizzare nella pagina principale le informazioni relative all’utente corrente.

Per porre rimedio a ciò, WordPress 2.6 imposta dei cookie separati per il “logged in” e l’“auth”. Il cookie di logged in viene consegnato da tutte le pagine del blog sia tramite sessioni SSL che sessioni non-SSL. il cookie logged in non può essere utilizzato per accedere al lato amministrtivo. Si limita solamente ad indicare che un particolare utente è loggato. Il cookie di logged in non può venir utilizzato per apportare delle modifiche al blog.

Per contro, il cookie auth, è consegnato solo dall’area amministrativa e può venir utilizzato per effetture modifiche al blog. Se si effettua il login tramite https, il cookie auth verrà consegnato solo per le sessioni SSL. Se si effettua il login tramite https e successivamente si svisita l’area amministrativa tramite una normale sessione http, si dovrà effetture nuovamente il login per ottenere un auth cookie non-SSL. Di base, si ha la possibilità di visitare il lato amministrativo sia tramite http che https. Se si desidera forzare tutte le sessioni amministrative tramite https, aggiungere la seguente riga al proprio wp-config.php:

define(’FORCE_SSL_ADMIN’, true);

Ciò previene i login non-SSL al proprio blog. Ciò significa che non si avrà mai un auth cookie consegnato in chiaro. Se si desidera forzare il login tramite SSL per impedire che i nomi utente e le passwords vengano inviate in chiaro permettendo però ai propri utenti di scegliere se utilizzare http o https quando visitano il lato amministrativo, aggiungere la seguente riga al file wp-config.php:

define(’FORCE_SSL_LOGIN’, true);

Ciò non forza la consegna di tutti i cookie tramite SSL. L’utentè ha la scelta fra una sessione https di grande sicurezza o fra una sessione http di grande velocità. Se si desidera rimuovere questa scelta e forzare solo sessioni https sicure, FORCE_SSL_ADMIN è l’opzione giusta.

Con questi nuovi cookie arrivano anche delle nuove chiavi segreteper firmarli. Come ricorderete WordPress 2.5 inrodusse SECRET_KEY con lo scopo di aggiungere una sicurezza ulteriore alla firma dei cookie. Se si desidera utilizzare il supporto SSL nella 2.6, si vorrò probabilmente definire delle chiavi segrete per i cookie sicuri. Se non si intende utilizare SSL, è possibile rimanere con SECRET_KEY esistente. Ecco un esempio che di come appaiono le definizioni delle nuove chiavi segrete:

define(’AUTH_KEY’, ‘put your unique phrase here’);
define(’SECURE_AUTH_KEY’, ‘put your unique phrase here’);
define(’LOGGED_IN_KEY’, ‘put your unique phrase here’);

Si dovrà ,modificare queste frasi di esempio con frasi univoche, possibilmente casuali. Ciascuna chiave dovrà avere frasi differenti. Visitando http://api.wordpress.org/secret-key/1.1/ si otterrò una serie di chiavi casuali che è possibile copiare ed incollare nel proprio wp-config.php. Ancora una volta, se non si intende utilizzare SSL, è possibile rimanere con la SECRET_KEY che già si utilizza.

Tutto questo dovrebbe essere per la maggior parte trasparente ai temi ed ai plugin. Dico maggiormente perchè vi sono alcuni temi che inviano richieste POST ed AJAX a file contenuti nella direcotry del tema. L’auth cookies viene consegnato solo ale directorieswp-admin e wp-content/plugins, quindi i file caricati direttamente da wp-content/themes non vedranno i cookie. I temi dovrebbero inviare le proprie richieste POST ed AJAX ai file admin-post.php o admin-ajax.php. Ho aggiunto un breve articolo a riguardo sul codex su come i temi ed i plugin dovrebbero gestire le richieste POST ed AJAX (in inglese).

I plugin potrebbero creare link che non sono correttamente prefissati con ‘https’. Qualsiasi contenuto caricato in un pagina sicura deve arrivare tramite un link https per evitare avvisi del browser riguardo a contenuti che sono solo parzialmente codificati. WordPress 2.6 introduce cinque nuove funzioni che si prendono cura di utilizzare il protocollo corretto quando si caricano CSS, JS ed altri file all’interno di una pagina amministrativa codificata-SSL. Esse sono site_url(), admin_url(), includes_ur(), plugins_url() e content_url(). Ciascuna funzione accetta un percorso relativo opzionale rispettivamente alle url del sito, del lato amministrativo, dei plugin ed dei contenuti. Ad esempio, un link a wp-content/plugins/foo/foo.php utilizzerà plugins_url(’foo/foo.php’).  I plugin che caricano CSS e JS tramite link relativi non necessitano di queste funzioni. I link relativi utilizzeranno automaticamente il protocollo corretto.

Se il vostro host supporta SSL, WordPress 2.6 permette di utilizzare tale supporto in maniera sicura. Divertitevi ed aiutateci a supportare sempre meglio SSL segnalando qualsiasi bug.