Perché non si può essere sempre la parte migliore di noi stessi.
(Ogni tanto un post come una volta).
La tradizionale architettura LAMP (Linux, Apache MySQL, PHP) su cui si basa la maggior parte delle installazioni di WordPress ha sempre funzionato bene e tutt’ora fa il suo lavoro in maniera egregia. Il problema di questa soluzione sono le prestazioni: su un server poco carrozzato o con siti ad alto traffico la modalità di funzionamento di Apache + PHP tende a saturare le risorse fino a smettere di servire pagine nei casi più estremi.
Dopo un aggiornamento di WordPress la pagina di login potrebbe presentare l’errore: “I cookie sono bloccati a causa di un output inaspettato.“, rendendo impossibile l’accesso all’interfaccia di amministrazione.
Le impostazioni del vostro browser non c’entrano, e i link suggeriti riportano soluzioni che non sempre funzionano e sono sempre le solite: rinominare la cartella dei plugin via FTP ed eventualmente anche quella dei temi. Visto che ci ho messo un po’ per capire la causa, e la soluzione è difficile da trovare con Google perché è sepolta sotto un po’ di pagine di risultati inutili, lo scrivo anche qui.
Questo non è un post che suggerisce metodi per violare la sicurezza di un blog, ma per rimediare ad un inconveniente che ho incontrato qualche volta. In particolare mi è successo che i privilegi di un utente si fossero in qualche modo “corrotti” e non fosse più possibile accedere alle funzioni di amministrazione.
Lo scenario è il seguente. Devo fare degli interventi di manutenzione su un blog WordPress che ha qualche problema di funzionamento. Le cose che ho a disposizione sono:
Come prima cosa accedo al blog con l’account e visualizzo la dashboard (bacheca).
Poi creo un file che chiamo, per esempio, get_user_info.php, con il seguente contenuto:
<?php global $current_user; require('wp-blog-header.php'); get_currentuserinfo(); echo 'Username: ' . $current_user->user_login . "\n"; echo '</br>'; echo 'User email: ' . $current_user->user_email . "\n"; echo '</br>'; echo 'User first name: ' . $current_user->user_firstname . "\n"; echo '</br>'; echo 'User last name: ' . $current_user->user_lastname . "\n"; echo '</br>'; echo 'User display name: ' . $current_user->display_name . "\n"; echo '</br>'; echo 'User ID: ' . $current_user->ID . "\n"; ?>
Negli ultimi giorni c’è stata un drastico aumento degli attacchi alla pagina di login di WordPress. Quasi 100.000 computer “zombies” in preda a un botnet stanno cercando di forzare un gran numero di installazioni tramite un attacco “brute force” che tenta di indovinare la password dell’amministratore.
Difendersi non è difficile, basta prendere alcune precauzioni. Potete cambiare il nome dell’amministratore, scegliendone uno diverso da “admin”, potete scegliere una password complessa di almeno 10 caratteri, o potete attivare l’autenticazione a due fattori.
Sul nuovo template ho messo in homepage alcuni “box”; un paio di questi recuperano le informazioni da un feed esterno e le ripubblicano. Per questo scopo WordPress ha una funzione apposita: fetch_feed, che restituisce un oggetto SimplePie utilizzabile per i propri scopi.
I risultati vengono cachati e ricaricati alla scadenza, ma purtroppo non c’è modo di impostare dalla funzione il tempo di refresh del feed, che di default è di 12 ore; specie per Twitter tale valore è un po’ troppo basso per i miei gusti, e ho cercato di capire se fosse modificabile. Il problema è banale, ma su Google i risultati sono viziati: la stragrande maggioranza riguarda i feed generati da WordPress, non quelli letti dall’esterno.
