Pas une mauvaise prĂ©occupation, pour ĂȘtre honnĂȘte, mais en pratique la solution ne tient pas vraiment la route. Jây rĂ©flĂ©chis depuis hier soir et il y a quelques obstacles qui sont intrinsĂšquement impossibles (?) Ă surmonter :
1. ProblĂšmes avec wget
SMF gĂ©nĂšre des permutations dâURL dynamiques pour chaque sujet :
-
Filtres de tri (?sort=subject;desc, ?sort=starter)
-
Pagination et liens de navigation rapide (?topic=123.prev_next=next, ?topic=123.prev_next=prev)
-
Vues utilitaires (?action=printpage, ?action=profile, ?action=help)
-
Identifiants de session et variations de lâindex des forums
Si tu lances wget -m sur SMF sans des dizaines de rĂšgles regex, le robot dâexploration VA tomber dans des boucles dâexploration infinies. Comme le forum compte environ 250 000 messages, il peut trĂšs, trĂšs facilement gĂ©nĂ©rer 15 MILLIONS (dâaprĂšs ce que je vois) dâURL Ă aspirer â bonne chance avec ça !
2. Le problĂšme dâURL et de serveur web
Jâai fait quelques tests ; les serveurs web standards ne servent pas de fichiers statiques Ă partir de chaĂźnes de requĂȘte (query strings) comme celles utilisĂ©es par SMF.
Pour ĂȘtre plus clair : lorsquâun utilisateur visite index.php?topic=1240.0, le serveur web voit index.php comme le chemin du fichier et ?topic=1240.0 comme des arguments de requĂȘte. Si PHP nâest plus lĂ , le serveur essaie simplement de servir le fichier statique index.php en boucle. Pour associer des fichiers statiques aspirĂ©s aux URL dâorigine avec chaĂźne de requĂȘte de SMF, il faut Ă©crire des rĂšgles de rĂ©Ă©criture alambiquĂ©es dans Caddy afin de traduire les arguments de requĂȘte en noms de fichiers simples sur le disque. Si cette association casse, tous les liens entrants provenant de Google et du CPCWiki lui-mĂȘme seront brisĂ©s, ce qui est un vĂ©ritable cauchemar pour le SEO.
3. PiÚces jointes/Téléchargements
SMF sert les piĂšces jointes de maniĂšre dynamique via index.php?action=dlattach;topic=.... Cela va trĂšs probablement ĂȘtre un Ă©chec cuisant avec un robot dâexploration.
4. Recherche
Si on conserve le tout sous forme de pages statiques, le moteur de recherche (tel quâil est) sera hors service. On pourrait intĂ©grer un index de recherche sĂ©parĂ© cĂŽtĂ© client (comme Pagefind) dans les modĂšles HTML aspirĂ©s, mais cela va partiellement Ă lâencontre du but recherchĂ©.
Une solution ?
La meilleure solution Ă laquelle jâai pu penser serait de parser la base de donnĂ©es avec un script pour gĂ©nĂ©rer une liste dâURL uniques de sujets, puis dâutiliser wget pour rĂ©cupĂ©rer les URL de cette liste â mais cela ne rĂ©sout pas le reste des problĂšmes.
SĂ©curisation (Hardening)
Si la sécurité contre le vandalisme, etc. est la préoccupation principale, on peut trÚs facilement tout verrouiller en révoquant simplement les permissions INSERT, UPDATE, DELETE, DROP, ALTER ON sur la base de données. Il suffit de passer la racine du site (webroot) en lecture seule et de renvoyer des erreurs 503 pour des actions spécifiques comme :
@blocked {
query action=login*
query action=register*
query action=post*
query action=pm*
}
respond @blocked "Forum is read-only" 403
âŠet le tour est jouĂ© !
Mais bon, mĂȘme si un attaquant parvenait dâune maniĂšre ou dâune autre Ă accĂ©der au systĂšme dans son Ă©tat actuel pour faire des siennes, on a de toute façon des sauvegardes Ă une douzaine dâendroits diffĂ©rents maintenant 
.
