Coucou,
je suis en train d'intégrer l'ecran de sécurité en standard dans SPIP,
de manière à ce qu'il soit encore plus facile de le mettre à jour en
cas de trou (c'est un fichier unique à écraser, et qui n'affecte pas
le fonctionnement du site).
Il s'agit du fichier config/ecran_securite.php ; il est inclus
systématiquement par inc_version, juste après mes_options (ce qui
permet de le désactiver ou de le configurer).
L'idée est que cet écran est indépendant de la version de SPIP :
ainsi, en cas de "trou", il suffit de mettre à jour ce fichier pour
boucher le trou.
Pour le désactiver, il suffit d'indiquer dans mes_options
define('_ECRAN_SECURITE', 0);
Dès que ce script est actif, _ECRAN_SECURITE est définie et a pour
valeur le numéro de version de l'écran.
Si on est hébergeur, on peut l'activer au niveau d'apache, pour tous
les scripts php, avec un auto_prepend_file
'/chemin/vers/ecran_securite.php' ; cela permet, en cas de trou de
sécu, de n'avoir qu'un seul fichier à mettre à jour pour protéger
l'ensemble des SPIP du serveur, y compris les plus vieux.
Outre la sécu à proprement parler, le script fait aussi barrage aux
robots indexeurs :
* sur les doubles paginations et sur les dates folles de l'agenda
* lorsque la charge serveur (load) est trop élevée.
Le niveau de load qui déclenche ce dernier comportement est défini par
défaut à 4 :
define('_ECRAN_SECURITE_LOAD', 4);
=> on peut mettre à 0 pour ne pas appliquer ce comportement.
Je le teste depuis plusieurs mois sur mes serveurs et ça a
spectaculairement résolu les problèmes de saturation.
C'est fait dans les règles (RFC et conseils donnés par Google) et ça
ne nuit pas au référencement : lorsqu'un robot demande une page, si le
serveur est chargé on répond avec un code 503 qui lui dit "pas
maintenant, reviens dans 5 minutes".
header("HTTP/1.0 503 Service Unavailable");
header("Retry-After: 300");
cf. http://www.seroundtable.com/archives/015171.html
-- Fil
