Pour améliorer le système, une nouvelle approche consiste à exploiter le même concept de champ caché, mais en utilisant cette fois un peu de javascript côté client pour lui donner sa "bonne" valeur. Aucune méthode n'est fiable à 100% mais celle-ci semble s'en approcher.
]]>Pour améliorer le système, une nouvelle approche consiste à exploiter le même concept de champ caché, mais en utilisant cette fois un peu de javascript côté client pour lui donner sa "bonne" valeur. Aucune méthode n'est fiable à 100% mais celle-ci semble s'en approcher.
Bilan et analyse
Tout d'abord un petit topo de ce que j'ai pu apprendre des spammers pendant cette semaine d'expérimentation :
- Il semble y avoir deux familles de spammeurs (regroupés dans une plus large famille dite de "chieurs"). Ceux qui savent quel CMS vous utilisez (Drupal, Wordpress, DotClear, etc.) et qui forgent des réponses spécifiques. Ceux là sont vite déroutés si l'on insère un nouveau champ non prévu en standard ou si l'on change les urls d'accès. La deuxième famille est plus complexe à gérer car elle se moque du type de CMS et analyse la page pour forger le "bon" formulaire.
- Contrairement à la légende en circulation, de nombreux spammeurs connaissent javascript et exécute très bien tous les scripts d'une page. Encoder un formulaire avec des document.write, même avec cryptage ne sert absolument à rien.
- Ces mêmes logiciels spammeurs savent suivre les scripts même s'ils sont dans des fichiers externes. Donc fragmenter un formulaire en plusieurs fichiers .js n'est d'aucune aide.
En revanche ce que ne semble pas savoir faire cette dernière famille à problèmes, c'est déclencher des événements javascript (onfocus, onkeyup,etc..). En effet, si l'on place par exemple un événement onfocus sur un champ et un autre sur un autre champ, le malheureux n'a aucun moyen de savoir lequel serait "piégé" et lequel rendrait le formulaire valide.
L'idée ici est donc de reprendre cet concept (merci Advaita 
pour modifier le champ caché de notre précédent article et lui donner une valeur "magique" à ce champ sur déclenchement d'un événement utilisateur onkeyup, rendant ainsi valide le formulaire.
Mise en œuvre
L'autre avantage de cette méthode est de ne plus avoir à désactiver le cache de page. En effet, il suffit de mettre dans le formulaire une valeur par défaut "fausse" et dans l'événement javascript la "bonne" pour le système fonctionne en cache ou pas. Dans le précédent exemple le time stamp devait être le bon à chaque visualisation et ne pouvait donc fonctionner avec un formulaire en cache.
De même la méthode est suffisamment transparent pour ne plus l'appliquer à seulement certains formulaires. Plus la peine donc de prévoir une page de "settings" pour définir qui est protégé de qui ne l'est pas. Par défaut tout formulaire accédé anonymement est protégé.
Comme pour la précédent méthode, la première chose à faire est d'ajouter un champ caché qui cette fois aura pour nom une valeur définie par une define php. Je vous conseille de choisir votre propre non de sorte à rendre le système le plus personnalisé possible.
Pour commencer ce nouveau module, reprenez l'ancien, enlevez la fonction de hook sur vilains_spammeurs_settings et modifiez la fonction hook vilains_spammeurs_form_alter comme suit :
define('COOKIE_VALUE', 'magique');
function vilains_spammeurs_form_alter($form_id, & $form)
{
global $user;
if ($user->uid == 0)
{
$timeStamp = time();
error_log('SpamKiller - ALTER - ' . $_GET['q'] . '/' . $form_id . ' = ' . COOKIE_NAME . '=' . $timeStamp);
$form[COOKIE_NAME] = array (
'#type' => 'hidden',
'#default_value' => $timeStamp
);
$form['#submit'] = array_merge(array (
'vilains_spammeurs_validator' => array ()
), $form['#submit']);
return;
}
}
Comme vous le voyez, il n'y a pas grande différence avec la précédent procédure mise à par le nom du champ et la suppression de la ligne désactivant la mise en cache.
Ensuite, nous allons introduire deux nouvelles fonctions pour modifier à la volée les champs textarea et textfield et y insérer un événement javascript :
{
$result = theme_textarea($element);
global $user;
if ($user->uid==0)
$result = str_replace("<textarea", '<textarea onkeyup="this.form.' . COOKIE_NAME . '.value=\'' . COOKIE_VALUE . '\';" ',$result);
return $result;
}
function phptemplate_textarea($element)
{
$result = theme_textarea($element);
global $user;
if ($user->uid==0)
$result = str_replace("<input", '<input onkeyup="this.form.' . COOKIE_NAME . '.value=\'' . COOKIE_VALUE . '\';" ',$result);
return $result;
}
La seule astuce ici consiste à utiliser les hooks assez peu connus phptemplate_xxx qui sont appelés pour skinner les éléments textarea et textfield. Heureusement pour nous le moteur de thème phptemplate ne les utilise pas. Leur rôle est d'effectuer la transformation standard (ne pas ré-inventer la roue) puis, si mode "anonyme", de rajouter un événement "onkeyup" qui va, lorsque déclenché, donner à notre champ caché sa vraie valeur. Ainsi l'appui d'une touche dans n'importe quel champ texte (commentaire, login, etc..) va valider.
Il ne nous reste plus maintenant qu'à vérifier cette valeur en retour de formulaire comme dans le billet précédent en modifiant la procédure de validation comme suit :
{
$cookieValue = $form_values[COOKIE_NAME];
$failed = $cookieValue != COOKIE_VALUE;
error_log('SpamKiller - SUBMIT - ' . ($failed ? 'SPAM' : 'OK') . ' - ' . $_GET['q'] . '/' . $form_id . ' : ' . COOKIE_NAME . ' = ' . $cookieValue);
if ($failed)
{
error_log('Spam Content : ' . $form_values['comment']);
drupal_set_header('HTTP/1.1 666 Forbiden to spammers.');
print "Ceci est sûrement un spam. Si c'est un erreur, veuillez contacter l'administrateur";
exit ();
}
return;
}
Voilà, c'est tout. Plus de spam, jusqu'à ce qu'ils trouvent une parade, bien évidement Mais il est à noter que les spammeurs ont un net handicape par rapport à nous, s'ils jouent sur une masse, nous nous pouvons créer des cas particuliers...
Pour ceux que cela intéresse, les sources sont disponible sur le dépôt subversion :