La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: turold le 01 janvier 2016 à 16:40:05
-
Salut,
Suite à différents soucis que l'IPv6 a, par défaut, soulevé dans un forum SMF 2.0+, voici une solution.
Il y a un mod compatible avec SMF 2.0+.
Sujet qui en parle: http://www.simplemachines.org/community/index.php?topic=440357.0
Et directement la page du mod: http://custom.simplemachines.org/mods/index.php?mod=3051
-
Ce mod n'est plus supporté.
Comme vous pouvez le voir, le dernier commit date de 2013 : https://github.com/jdarwood007/smfmod_ipv6
Le fichier disponible sur http://custom.simplemachines.org/mods/index.php?mod=3051 a été modifié en 2015 par un fichier inutilisable.
Les autres problèmes de ce mod est qu'il modifie de très nombreux fichiers de SMF, ce qui est l’assurance de problèmes lors de l'upgrade en SMF 2.1
Bref, la seule solution pour IPv6 avec SMF, c'est SMF 2.1 qui est aujourd'hui en Beta 2.
Le développement ne va vraiment pas vite et j'ai peur qu'il ne sorte pas avant 2018 (après les bêta, il y a les Release Candidate).
Voici le calendrier auquel je pense, vu ce qu'il s'est passé pour le dev de SMF 2.0 :
- SMF 2.1 Beta 1 Released : 21 novembre 2014
- SMF 2.1 Beta 2 Released : 16 juillet 2015
- SMF 2.1 Beta 3 : début 2016
- SMF 2.1 RC 1 : fin 2016
- SMF 2.1 RC 2 : début 2017
- SMF 2.1 RC 3 : mi 2017
- SMF 2.1 RC 4 : fin 2017
- SMF 2.1 final : début 2018
-
Pour dire vrai, je n'avais lu que:
- le début du sujet
- la page du mod en diagonal
Même comme ça, j'avais lu que ce mod était dangereux sans aucune précaution.
Dommage pour sa dernière maj qui le rend inutilisable. :(
Par contre, t'as l'air d'avoir plus d'info que moi sur la version 2.1 de SMF.
Pas trouvé de trace que ce soit/sera compatible IPv6. Si?
-
SMF 2.1 est compatible IPv6 depuis 2012 (car le dev a débuté bien avant la beta 1)
Je suis perplexe face a un logiciel où il faut 6 ans de dev pour sortir la version 2.1
A noter que elle s'appelait SMF 2.5 ou SMF 3.0 selon les documents. Le nommage en SMF 2.1 a été décidé assez tard.
Calendrier de SMF 2.0 :
- SMF 2.0 Beta 1 : 24 août 2007
- SMF 2.0 Beta 2 : 20 janvier 2008
- SMF 2.0 Beta 3 : 17 mas 2008
- SMF 2.0 Beta 4 : 7 septembre 2008
- SMF 2.0 RC 1 : 4 février 2009 (SMF 2.0 RC 1.1 : 20 mai 2009 et SMF 2.0 RC 1.2 : 14 juillet 2009)
- SMF 2.0 RC 2 : 3 octobre 2009
- SMF 2.0 RC 3 : 8 mars 2010
- SMF 2.0 RC 4 : 1 novembre 2010
- SMF 2.0 RC 5 : 8 février 2011
- SMF 2.0 : 11 juin 2011
-
Je suis perplexe face a un logiciel où il faut 6 ans de dev pour sortir la version 2.1
Pas plus perplexe que 7-zip qui attend 2015 pour inclure unRAR5... 2 ans!
Open source ne veut pas dire que tous les devs s'occupent de la QA, et des choix d'orientation du logiciel.
-
SMF est plutôt bon au niveau qualité / sécurisation du code.
Bien moins de pb trou de sécurités graves qu'avec d'autres moteurs de forum open source.
Il faut par contre du temps pour les évolutions.
-
J'ai un peu vagabondé dans le code source, ça a l'air plutôt propre, structuré.
(Disons que si SMF était un restaurant, il n'y aurait pas de cafards écrasés partout dans la cuisine ni de crottes dans les assiettes.)
-
C'est quoi le problème avec l'IPv6 ? J'ai jamais eu de problèmes avec SMF et l'IPv6.
-
C'est quoi le problème avec l'IPv6 ? J'ai jamais eu de problèmes avec SMF et l'IPv6.
D'après nos retours, celui de Vivien, et de ce que j'en ai lu ailleurs, dans l'ordre des sources:
- Notre IPv6 ne s'affiche pas dans nos messages. C'est vide, aucune IP.
- Tous les invités IPv6 sont comptés comme un seul, car pas d'IP d'après SMF, donc pas possible de compter le nombre d'IPv6 différentes. Logique. Au revoir les nouveaux records de connexion en attendant la compatibilité IPv6 de SMF.
- Et en bonus, pour les admins qui adorent faire des ban IP: pas possible de ban IP quelqu'un en IPv6. Logique aussi.
-
J'ai jamais eu aucun de ces problèmes.
-
J'ai jamais eu aucun de ces problèmes.
Parfait!
Tu pourras dire à Vivien comment régler les 2 suivants:
- Notre IPv6 ne s'affiche pas dans nos messages. C'est vide, aucune IP.
- Tous les invités IPv6 sont comptés comme un seul, car pas d'IP d'après SMF, donc pas possible de compter le nombre d'IPv6 différentes. Logique. Au revoir les nouveaux records de connexion en attendant la compatibilité IPv6 de SMF.
Ici, on sèche...
-
Tu pourras dire à Vivien comment régler les 2 suivants:Ici, on sèche...
Ok mais il faut me dire exactement où ça coince parce que j'ai rien vu de tel.
-
Ok mais il faut me dire exactement où ça coince parce que j'ai rien vu de tel.
Pour l'IP, c'est très simple à vérifier.
En bas à droite de tous tes messages, tu dois avoir ton IP qui s'affiche (celle au moment du dit message).
Pas de souci en IPv4. Vide en IPv6 dans ce forum.
C'est à droite de "Signaler au modérateur" suivi d'une mini-image, et normalement suivi de ton IP que t'avais quand tu a posté le dit message.
Uniquement dans tes messages, sinon la mention d'IP est remplacée par "IP archivée".
L'autre problème est lié. Pas d'IPv6, pas de comptage de ceux-ci...
-
SMF 2.0 n'est pas entièrement compatibles IPv6, c'est assumé, la première version compatible IPv6 est la 2.1, en cours de dev.
Comme expliqué par turold, les log, les stats et le ban sont impactés.
-
J'ai du mal à comprendre comment un CMS arrive à gérer aussi mal les IP.
Il suffit simplement de regarder l'IP dans $_SERVER['REMOTE_ADDR'], augmenter la longueur du champ qui va bien dans MySQL et boom.
Ca me parait fou d'avoir à modder tout le CMS juste pour ça.
Bon courage et bonne année ;)
-
Ok, on va tester tout ça.
-
$_SERVER['REMOTE_ADDR'] dans SMF est modifié je ne sais où car il est vide en cas de connexion IPv6.
Cf le code que j'ai mis en bas de page qui teste si $_SERVER['REMOTE_ADDR'] est vide :
SMF n'est toujours pas compatible IPv6.
Voici le petit code PHP que j'ai rajouté, pour afficher si on surf en IPv6 (ligne affiché en bas de chaque page) :
echo '
<div id="footer_section"><div class="frame">
Vous utilisez <a href="https://lafibre.info/ipv6/ipv6-pour-lafibre-info/"><font color="';
if(empty($_SERVER['REMOTE_ADDR'])) echo 'green">IPv6</font></a> (Félicitations!)';
else echo 'red">IPv4</font></a>';
echo ' avec le port <a href="https://ip.lafibre.info" target="_blank"><font color="';
if ($_SERVER['REMOTE_PORT'] < "32768") echo 'red';
else echo 'green';
echo '">TCP ',$_SERVER['REMOTE_PORT'],'</font></a> <small>(<a href="https://lafibre.info/systeme-exploitation/local_port_range/" title="Plage de ports dynamique du protocole TCP" target="_blank">Plus d\'informations</a>)</small>';
Je teste l'absence d'adresse IP dans $_SERVER['REMOTE_ADDR'] pour déduire que le surf se fait en IPv6.
$_SERVER['REMOTE_ADDR'] empty => IPv6 else IPv4
-
$_SERVER['REMOTE_ADDR'] dans SMF est modifié je ne sais où car il est vide en cas de connexion IPv6.
$_SERVER['REMOTE_ADDR'] est vide quand tu appelles PHP en ligne de commande. Je soupçonne un reverse proxy mal configuré dans ton cas.
-
Je ne l'appelle pas depuis une ligne de commande, je fais la même chose que pour https://ip.lafibre.info sauf que le résultat est différent.
-
Ok, ça marche pour moi, en fait le code vérifie qu'il s'agit d'une IPv4 valide donc j'ai rajouté des OR avec une regex IPv6 et maintenant j'ai bien l'adresse qui s'affiche sur les posts. Je sais pas pourquoi mais dans le code les devs traitent les adresses rfc1918 comme non valides.
PS: pour pas s'emmerder, copier le QueryString.php de SMF 2.1 beta2. Ne pas oublier de faire un backup de l'ancien au cas où :P
-
PS: pour pas s'emmerder, copier le QueryString.php de SMF 2.1 beta2. Ne pas oublier de faire un backup de l'ancien au cas où :P
L'astuce aussi dangereuse que le mod.^^
Effectivement, précaution, précaution.
Par contre, je n'ai pas regardé son contenu. Est-ce que cela agit pour toutes les fonctions qui utilisent l'IP, ou seulement juste voir ses IP dans ses messages?
Et comme Corrector dans un autre sujet, j'ai toujours cru que l'ID dans les cookies servaient à compter les invités.
Mais à quoi pense les 4 devs officiels de SMF?
-
C'est pas dangereux, dans le nouveau code il y a juste des fonctions pour remettre les 0 ommis par la convention. J'aime pas trop cette approche.
-
C'est pas dangereux
ok
dans le nouveau code il y a juste des fonctions pour remettre les 0 ommis par la convention. J'aime pas trop cette approche.
En IPv4, IPv6, ou les 2?
Dans tous les cas, cela va surcharger l'info des IP.
-
okEn IPv4, IPv6, ou les 2?
Dans tous les cas, cela va surcharger l'info des IP.
Non ce sont des fonctions qui sont utilisées juste pour faire des vérifications, dans la db le code écrit les adresses sous leur forme abrégée.
-
Non ce sont des fonctions qui sont utilisés juste pour faire des vérifications, dans la db le code écrit les adresses sous leur forme abrégée.
Ah ok.
Ben c'est juste pour simplifier le code des vérifications alors.
Après, je ne sais pas ce qui est le mieux pour optimiser les performances des vérifications.
-
SMF 2.0 n'est pas entièrement compatibles IPv6, c'est assumé, la première version compatible IPv6 est la 2.1, en cours de dev.
Comme expliqué par turold, les log, les stats et le ban sont impactés.
Bref tous les modules qui gèrent les adresses!
J'ai du mal à comprendre comment un CMS arrive à gérer aussi mal les IP.
Il suffit simplement de regarder l'IP dans $_SERVER['REMOTE_ADDR'], augmenter la longueur du champ qui va bien dans MySQL et boom.
Les adresses IP ne sont pas juste stockées dans la table des messages.
Tu as aussi des opérations arithmétiques sur les adresses afin d'appliquer les bans.
-
Je sais pas pourquoi mais dans le code les devs traitent les adresses rfc1918 comme non valides.
Puisque l'adresse sert à attribuer la responsabilité les messages postés en cas de problème, éventuellement à faire des bans ou même à communiquer aux autorités en cas de plainte, il vaut mieux que l'adresse corresponde à quelque chose de bien défini et non un numéro dont le sens dépend du réseau local!
-
D'après nos retours, celui de Vivien, et de ce que j'en ai lu ailleurs, dans l'ordre des sources:
- Notre IPv6 ne s'affiche pas dans nos messages. C'est vide, aucune IP.
- Tous les invités IPv6 sont comptés comme un seul, car pas d'IP d'après SMF, donc pas possible de compter le nombre d'IPv6 différentes. Logique. Au revoir les nouveaux records de connexion en attendant la compatibilité IPv6 de SMF.
- Et en bonus, pour les admins qui adorent faire des ban IP: pas possible de ban IP quelqu'un en IPv6. Logique aussi.
En bonus : la limite du nombre de messages postés en rafale est atteinte facilement.
-
En bonus : la limite du nombre de passage posté en rafale est atteinte facilement.
Tu as été confronté a une limite en terme de MP postés ou de messages publics sur le site ?
-
Sur le forum, j'ai atteint la limite de messages "par personne" postés en rafale : "ma personne" doit être "0.0.0.0"
-
Je ne vois dans les paramètres que des limites pour les messages privés :
- Nombre maximal autorisé de destinataires dans un message personnel : 10
- Nombre de messages de forum en dessous duquel les utilisateurs doivent entrer un code lorsqu'ils envoient des messages personnels : pas de limite
- Nombre de messages personnels qu'un utilisateur peut envoyer en une heure : 10
- Nombre de messages de forum en dessous duquel les utilisateurs doivent entrer un code pour poster un message : pas de limite
-
Il n'y a pas une option délai minimal en secondes entre 2 messages postés ?
-
// Modify all settings related to posts and posting.
function ModifyPostSettings($return_config = false)
{
global $context, $txt, $modSettings, $scripturl, $sourcedir, $smcFunc, $db_prefix;
// All the settings...
$config_vars = array(
// Simple post options...
array('check', 'removeNestedQuotes'),
array('check', 'enableEmbeddedFlash', 'subtext' => $txt['enableEmbeddedFlash_warning']),
// Note show the warning as read if pspell not installed!
array('check', 'enableSpellChecking', 'subtext' => (function_exists('pspell_new') ? $txt['enableSpellChecking_warning'] : ('<span class="alert">' . $txt['enableSpellChecking_warning'] . '</span>'))),
array('check', 'disable_wysiwyg'),
'',
// Posting limits...
array('int', 'max_messageLength', 'subtext' => $txt['max_messageLength_zero'], 'postinput' => $txt['manageposts_characters']),
array('int', 'fixLongWords', 'subtext' => $txt['fixLongWords_zero'] . ($context['utf8'] ? ' <span class="alert">' . $txt['fixLongWords_warning'] . '</span>' : ''), 'postinput' => $txt['manageposts_characters']),
array('int', 'topicSummaryPosts', 'postinput' => $txt['manageposts_posts']),
'',
// Posting time limits...
array('int', 'spamWaitTime', 'postinput' => $txt['manageposts_seconds']),
array('int', 'edit_wait_time', 'postinput' => $txt['manageposts_seconds']),
array('int', 'edit_disable_time', 'subtext' => $txt['edit_disable_time_zero'], 'postinput' => $txt['manageposts_minutes']),
);
ManagePosts.php
-
$txt['spamWaitTime'] = 'Time required between posts from the same IP';
If you have a busy forum and you are on dialup or DSL where your IP can change, or multiple people from the same internet connection are posting to the board at the same time, you will experience this.
You can disable the time between posting in Admin > Posts and Topics > Time required between posts from the same IP
http://www.simplemachines.org/community/index.php?topic=301521.msg1993379#msg1993379
-
Subs.php
// Make sure the user isn't posting over and over again.
function spamProtection($error_type)
{
global $modSettings, $txt, $user_info, $smcFunc;
// Certain types take less/more time.
$timeOverrides = array(
'login' => 2,
'register' => 2,
'sendtopc' => $modSettings['spamWaitTime'] * 4,
'sendmail' => $modSettings['spamWaitTime'] * 5,
'reporttm' => $modSettings['spamWaitTime'] * 4,
'search' => !empty($modSettings['search_floodcontrol_time']) ? $modSettings['search_floodcontrol_time'] : 1,
);
// Moderators are free...
if (!allowedTo('moderate_board'))
$timeLimit = isset($timeOverrides[$error_type]) ? $timeOverrides[$error_type] : $modSettings['spamWaitTime'];
else
$timeLimit = 2;
// Delete old entries...
$smcFunc['db_query']('', '
DELETE FROM {db_prefix}log_floodcontrol
WHERE log_time < {int:log_time}
AND log_type = {string:log_type}',
array(
'log_time' => time() - $timeLimit,
'log_type' => $error_type,
)
);
// Add a new entry, deleting the old if necessary.
$smcFunc['db_insert']('replace',
'{db_prefix}log_floodcontrol',
array('ip' => 'string-16', 'log_time' => 'int', 'log_type' => 'string'),
array($user_info['ip'], time(), $error_type),
array('ip', 'log_type')
);
// If affected is 0 or 2, it was there already.
if ($smcFunc['db_affected_rows']() != 1)
{
// Spammer! You only have to wait a *few* seconds!
fatal_lang_error($error_type . 'WaitTime_broken', false, array($timeLimit));
return true;
}
// They haven't posted within the limit.
return false;
}
-
// Check both IP addresses.
foreach (array('ip', 'ip2') as $ip_number)
{
// Check if we have a valid IP address.
if (preg_match('/^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/', $user_info[$ip_number], $ip_parts) == 1)
{
$ban_query[] = '((' . $ip_parts[1] . ' BETWEEN bi.ip_low1 AND bi.ip_high1)
AND (' . $ip_parts[2] . ' BETWEEN bi.ip_low2 AND bi.ip_high2)
AND (' . $ip_parts[3] . ' BETWEEN bi.ip_low3 AND bi.ip_high3)
AND (' . $ip_parts[4] . ' BETWEEN bi.ip_low4 AND bi.ip_high4))';
// IP was valid, maybe there's also a hostname...
if (empty($modSettings['disableHostnameLookup']))
{
$hostname = host_from_ip($user_info[$ip_number]);
if (strlen($hostname) > 0)
{
$ban_query[] = '({string:hostname} LIKE bi.hostname)';
$ban_query_vars['hostname'] = $hostname;
}
}
}
// We use '255.255.255.255' for 'unknown' since it's not valid anyway.
elseif ($user_info['ip'] == 'unknown')
$ban_query[] = '(bi.ip_low1 = 255 AND bi.ip_high1 = 255
AND bi.ip_low2 = 255 AND bi.ip_high2 = 255
AND bi.ip_low3 = 255 AND bi.ip_high3 = 255
AND bi.ip_low4 = 255 AND bi.ip_high4 = 255)';
}
Security.php
-
if (preg_match('/^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/', $user_info[$ip_number], $ip_parts) == 1)
Security.php
il existe un $ip_number_v6 ?
Bon courage,pas sortis de l'auberge.
-
SMF est un gros morceau. C'est vrai un labyrinthe!
-
Effectivement, c'était dans une partie complètement différente (L'un dans configuration => sécurité et modération => anti-spam et l'autre dans Forum => Messages et sujets => paramètres des messages).
J'ai modifié
Temps d'attente requis entre deux envois en provenance d'une même adresse IP : 5 secondes
par
Temps d'attente requis entre deux envois en provenance d'une même adresse IP : 0 seconde
Merci corrector
-
Vous ne trouvez pas que cette histoire a un coté Y2K?
Le problème est conceptuellement simple, il faut remplacer un champ de nombres à X chiffres par des nombres à Y>X chiffres. Mais on ne sait pas précisèment où peuvent être traités ces données dans le programme (potentiellement n'importe où), alors on le découvre empiriquement et c'est CHIANT.
-
il existe un $ip_number_v6 ?
Bon courage,pas sortis de l'auberge.
Le code actuel considère une adresse IP comme mal formée si elle n'est pas sous la forme a.b.c.d. C'est un critère de validité textuel. Le logiciel manipule ces adresses sous une forme destinée à l'être humain ce que je trouve débile à la base.
Tu pourrais modifier le critère pour accepter les adresses IPv6, cela n'aurait probablement pas d'impact sur le reste du code. Une adresse est au final un identifiant arbitraire comme un numéro de tél qu'on stocke sans réfléchir au cas où l'administrateur en aurait besoin un jour.
Mais par contre le principe même de la protection anti-spam venant d'une même IP est affecté par IPv6 : si un abonné "ordinaire" a accès à 2**64 > 1,844e19 = 18.440.000.000.000.000.000.000, limiter à 1 messages / unité de temps / IP ne sert plus à grand chose. C'est la logique même du par adresse qui doit être changé, mais en quoi : par préfixe /64? Sachant que les abonnés Free reçoivent un /60 (pas entièrement utilisable en pratique via la Freebox, mais utilisable via un autre modem), et d'autres FAI fournissant une plus grande plage, quel doit être la taille du préfixe?
Et à l'autre opposé, le principe même de cette limite serait mis à mal par la généralisation des CG-NAT qui mettent des milliers d'utilisateurs sur quelques addresses IPv4.
La limitation des accès par IP, par opposition à par utilisateur inscrit, me semble plus compromise que jamais.
-
Mais par contre le principe même de la protection anti-spam venant d'une même IP est affecté par IPv6 : si un abonné "ordinaire" a accès à 2**64 > 1,844e19 = 18.440.000.000.000.000.000.000, limiter à 1 messages / unité de temps / IP ne sert plus à grand chose. C'est la logique même du par adresse qui doit être changé, mais en quoi : par préfixe /64? Sachant que les abonnés Free reçoivent un /60 (pas entièrement utilisable en pratique via la Freebox, mais utilisable via un autre modem), et d'autres FAI fournissant une plus grande plage, quel doit être la taille du préfixe?
À mon avis, de grosses bases de correspondance opérateur = préfixe seront construites tôt ou tard par les administrateurs système, avec une taille par défaut assignée aux plages peu connues tant qu'elles génèrent peu de trafic.
Et à l'autre opposé, le principe même de cette limite serait mis à mal par la généralisation des CG-NAT qui mettent des milliers d'utilisateurs sur quelques addresses IPv4.
Elles sont surtout vouées à se prendre des captchas type Cloudflare à l'entrée des gros et moyens sites, ou des trucs du genre. Sur le long terme, ce n'est pas très grave en soi si cette technologie est vouée à devenir un fallback peu répandu.
-
À mon avis, de grosses bases de correspondance opérateur = préfixe seront construites tôt ou tard par les administrateurs système, avec une taille par défaut assignée aux plages peu connues tant qu'elles génèrent peu de trafic.
Listes qu'il faudra consulter en ligne ou dont il faudra avoir une copie qu'on devra mettre à jour régulièrement...
Cela ajoute de la complexité à quelque chose qui était simpliste : 1 IP = 1 utilisateur
-
Le code actuel considère une adresse IP comme mal formée si elle n'est pas sous la forme a.b.c.d. C'est un critère de validité textuel. Le logiciel manipule ces adresses sous une forme destinée à l'être humain ce que je trouve débile à la base.
Oui, je suis d'accord.
Pour ce type de fonctionnalités qui ont un impact profond sur le développement, c'est certainement à décider avec ceux qui continuent à s'occuper du produit.
-
Autre modification : les recherches, les utilisateurs d'IPv6 étant vu comme un mème membre, j'ai modifié :
Délai nécessaire entre les recherches d'un même membre : 5 secondes
par :
Délai nécessaire entre les recherches d'un même membre : 0 secondes
-
Et les dév, ils peuvent se sortir les doigts et sortir une version gérant correctement IPv6?
-
C'est moi ou ce code est craignos?
$ban_query[] = '((' . $ip_parts[1] . ' BETWEEN bi.ip_low1 AND bi.ip_high1)
AND (' . $ip_parts[2] . ' BETWEEN bi.ip_low2 AND bi.ip_high2)
AND (' . $ip_parts[3] . ' BETWEEN bi.ip_low3 AND bi.ip_high3)
AND (' . $ip_parts[4] . ' BETWEEN bi.ip_low4 AND bi.ip_high4))';
-
J'ai encore eu une erreur!
-
J'ai encore un blocage pour flood!
C'est quoi ce truc encore?
-
Tu as été confronté a une limite en terme de MP postés ou de messages publics sur le site ?
Je "flood" encore le forum!!!
-
Cela ressemble a une protection supplèmentaire non désactivable, le nombre de MP étant par membre et non par IP dans l'interface d'Admin (Nombre de messages personnels qu'un utilisateur peut envoyer en une heure, réglé à 20 pour éviter trop de SPAM pour le parrainage Orange)
-
Pourquoi tu parles de MP?
-
Car la partie "Actus Bouygues" est une boite de messagerie privée.^^
Non, sérieusement, c'est juste Vivien qui se fait un fixette dessus, car la plupart des paramètres anti-flood se trouvent au niveau des mp.
Mais ce n'est visiblement pas à ce niveau que le problème perdure, dans ce cas.
-
Ah effectivement, on parles de message sur le forum en non e MP.
J'ai trouvé la protection : Temps d'attente requis entre deux envois en provenance d'une même adresse IP (Ici vous pouvez spécifier le temps minimal requis entre deux envois de messages en provenance d'un même utilisateur. Cette option peut être utilisée afin de contrer le pollupostage ("spamming").)
Il est réglé à 0, je viens de le passer à -1
Je ne sais pas ce que cela fait.
-
L'anti-flood de SMF utilise une table SQL pour logger les dernières opérations, qui d'après ce que je comprends est une table normale de la base de données, et non une table temporaire d'une base de données jetable.
Cela me parait horriblement inefficace.