{"id":2291,"date":"2008-07-17T08:30:04","date_gmt":"2008-07-17T06:30:04","guid":{"rendered":"https:\/\/www.dreamsworld.it\/emanuele\/?p=2291"},"modified":"2016-05-17T11:06:20","modified_gmt":"2016-05-17T09:06:20","slug":"come-attivare-il-supporto-ssl-su-wordpress-26","status":"publish","type":"post","link":"https:\/\/www.dreamsworld.it\/emanuele\/2008-07-17\/come-attivare-il-supporto-ssl-su-wordpress-26\/","title":{"rendered":"Come attivare il supporto SSL su WordPress 2.6."},"content":{"rendered":"

\"LogoWordPress 2.6<\/a> include un supporto migliore<\/strong> per visitare la sezione di amministrazione via SSL<\/a>.<\/p>\n

Questa funzione ha bisogno che i cookie di autorizzazione<\/strong> siano inviati esclusivamente attraverso sessioni HTTPS<\/em> (cifrate<\/em>).
\nPer permettere questa possibilit\u00e0, lasciando la possibilit\u00e0<\/strong> di visitare il pannello di amministrazione tramite HTTP<\/em> (in chiaro<\/em>), WordPress 2.6 passa da un unico cookie ad una impostazione a 3 cookie<\/strong>.<\/p>\n

Nelle versioni precedenti WordPress impostava un cookie. Questo cookie era consegnato tramite tutte le pagine del blog<\/strong> 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<\/strong>. Se WordPress avesse continuato con un singolo cookie e l’avesse reso pi\u00f9 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\u00ec, WordPress non sarebbe stato in grado di mostrare le informazioni dello stato dell’utente corrente.<\/p>\n

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

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

define(\u2019FORCE_SSL_ADMIN\u2019, true);<\/pre>\n
Questo bloccher\u00e0 ogni accesso non-SSL al blog<\/strong>. Significa che non sar\u00e0 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<\/strong> che gli utenti scelgano se usare l’HTTP<\/em> o l’HTTPS<\/em> per visitare il pannello di amministrazione, \u00e8 necessario aggiungere questa riga al file wp-config.php<\/em>:<\/p>\n
define(\u2019FORCE_SSL_LOGIN\u2019, true);<\/pre>\n
Questo fa si che non tutti i cookie siano inviati via SSL<\/strong>. Gli utenti possono scegliere<\/strong> tra la sicurezza di una sessione HTTPS<\/em> e la velocit\u00e0 di una sessione HTTP<\/em>. Se si vuol evitare questa possibilit\u00e0 e forzare l’uso di sessioni HTTPS<\/em>, bisogna usare FORCE_SSL_ADMIN<\/em>.<\/p>\n
Con questi nuovi cookie sono necessarie delle nuove chiavi segrete<\/strong>. WordPress 2.5 ha introdotto una SECRET_KEY<\/em> 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\u00e0 necessario impostare le chiavi segrete per la sicurezza dei cookie<\/strong>. Se non intendete invece utilizzare il supporto SSL, \u00e8 sufficiente rimanere con la propria SECRET_KEY<\/em>. Ecco un esempio di come sarebbero le definizioni delle nuove chiavi segrete:<\/p>\n
define ( 'AUTH_KEY', 'metti qui la tua sequenza random');\r\ndefine ( 'SECURE_AUTH_KEY', 'metti qui la tua sequenza random');\r\ndefine ( 'LOGGED_IN_KEY', 'metti qui la tua sequenza random');<\/code><\/pre>\n
Dovreste cambiare questi esempi con sequenze di caratteri uniche<\/strong>, preferibilmente random. Ogni chiave dovrebbe essere diversa.  Per ricevere un set di chiavi random semplicemente da copiare ed incollare nel file wp-config.php<\/em> andate qui<\/a>. Ancora una volta, se non si si intende utilizzare l’SSL, si pu\u00f2 continuare ad usare la SECRET_KEY<\/em><\/strong> che si ha gi\u00e0 dalla versione 2.5 di WordPress.<\/p>\n
In linea di massima, tutto questo dovrebbe essere invisibile<\/strong> ai plugin ed ai temi. Ci sono per\u00f2 alcuni temi che inviano richieste POST<\/em> e AJAX<\/em> a file dentro la cartella dei temi. I cookie di autenticazione sono inviati solo<\/strong> per la cartella wp-admin<\/em> e quella wp-content\/plugins<\/em>, cos\u00ec i file aperti direttamente da wp-content\/themes<\/em> non vedranno il cookie<\/strong>. I temi dovrebbero inviare le loro richieste POST<\/em> e AJAX<\/em> tramite i file admin-post.php<\/em> e admin-ajax.php<\/em>. C’\u00e8 un piccolo articolo nel codex<\/a> su come i temi ed i plugin dovrebbero gestire<\/strong> le loro richieste POST<\/em> e AJAX<\/em>.<\/p>\n
I plugin potrebbero anche creare link che non sono prefissati correttamente con “https”<\/em>. Qualsiasi contenuto in una pagina cifrata deve arrivare<\/strong> attraverso un link HTTPS<\/em> per evitare gli avvisi del browser circa contenuti parzialmente cifrati<\/strong>. WordPress 2.6<\/em> introduce cinque nuove funzioni che si occupano di gestire il protocollo giusto<\/strong> quando si caricano CSS<\/em>, JavaScript<\/em> e altri file in una pagina di amministrazione cifrata. Queste funzioni sono: site_url()<\/em>, admin_url()<\/em>, includes_ur()<\/em>, plugins_url()<\/em>, e content_url()<\/em>. Ognuna accetta una path “relativa”<\/em> rispettivamente per i link site<\/em>, admin<\/em>, include<\/em>, plugins<\/em> e contents<\/em>. Per esempio per collegarsi a wp-content\/plugins\/foo\/foo.php<\/em> basta usare plugins_url(‘foo\/foo.php’)<\/em>. I plugin che caricano CSS<\/em> o JavaScript<\/em> tramite link relativi non hanno bisogno<\/strong> di usare queste funzioni. I link relativi utilizzeranno automaticamente<\/strong> il protocollo corretto.<\/p>\n
Emanuele<\/strong><\/p>\n
PS: libera traduzione di quanto scritto<\/a> da Rayn<\/em>, sviluppatore di WordPress, se doveste notare qualche inesattezza non esitate a segnalarmela. \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u00e0, lasciando la possibilit\u00e0 di visitare il … Leggi ancora →<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[4],"tags":[],"class_list":["post-2291","post","type-post","status-publish","format-standard","hentry","category-internet"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/posts\/2291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/comments?post=2291"}],"version-history":[{"count":0,"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/posts\/2291\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/media?parent=2291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/categories?post=2291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dreamsworld.it\/emanuele\/wp-json\/wp\/v2\/tags?post=2291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}