Archives For Sviluppo Web

Qualcuno lo avrà certamente notato. Da qualche giorno questa installazione di WordPress è raggiungibile al suo “nuovo” URL in HTTPS. Dico “nuovo” perché da circa un anno avevo già forzato la Dashboard in HTTPS, lasciando ancora in HTTP il blog visibile pubblicamente a tutti i lettori. Il tutto ha potuto funzionare generando un certificato con Let’s Encrypt e chiedendo al supporto di Serverplan (l’hosting che ospita questo blog) di caricarlo.

WordPress: passaggio da HTTP a HTTPS 8

Qualche giorno fa, tutti i clienti del provider hanno però ricevuto una comunicazione decisamente più ufficiale:

[…]

Dopo un periodo di test, necessario per la tranquillità dei clienti, Serverplan ha attivato il certificato TLS gratuito Let’s Encrypt su tutti i piani Hosting. Cosa devi fare per attivare questo servizio? Niente, è già attivo. Devi solo goderti la tranquillità di una connessione sicura.

[…]

Ho quindi pensato fosse arrivato il momento giusto per portare tutto su HTTPS, anche perché Google sembrerebbe avere tutte le intenzioni di cominciare a penalizzare chi non passa alla connessione più sicura e che permette maggiore sicurezza nel caso in cui si debbano utilizzare delle credenziali di autenticazione (cosa che però qui sul blog non accade, poiché i commenti –unico login che potresti voler effettuare– vengono gestiti da Disqus, anch’esso passato a HTTPS).

Molti hosting provider oggi propongono un certificato di Let’s Encrypt in maniera semplice, attivabile direttamente dal proprio pannello di controllo oppure pre-attivato sul proprio spazio (quello che ha scelto di fare Serverplan, nda). Se nel tuo caso questo non è ancora possibile, sappi che puoi procedere in autonomia, creando il tuo certificato personale e chiedendo al supporto tecnico del tuo provider di attivarlo sul tuo sito web.

Creare un certificato Let’s Encrypt

Le linee guida per la richiesta e creazione di un certificato sono disponibili sul sito web ufficiale del progetto, all’indirizzo letsencrypt.org/getting-started. Per fartela più semplice, puoi passare dal sito web sslforfree.com, ti propongo la solita galleria esplicativa ma ti indico istruzioni più dettagliate subito di seguito, per evitare possibili errori:

  • Inserisci il sito web che vuoi certificare. Puoi specificare il dominio di secondo livello (tuodominio.tld), il sito web inserirà in maniera automatica il www davanti, per certificare anche il terzo livello.
  • Scegli di effettuare una verifica manuale tramite upload di file sul tuo spazio FTP (questo è quello che ti consiglio). Scarica i due file necessari alla verifica da sslforfree (fai clic su Download File #1 e Download File #2, scarica entrambi i file sul Desktop o equivalente, servono per poco tempo).
  • Vai sul tuo spazio FTP, crea una cartella chiamata .well-known, entra al suo interno e crea una nuova cartella chiamata acme-challenge. Carica entrambi i file che hai precedentemente scaricato all’interno di quest’ultima cartella.
  • Torna su sslforfree e procedi con la verifica, ti basterà fare clic su Download SSL Certificate e, salvo errori, potrai avere accesso al tuo set di chiavi. Fai clic su Download All SSL Certificate Files e metti a disposizione il pacchetto che scaricherai ora al tuo hosting provider, aprendo un ticket di richiesta supporto per caricare il tuo nuovo certificato SSL Let’s Encrypt.

Passiamo a WordPress, adesso

Se il tuo Hosting Provider ti confermerà il caricamento del certificato, potrai finalmente procedere con la migrazione del tuo blog. Provo a fartela semplice anche in questo caso, ti consiglio l’utilizzo di un paio di plugin che possono fare tutto il lavoro al posto tuo, cercando così di abbattere i rischi di possibili errori.

Easy HTTPS Redirection
Easy HTTPS Redirection
SSL Insecure Content Fixer
SSL Insecure Content Fixer
Developer: WebAware
Price: Free

Entrambi ti aiuteranno a redirigere il traffico facilmente e correggere tutto quello che punta al vecchio indirizzo HTTP, salvo modifiche manuali (per esempio nel tema o in un file functions.php modificato, facilmente individuabili se sei stato tu a farlo). C’è ben poco di complesso da impostare, è tutto dannatamente semplice:

  • Vai in SettingsHTTPS Redirection, seleziona Enable automatic redirection to the “HTTPS” e Force resources to use HTTPS URL. Salva la tua scelta e, quando la pagina sarà aggiornata, seleziona la voce The whole domain in corrispondenza di You can apply a force HTTPS redirection on your entire domain or just a few pages. Salva ancora una volta. Hai appena terminato qui.
  • Spostati ora in SettingsSSL Insecure Content. Il plugin seleziona una papabile configurazione basata su un’analisi della tua installazione. Nel mio caso le opzioni selezionate sono:
    • Fix insecure content → Simple;
    • Fixes for specific plugins and themes → WooCommerce + Google Chrome HTTP_HTTPS bug (fixed in WooCommerce v2.3.13);
    • HTTPS detection → standard WordPress function.

Puoi –in qualsiasi momento– verificare che venga individuato correttamente il funzionamento HTTPS da Tools → SSL Tests.

Salvo errori, la tua configurazione ti permetterà ora di vedere il sito in HTTPS. Ricordati però che, a meno che il tuo Hosting Provider non lo preveda, dovrai ricordarti di rinnovare il tuo certificato SSL di Let’s Encrypt ogni 90 giorni. Puoi farlo facilmente tramite sslforfree, dovrai poi ricontattare il tuo provider per far caricare le nuove chiavi.

WordPress: passaggio da HTTP a HTTPS 16

Se utilizzi il sistema di commenti integrato in WordPress, il tuo lavoro finisce qui. In caso contrario potresti aver scelto di utilizzare Disqus (il sistema in uso su questo blog), e dovrai quindi seguire ancora qualche passaggio prima di poterti congedare ;-)

Migrare i commenti di Disqus

Cerco di riepilogare rapidamente anche questa: Disqus carica i commenti nei tuoi articoli grazie a un banale (si fa per dire, da gestire lato server) sistema di mappature URL. Il sistema capisce che commenti caricare in base all’indirizzo visitato in quel momento. Avendo tu migrato tutto sotto HTTPS, occorrerà allineare anche Disqus.

Tale funzione è ovviamente prevista, e viene spiegato all’indirizzo help.disqus.com/customer/portal/articles/286778-using-the-migration-tools, nasce più probabilmente per cambiare completamente URL (primodominio.tld verso secondodominio.tld per esempio), ma torna comodo anche per questo caso.

Accedi alla tua area di amministrazione Disqus, quindi spostati in Migration Tools (dalla colonna di sinistra), dovresti arrivare all’URL TUOUTENTE.disqus.com/admin/discussions/migrate/?p=migrate. A questo punto dovrai scaricare una lista completa delle tue mappature commenti, modificarla e darla nuovamente in pasto a Disqus, così che possa aggiornarsi. Dai un’occhiata alla galleria qui di seguito (sotto includo istruzioni più dettagliate):

  • Cominciata la migrazione, Disqus invierà all’indirizzo di posta elettronica (che hai fornito durante l’iscrizione al servizio) la lista degli URL indicizzati.
  • Apri la lista con Excel (o equivalente), clona la prima colonna, seleziona solo la seconda colonna e sostituisci tutti gli http:// con https:// (utilizza la funzione Cerca e sostituisci di Excel).
  • Salva il file, esci da Excel, riapri il file con Notepad++ (o qualsiasi altro editor di testo) e sostituisci tutti i punti e virgola con semplici virgole (anche in questo caso utilizza il Cerca e sostituisci), è richiesto da Disqus (che evidentemente non digerisce poi tanto bene i ;).
  • Carica il file su Disqus, verifica che la mappatura sia corretta, quindi lascia partire il lavoro in batch, a quel punto dovrai solo attendere che termini.

Entro le successive 24 ore, Disqus metterà a posto le cose, e tu finalmente potrai tornare a vedere i tuoi commenti :-)

Google Search Console

Update

In base al giusto suggerimento di Emanuele (nei commenti), mi sono
accorto di non averti parlato di Google Search Console, nonostante sia andato ad aggiornare la proprietà del sito inserendo l’URL con HTTPS. Trovi qui un suo articolo dedicato alla migrazione di WordPress da HTTP a HTTPS pubblicato al termine dello scorso anno, davvero molto interessante e completo.

In realtà è molto semplice anche questa cosa e va fatta se hai già configurato il tuo sito web nella console di big G. Secondo la documentazione ufficiale (support.google.com/webmasters/answer/6073543?hl=it), in caso di migrazione, si adotta questo metodo:

Se esegui la migrazione del sito da HTTP a HTTPS, Google considera l’operazione uno spostamento del sito con modifiche agli URL. Ciò può influire temporaneamente sulle cifre relative al traffico. Per ulteriori informazioni, consulta la pagina recante una panoramica sullo spostamento di un sito.
Aggiungi la proprietà HTTPS a Search Console. Search Console gestisce HTTP e HTTPS separatamente, non condividendo i dati relativi a tali proprietà. Pertanto, se hai pagine che adottano entrambi i protocolli, devi indicare una proprietà Search Console distinta per ciascuno di essi.

Quindi ti basterà entrare in Search Console, aggiungere “una proprietà” e specificare il tuo solito dominio, con l’unica differenza che ora avrà https:// davanti. Al resto, salve tue specifiche necessità di diversa configurazione, ci penserà Google, secondo un intervallo variabile che servirà ad analizzare nuovamente i contenuti del sito disponibili, indicizzandoli quanto prima e rendendoli disponibili nelle sue ricerche. Continueranno -contestualmente- a rimanere disponibili anche tutti i dati in HTTP semplice.

WordPress: passaggio da HTTP a HTTPS 17

Troubleshooting

Questione di Cookie

Paragrafo che spero non ti serva, ma ti lascio un consiglio spassionato: avvia quanto prima una sessione anonima con il tuo browser preferito, quindi visita il tuo sito web ora sotto HTTPS. Tutto si vede correttamente? Noti problemi o strani caricamenti che non vanno a buon fine? Io l’ho scoperto dopo un un po’ di tempo (stupidamente non ci avevo pensato, sono un po’ un pirla) e grazie anche alla segnalazione di alcuni lettori (che ancora ringrazio). Il plugin che caricava il famoso blocco di accettazione cookie (per quella stupida legge europea), impediva al CSS di fare il suo lavoro, rendendo di fatto inutilizzabile il blog.

Ho sostituito il plugin di (eu-cookie-law-widget) con Cookie Notice di dFactory:

Cookie Notice by dFactory
Cookie Notice by dFactory
Developer: dFactory
Price: Free

Un .htaccess per intercettare ogni cosa

Update

Anche questo nasce dal commento di Emanuele (vedi commento),
ed entra in gioco perché è riuscito a collegarsi a uno dei contenuti del blog forzando manualmente il protocollo HTTP dalla barra dell’URL. Per questo motivo, ho messo in produzione una modifica del file .htaccess, che ognuno di noi ha nella root della propria installazione WordPress (cos’è un file .htaccess?), pari a quella da lui utilizzata.

ATTENZIONE: Prima di partire, il solito consiglio: occhio sempre a quello che tocchi e che rimuovi, effettua il backup del tuo file .htaccess per sicurezza, così potrai agilmente tornare indietro in caso di problemi.

Apri il tuo file .htaccess con un editor di testo e scorrilo fino a trovare qualcosa che assomigli a questo:

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

A questo punto, inserisci ciò che ti permetterà di intercettare i tentativi di connessione via HTTP, che verranno automaticamente portati verso HTTPS:

RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Entrambe le righe possono essere inserite prima della RewriteBase /, ottenendo quindi questo risultato:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Se aggiornando il tuo blog (sia come utente autenticato, sia come visitatore ospite, mi raccomando!) qualcosa non dovesse funzionare, ripristina immediatamente il backup che avevi precedentemente effettuato. Probabilmente hai toppato qualcosa, o magari il codice riportato qui sopra non è adatto alla tua configurazione e occorrerà approfondire con il tuo fornitore di servizi (il provider sul quale hai acquistato il tuo piano di hosting).

Ora mi sembra che ci sia davvero tutto, spero di non aver dimenticato nulla.

Enjoy.

Condividi l'articolo con i tuoi contatti:

Il titolo è volutamente simile a quanto già scritto poco tempo fa, e vuole analizzare alcuni consigli che anche io cerco di dare a chiunque si mette a preparare una nuova installazione WordPress (spero prima per sé, poi forse –con buona esperienza sulle spalle– anche per altri), anche se in realtà i concetti di base valgono per qualsiasi accesso a qualunque servizio disponibile sulla grande rete. Basandomi sul blog di chi iThemes Security lo scrive, riporto alcuni passaggi secondo me fondamentali.

WordPress e Authy: autenticazione OneTouch 6

According to this infographic by WP Template on WordPress safety, insecure WordPress themes and plugins contribute to over 50% of all successful WordPress hacks.

Plugins and themes have to go through a screening process before they are released for public use from the WordPress.org plugin repository, so it is important to download your plugins and themes from trustworthy sources and always keep active themes and plugins update to the latest version.

fonte: ithemes.com/2016/11/08/wordpress-hacks

e ancora:

Using the same password on multiple sites is risky.

Using strong passwords for all your logins is one of the best online security practices you can develop.

The best practice to follow is creating a different password for every sing website you are registered on. Definitely don’t use the password you use for your bank account on another site.

An average of 30,000 sites are hacked every day.
This should give you an idea of how many people are affected by cyber attacks, and motivate you to use stronger passwords.

fonte: ithemes.com/2016/11/04/brute-force-attacks

Che poi non è che proprio ci voglia la scala eh. Strumenti come KeePass o simili (anche quelli completamente in cloud) sono fatti apposta per ricordarti password altrimenti (probabilmente) molto difficili da ricordare, soprattutto quando decidi di lasciare fare loro nella fase di generazione di una nuova password complessa. Vale anche il vecchio (ma ancora perfetto) consiglio del “utilizza password apparentemente stupide“, perché ti assicuro che “Il cavallo bianco di Napoleone!” può essere una password certamente più complessa della targa della tua automobile (puoi provare tu stesso su passwordmeter.com, tanto per levarti la curiosità).

Sulla base di ciò, è semplice stilare una ToDo List da tenere sempre bene a mente:

  • Sempre tenere aggiornato il tuo WordPress. Questo vale per il motore principale del CMS, ma anche (soprattutto, in realtà) plugin, temi e codice personalizzato che potresti aver scritto e poi dimenticato lì dopo poco, offrendo una possibile backdoor poco simpatica. Se il server che lo ospita è controllato da te, occorre tenere aggiornato ciò che gli permette di stare online (server web, MySQL, PHP, ecc.).
  • Disinstallare sempre plugin e temi non più utilizzati. Perché qui non si tratta solo di pulizia (sicuramente necessaria per tenere sempre snella l’installazione), ma perché così si vanno a chiudere possibili ulteriori falle, esattamente come da ragionamento del precedente punto della lista.
  • Utilizzare password complesse per ciascun account, possibilmente. Perché se è vero che il tuo blog è aperto alle iscrizioni (e si basa così sul buon senso dei tuoi utenti), è -spero- anche vero che tu possa stabilire delle regole precise per le password di coloro che possono pubblicare qualcosa, o peggio che possono modificare il comportamento del blog intero (un amministratore, tanto per essere chiari).
  • Abilitare l’autenticazione in due fattori per WordPress. E qui ti rimando all’articolo dedicato ad Authy e alla sua possibile integrazione con WordPress, comoda, funzionale, sicura.
  • Cancellare o declassare l’account “admin” predefinito di WordPress. Detto e stradetto, anche nel mio precedente articolo sulla protezione degli accessi alla Dashboard amministrativa, perché quell’utente creato di default nel database, è sempre scomodo e attaccabile (perché è quello che si da per scontato che esista).
  • Scegliere un buon hosting provider per il proprio CMS. Perché la sicurezza comincia dalle fondamenta, e affidarsi a chiunque non è –probabilmente– la migliore scelta, almeno per come la vedo io (e non solo). Un buon partner (perché di questo si tratta, nda) è quello che è sempre attento e pronto ad affrontare una difficoltà, a suggerirti le prossime mosse da fare, a bloccare chi è sgradito prima che faccia danni (più di quanti ne abbia già fatti entrando nel tuo sistema), e che ci tiene alla salvaguardia dei tuoi dati ma anche di coloro che abitano nel tuo stesso “condominio” (quando si parla di hosting condiviso, molto diffuso e primo step per tutti).
  • Scarica plugin e temi solo da fonti sicure. Evita come la peste siti web che promettono di regalarti il tema all’ultimo grido, creati con ore di sudato lavoro e ricchi di plugin solitamente a pagamento, pacchetti “all-in-one” appositamente clonati da siti web che li vendono e supportano quotidianamente. Spesso quei temi contengono codice malevolo, codificato (quindi di difficile decodifica per chi è alle prime armi), da qui in poi è tutto un salto nel buio. Se pensi che un tema sia assolutamente irresistibile, valuta l’acquisto della sua licenza, otterrai così anche un aiuto qualificato in caso di problemi, certamente meno costoso di qualcuno in grado di rimetterti in piedi dopo un deface (o simile) ai danni del tuo sito web.

Hai altri consigli? Vuoi raccontare la tua esperienza e dare qualche suggerimento in merito? L’area commenti –manco a dirlo– è a tua completa disposizione :-)

Condividi l'articolo con i tuoi contatti:

Qualche tempo fa ho avuto un problema piuttosto fastidioso: qualcuno ha deciso che uno specifico articolo di questo blog era poco gradito, buon (?) motivo per rompermi le scatole e saturare le risorse messe a disposizione dal mio hosting provider (che ringrazio per la pazienza). Per cercare di correre ai ripari, ho incattivito l’opzione di un plugin che già utilizzavo e che utilizzo ancora oggi, iThemes Security (ex Better WP Security).

Proteggere WordPress da login non autorizzati

Ci sono molteplici modi per proteggere l’accesso al wp-login.php, questo è uno tra i tanti attuabili senza molta fatica, una soluzione tutto sommato semplice da mettere in piedi.

Il mio consiglio? Fallo dopo aver chiuso l’accesso al sito web “al pubblico“, perché se è vero che sei sotto attacco, è anche vero che le risposte del tuo blog potrebbero andare in timeout, non arrivare mai. Per chiudere l’accesso a tutti tranne che a te dovrai conoscere il tuo indirizzo IP (mioip.it aiuta in questi casi) e sbarrare le porte grazie al file htaccess. Farlo è semplice, ti basterà creare (o modificare quello esistente) il file inserendo questo pezzo di codice:

order deny,allow
deny from all
allow from 127.0.0.1

Sostituisci il 127.0.0.1 con il tuo IP, carica il file .htaccess nel tuo spazio web (ripeto: se lo hai già, modifica quello che hai e non sovrascriverlo) e il gioco è fatto. Nessuno potrà visitare il tuo sito web a eccezione di te. Così facendo dovresti tagliare fuori il resto del mondo e avere campo libero per lavorare.

Installa iThemes Security e attivalo, così possiamo passare alla sua configurazione, e nello specifico quella utile a proteggere il blog da ripetuti tentativi di accesso alla dashboard di amministrazione o a un URL in particolare (giocando un pelo in contropiede e cambiando le carte in corsa, per poi rimetterle al loro posto).

Il plugin propone moltissime opzioni che ti consiglio caldamente di analizzare, ragionare e attivare secondo tue necessità, io preferisco saltare sulla singola esigenza di stavolta, andiamo con ordine.

404 detection

Servirà a proteggerti da chi tenta di raggiungere costantemente URL non esistenti, le sue impostazioni (e i limiti oltre i quali mandare in ban l’IP di chi ci sta provando) si trovano però in Global Settings, nello specifico parlo di:

  • Blacklist Repeat Offender, che deve essere assolutamente attivo.
  • Blacklist Threshold, che corrisponde al numero di tentativi da abbuonare all’IP prima di escluderlo in maniera definitiva (impedendogli di visualizzare il sito web).
  • Blacklist Lookback Period, che corrisponde al numero di giorni durante i quali quell’IP continuerà a rimanere sotto controllo (per capirci: se il limite di lockout è 2, per il numero specificato di giorni basterà farne un altro per andare in ban, una soluzione molto secca, tanto chi attacca generalmente raggiunge il limite di lockout nel giro di qualche minuto al massimo).
  • Lockout Period, che corrisponde all’intervallo di tempo (in minuti) di allontanamento di quell’IP dal blog.
  • Lockout White List è invece il box adatto a raccogliere gli IP che non devono essere soggetti alle impostazioni sopra riportate.

In tutto questo, nella stessa tab (Global Settings, nda), potrai scegliere di essere avvisato dei lockout e dei ban a mezzo posta elettronica (l’opzione da spuntare è Enable Email Lockout Notifications), che poi è un po’ come avere l’immediato polso della situazione …

Proteggere WordPress da login non autorizzati 1

e pensa che quella che vedi qui sopra è solo una parte dei ban a me notificati nel periodo dell’attacco, in pratica un campo di battaglia senza esclusione di colpi (sono arrivato a toccare quota 400 ban circa in un paio di giorni).

Banned Users

Passa ora alla tab Banned Users e imposta ciò che credo possa esserti più utile, ovvero:

  • Default Blacklist, che ti permetterà di sfruttare liste già popolate e verificate, offerte da HackRepair.com.
  • Enable Ban Lists, che manco a dirlo è tutto ciò che serve per iniziare a fare la raccolta differenziata di IP che servono evidentemente poco alle tue visite, ma che minano per troppo tempo la tua pazienza.

Volutamente non ho specificato (almeno fino a oggi) degli User Agents specifici. Generalmente quelli più fastidiosi vengono lasciati liberi nel web da player molto grandi, motori di ricerca, servizi. Ricorda che potrai comunque appoggiarti a questa ulteriore funzione in qualsiasi momento, in caso di necessità.

Local Brute Force Protection

Ciò che più va a “braccetto” con la protezione relativa agli errori 404, opzioni che riguardano stavolta il login alla Dashboard amministrativa di WordPress e che –secondo me– devono essere altrettanto restrittive e di difficile perdono, perché se sei davvero il gestore del blog, hai anche la possibilità di chiuderti fuori dalla porta ma conoscere il trucco delle chiavi sotto al tappeto, andando a disabilitare il plugin (rinominando la sua cartella nello spazio FTP) in caso di errore ripetuto e non voluto.

  • Max Login Attempts Per Host: specifica qui il numero di tentativi massimi di login per un singolo host (IP) prima di finire nella lista dei cattivi, in alternativa puoi lasciarlo a zero per evitare di mandare in ban l’indirizzo IP e decidere di rendere sufficientemente cattivo il Max Login Attempts Per User, che si riferisce invece al numero massimo di login di uno specifico utente (che può utilizzare più IP sorgenti, giusto per capirci).
  • Minutes to Remember Bad Login (check period) indica, come per il Blacklist Lookback Period di prima, il tempo che deve passare prima che il plugin dimentichi uno dei tentativi andati a male precedentemente.
  • Automatically ban “admin” user è –infine– quella che preferisco, perché la prima regola di qualsivoglia installazione di WordPress è quella di andare a disattivare o eliminare completamente l’admin creato di default dall’installazione, creandone uno che abbia uno username del tutto differente. Se qualcuno tenta di entrare come “admin” nel tuo blog, probabilmente si tratta di un bot, meglio estirparlo sul nascere, senza pensarci due volte.

C’è altro?

Si, molto. C’è da dare un’occhiata alla Network Brute Force Protection, alla File Change Detection (ciò che ti avvisa nel caso in cui vengano modificati dei file), alla WordPress Tweaks (per disattivare opzioni non necessarie e regolare l’accesso a risorse di WordPress) e tanto altro ancora, davvero. Prenditi il tempo necessario, studia tutte le possibilità offerte dal plugin, valuta se l’opzione Pro (a pagamento) proposta dallo stesso sviluppatore fa al caso tuo, imposta la migliore configurazione tenendo presente che in caso di configurazione errata o particolarmente cattiva, potrebbe chiuderti fuori dalla porta senza neanche passare dal via e prendere le duemila lire.

Quanto fatto però non basta, perché se l’attacco è verso uno specifico URL esistente, dovrai temporaneamente mettere offline il contenuto, oppure scegliere di cambiargli indirizzo, almeno per un periodo durante il quale ogni attacco non andrà a buon fine e porterà direttamente al ban, raccogliendo una serie di IP dai quali proteggersi. Concludi l’operazione andando a rimettere a posto il file .htaccess precedentemente modificato, per permettere a tutti di accedere nuovamente al blog. Le risorse del provider saranno ora più che sufficienti e potrai sopportare nuovamente il tuo carico di visite, quelle vere e assolutamente gradite.

Dopo aver adottato la soluzione, ho potuto rimettere abbastanza rapidamente online il contenuto precedentemente attaccato, che ancora oggi fa parte degli archivi di questo blog e che spero possa rimanere lì per molto altro tempo (no, non dirò di quale si tratta) :-)

L’area commenti è –come sempre– a totale disposizione per ulteriori soluzioni, alternative, commenti, critiche costruttive e per raccolte di “beneficenza“, che Natale si avvicina e sta baracca bisogna pur pagarla per tenerla viva e vegeta.

Estote parati (cit.).

G

Condividi l'articolo con i tuoi contatti:

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!

Più che un post del blog questa è una vera e propria comunicazione di servizio da tenere buona se dovesse ricapitarmi la stessa cosa. Per poter utilizzare il sito web dell’INPS (e non solo) bisognerebbe avere a disposizione un manuale di istruzioni o una guida turistica da tradurre in più lingue per tutti i tipi di utente.

Dato che facilità non è certo il loro sinonimo, sappiate che per cambiare l’indirizzo di posta elettronica associato al proprio profilo cittadino, sarà necessario recarsi nei Servizi Online (a oggi: inps.it/portale/default.aspx?iMenu=2&ServAction=elencoTipoUtente), quindi selezionare la voce “Visualizzazione e modifica dati anagrafici, indirizzo e recapiti” (a oggi: inps.it/portale/default.aspx?iMenu=2&iNodo=2&iiDServizio=533&sURL=https%3a%2f%2fserviziweb2.inps.it%2fArcaSatWeb%2fLoginInternet.do%3fsrcPortal%3d3), voce che fa parte di una pagina interminabile, all’interno di un altrettanto interminabile elenco puntato:

Servizi online INPS: modificare il proprio indirizzo e-mail

Ennesimo caso da aggiungere a quelli di usabilità e “user experience” che il nostro governo offre quotidianamente tramite siti web e applicativi in Java, quelli che ogni volta che c’è bisogno di fare un’installazione o un aggiornamento è un po’ come organizzare una gita scolastica a Lourdes.

Condividi l'articolo con i tuoi contatti:

Oggi facciamo della gran auto-referenzialità, non capitava da tanto e voglio approfittarne per spiegarvi come nasce un piccolo sito web in grado di raccogliere alcune pagine “quasi statiche” che raccontano la propria persona, mettano in mostra il Curriculum Vitae e facciano conoscere al visitatore gli interessi, le capacità e le informazioni di cui necessita per un primo approccio (fondamentali quindi i riferimenti per essere contattati).

gfsolone.Com, since 2005

Ho messo in piedi la prima versione del mio sito personale circa 4 anni fa. Novembre del 2005, grazie ad archive.org sono anche riuscito a trovare uno straccio di pagina ancora funzionante:

web.archive.org/web/20051124224608/http://www.gfsolone.com

La piattaforma usata era Simple PHP Blog, chiaramente modificata secondo le mie esigenze (avevo già usato lo stesso motore per diversi altri siti nello stesso periodo, compreso RavennaLUG), serviva a raccogliere le pagine secondo me utili a farmi conoscere quanto bastava, ancora niente blog, decisamente restio ad espormi in prima persona (lo facevo già via GxWare.org pubblicando articoli informatici).

Da li il passo ad una v2 è stato abbastanza breve, si parla del 24 giugno di 365 giorni dopo (24.06.06), giorno del mio onomastico durante il quale ho deciso di tirare fuori la versione rinnovata, decisamente più compatta e (ahimé) con informazioni dimezzate:

web.archive.org/web/20060724234250/http://www.gfsolone.com (si vede poco e nulla, c’erano molte immagini)

E così venne la terza versione, la penultima, quella durata più di tutte, basata semplicemente su codice scritto a manina, grafica personalizzata via CSS, PHP e qualche “funzioncina” qua e la in JavaScript, nulla di eccezionale ma ha fatto il suo “sporco lavoro“:

web.archive.org/web/20070204085430/http://www.gfsolone.com/index.html

Tra una modifica e l’altra (piccole, mai invasive), si è arrivati a “gfsolone.Com v4“, un rinnovamento completo di motore, grafica e contenuti con la speranza che questi ultimi rimangano sempre aggiornatissimi (dipende dal sottoscritto, lo so :P). Ve lo presento:

http://gfsolone.com

e questi sono i suoi dettagli:

Nulla quindi di particolarmente ostico da mettere in piedi, non trovate?

# perché WordPress?

Perché è il CMS più scalabile, modificabile e personalizzabile in pochi minuti che esista sulla faccia della terra, pensiero personale ovviamente. Perché è gratuito, open-source, ha dietro di se una comunità di utilizzatori, sviluppatori e appassionati davvero enorme, pronta ad aiutare chi ha difficoltà, anche a livello nazionale.

Perché possiede già un ricco database di plugin che possono venire incontro alle esigenze di qualunque sviluppatore desideroso di non fare a mano ciò che potrebbe fare automaticamente uno script in PHP. Perché viene costantemente tenuto sotto controllo, aggiornato e rilasciato in tempi record quando si tratta di riparare una possibile falla critica (un pò come Firefox).

Perché, perché, perché, ci sarebbero mille altri motivi per utilizzare WordPressnon è solo un CMS per far blog, è molto di più.

# perché quei plugin?

Il paragrafo probabilmente più piccolo, non serve spendere molte parole sulla scelta dei 3 plugin di partenza. Ciò che fanno spiega abbondantemente la loro funzione all’interno del sito:

  • post2pdf servirà a chi desidera salvare una copia del mio CV direttamente in PDF da tenere da parte e stampare nell’eventualità serva. Non posso mostrarvelo in funzione, la pagina CV non è ancora pubblica :P
  • wp-db-backup … lo chiedete anche? Salvare settimanalmente una copia del DB MySQL da inviare comodamente alla casella GMail è un’operazione che abilito su qualsiasi blog da me controllato o messo in piedi. I backup non sono mai abbastanza quando qualcosa va storta!
  • wp-contactform è già in funzione e disponibile per tutti alla pagina gfsolone.com/contattami/modulo-contatto, per permettere al visitatore di contattarmi senza usare il proprio mailclient. Comodo, rapido, funzionale.

# perché quel tema?

No dico, lo avete visto? Replicare nativamente la grafica di facebook che da sempre apprezzo particolarmente è la soluzione che mi ha colpito di più durante l’esplorazione del web alla ricerca di un tema che potesse identificare la nuova versione del sito. E’ minimalista, non richiede troppi secondi per il caricamento di una singola pagina, usa un CSS da 20 righe a malapena, una vera chicca! E poi date una occhiata anche a questo blog, non vi sembra che vadano particolarmente d’accordo? :)

Immagini grandi (volutamente tenute così), testo altrettanto (per una più comoda lettura), uso spudorato di strumenti che mette a disposizione il web 2.0 per raccogliere (ad esempio) gli ultimi articoli presi da questo blog o per farvi vedere le ultime fotografie caricate su Flickr, contatti bene in vista per essere sicuro che a nessuno sfuggano :mrgreen:

# qualche modifica fatta

Andare a ritoccare un tema così ben studiato è un’operazione che porta via “poco tempo“, tutto dipende da ciò che si desidera. Mettiamola così: il menu inizialmente studiato per CryBook prevede uno spazio dinamico tra una voce di menu e l’altra (nella barra superiore) che comprende anche eventuali pagine “figlie” al di sotto della principale. Vi mostro la differenza:

PRIMA


DOPO


Il tutto per dare il giusto spazio tra una voce e l’altra senza strani incolonnamenti stile tangenziali di Milano! Le pagine figlie vengono dichiarate attraverso il DIV “Pagine Correlate” nelle pagine “padre” (si vede nell’immagine “Dopo”).

Come seconda cosa è arrivata la personalizzazione della pagina di errore 404, abbastanza comune e visualizzata (anche se non richiesta espressamente) da tutti coloro che ricordano un vecchio indirizzo forse non funzionante. Fondamentale specificare che probabilmente il contenuto richiesto esiste ancora ma sarà necessario cercarlo manualmente, oppure scrivere al proprietario della baracca per chiedere delucidazioni.

Chiaramente si andrà a togliere di mezzo il motore di ricerca interno, non serve con così poche pagine già tutte raggiungibili tramite menu superiore (o Pagine Correlate). Ciò vuol dire che non sarà visibile, ma comunque funzionante se lo si richiama dall’URL!

Lo stesso vale per il feed dei contenuti. Trattandosi di pagine “statiche” non ci sarà bisogno di seguire notizie che non verranno mai pubblicate. Tanto vale commentare la riga che richiama il tutto no (si trova generalmente nel file header.php del tema scelto)?

Stavolta però il lavoro lo si fa bene e per sicurezza si mette un plugin (solo se lo ritenete opportuno) per bloccare chiunque cerchi di arrivare “a mano” sul feed:

gfsolone.com/feed

Il suo nome è “Disable RSS“, disponibile gratuitamente sull’extend di WordPress.org:

wordpress.org/extend/plugins/disable-rss

Il più del lavoro è stato il trasporto vero e proprio dei dati contenuti nelle pagine, un procedimento che porta via parecchio tempo se si vuole adattare al meglio il codice al nuovo layout o decidere di cambiare totalmente posizione agli elementi. Ho preferito adottare la seconda soluzione per parecchi elementi, giusto per rinnovare un attimo il look (altrimenti che gusto c’è?).

Ho tolto (per chi stesse cercando inutilmente) le pagine dedicate all’intervento del LitCamp (mi pare di ricordare che si parlasse del 2007) e gli oggetti creati per la Google Toolbar ufficiale. Nel caso in cui questi ultimi servissero nuovamente basterà chiedere, ripristinerò la pagina :)

# e ora?

Il risultato è servito, in bella mostra per tutti, certo di miglioramenti se ne possono tirare fuori molti altri ma per il momento va bene così, mi piace, quel look talmente tanto minimalista da apparire fantastico ai miei occhi, non riesco a farmi piacere i temi ultra-complessi o ricchi di immagini facenti parte del layout di base, semmai preferisco usare la banda (internet) altrui per far caricare immagini che arricchiscono i post (lo notate fin troppo su gioxx.org)!

Cosa ne pensate? Volete provare a lasciare un commento per insultare il sottoscritto o magari per suggerire ulteriori miglioramenti? :)

Condividi l'articolo con i tuoi contatti: