Ho un’installazione di WordPress Mu (versione 1.3 se non ricordo male) sulla quale lascio libera la possibilità di creazione di account utente e di blog. La piattaforma ospita una trentina di blog e, grazie anche ad un argomento principale molto di nicchia, non sono molti i nuovi blog registrati mensilmente.
Nonostante un basso traffico mi trovo comunque a dover affrontare orde di IP cinesi che tentano di registrare una quantità infinita di splog (spam blog). I vari plugin di captcha non sono affatto sufficienti (ne trovate alcuni qui http://wpmudev.org/plugins.php).
Ovviamente è banale cancellare uno splog appena lo si individua, il problema è che tra il momento di creazione e l’effettiva cancellazione può passare diverso tempo (dipende ovviamente da quanto frequentemente controllo la posta). In questa finestra temporale ho un blog sulla mia piattaforma che linka spudoratamente siti di Cia1is oppure WoW Gold. Tutto questo mi infastidisce.
Per questo motivo ho deciso di mettere mano al codice sorgente di WordPress Mu (che per gran parte è condiviso con Worpdress) e cercare di arginare il problema.
La soluzione proposta prevede la riscrittura di alcune funzioni nel file wp-signup.php in modo che venga inibita la possibilità di registrare direttamente un blog sulla piattaforma. In questo modo gli spammer non possono più interagire direttamente con le strutture dati che memorizzano i blog. E gli utenti “buoni”?
Ogni volta che un utente (o anche uno spammer) registra un nuovo blog viene inviata una mail, con tutti i dati inseriti dall’utente, all’amministratore della piattaforma; sarà quest’ultimo a creare a mano il blog, ovviamente solo se ritenuto valido (la creazione di un blog è facilmente eseguibile dal pannello di amministrazione di WordPress Mu).
Passiamo ora all’aspetto tecnico.
Le funzioni in wp-signup.php da modificare sono diverse: dovete cercare tutte le funzioni che creano un nuovo utente, un nuovo blog oppure un nuovo blog per un utente esistente.
Per fare un esempio si veda la funzione validate_another_blog_signup(). Verso la fine si trova una chiamata a wpmu_create_blog(), che si occupa della creazione di un blog, seguita da una chiamata a confirm_another_blog_signup(), che ha il compito di inviare una mail all’utente con i dati di accesso.
Per impedire agli utenti di interagire direttamente con il processo di creazione blog ho commentato la chiamata a wpmu_create_blog() e riscritto la funzione confirm_another_blog_signup(). Inoltre, per ricevere una mail ogniqualvolta un utente cerca di registrare un blog ho aggiunto una semplice chiamata alla funzione mail().
Il codice sorgente adesso è simile a questo:
mail('e-mail@amministratore-piattaforma.net', "Richiesta di attivazione altro blog", 'dominio: ' . $domain . ',path: ' . $path . ',titolo: ' . $blog_title . ',utente: ' . $current_user->id . ',meta: ' . $meta);
// wpmu_create_blog($domain, $path, $blog_title, $current_user->id, $meta);
confirm_another_blog_signup_hack($domain, $path, $blog_title, $current_user->user_login, $current_user->user_email, $meta);
dove la funzione confirm_another_blog_signup_hack() è così definita:
function confirm_another_blog_signup_hack($domain, $path, $blog_title, $user_name, $user_email, $meta) {
?>
<h2><?php printf(__('Abbiamo ricevuto la tua richiesta di attivazione. Grazie.')); ?></h2>
<p><?php printf(__('Appena il tuo blog verrà approvato riceverai una mail di conferma.')); ?></h2>
<?php
do_action('signup_finished');
}
se si ripetono queste modifiche per tutte le funzioni interessate si avrà una piattaforma nella quale sarà solo l’amministratore a poter creare i blog su esplicita richiesta degli utenti. Per ovvi motivi è opportuno modificare il processo di signup per segnalare come la creazione dei blog non sia immediata.
Per ora mi trovo bene con questo metodo che mi evita di dover cancellare 6 o 7 splog al giorno (infatti mi basta ignorare le richiesta di creazione blog se fatta da uno spammer) a fronte di 2 o 3 richieste valide al mese.
