Donc, actuellement, je rencontre un goulot d’étranglement lors de la suppression des utilisateurs spammeurs et de leurs publications.
Je dois supprimer manuellement toutes les publications d’un utilisateur avant de le supprimer, attendre que cela soit traité pendant que le navigateur est ouvert, puis supprimer l’utilisateur.
Je ne peux traiter que 2 à 3 utilisateurs à la fois, même si le serveur dispose de 16 processeurs Xeon modernes, sinon je rencontre une erreur. Chaque opération prend plusieurs minutes. C’est un processus très fastidieux et lent pour le moment.
À mon avis, il serait préférable d’avoir une option « supprimer le spammeur/détruire l’utilisateur » qui ne nécessite pas de supprimer toutes les publications au préalable. Elle mettrait ensuite les tâches en file d’attente et les traiterait en arrière-plan (supprimer toutes les publications et supprimer l’utilisateur). De cette façon, la modération peut être effectuée rapidement et le traitement peut se faire en arrière-plan sans surcharge.
Une autre option serait de simplement supprimer l’utilisateur avant de supprimer ses publications. Ensuite, un cron s’exécuterait périodiquement pour rechercher et supprimer les publications orphelines. Je pense que cette option pourrait être préférable car elle résout tous les problèmes liés aux publications orphelines dans l’ensemble.
Ce serait également un gain de temps considérable si certaines de ces options étaient disponibles directement sur la carte de l’utilisateur depuis les discussions, afin que nous n’ayons pas à passer par le profil de l’utilisateur et la page d’administration pour accéder à ces options (suspendre, taire, supprimer/détruire).
Ces spammeurs utilisent-ils un mot ou une expression particulière ?
Vous pouvez l’ajouter à la liste des mots surveillés pour empêcher la publication des spams.
Vous pouvez ajuster temporairement les paramètres suivants pour vous permettre de supprimer les comptes des spammeurs sans trop de tracas : delete_user_max_post_age et delete_all_posts_max. Assurez-vous simplement de les réinitialiser aux valeurs par défaut une fois terminé, afin que les utilisateurs ne puissent pas simplement spammer et s’auto-supprimer.
J’ai déjà ajusté ces deux paramètres, mais le goulot d’étranglement est que la suppression de l’utilisateur et des publications prend vraiment beaucoup de temps.
Je me demande si limiter les options d’inscription ou imposer la double authentification (2FA) aux utilisateurs pourrait vous être utile dans votre cas ?
Respectueusement, je ne pense pas qu’il y ait quoi que ce soit de mal dans ma configuration en matière de limitation du débit pour les nouveaux utilisateurs. Il s’agit principalement de paramètres par défaut, avec certains ajustés pour être plus stricts que la valeur par défaut.
Les seules limitations de débit que j’ai observées pour les nouveaux utilisateurs (publication de sujets et de réponses uniquement) sont les suivantes :
nombre maximal de sujets le premier jour : la valeur par défaut est de 3 sujets – les spammeurs doivent simplement attendre 24 heures après leur premier message
nombre maximal de réponses le premier jour : la valeur par défaut est de 10 réponses – les spammeurs doivent simplement attendre 24 heures après leur premier message
limitation du débit pour la création de sujets par un nouvel utilisateur : la valeur par défaut est de 120 secondes entre les messages / 720 sujets par jour / 30 par heure
limitation du débit pour la création de messages par un nouvel utilisateur : la valeur par défaut est de 30 secondes entre les messages / 2880 messages par jour / 120 par heure
Veuillez me faire savoir si j’oublie quelque chose, j’espère que c’est le cas. Des précisions seraient appréciées.
ne sont pas protégés contre la suppression de contenu lorsqu’ils sont signalés
Je n’ai pas rencontré de problème à ce sujet grâce à la modification de delete_user_max_post_age et delete_all_posts_max.
Supprimer un spammeur est une opération en un clic avec les paramètres par défaut de Discourse. Cela a toujours été le cas.
De quelle option de suppression parlez-vous ? J’ai principalement utilisé celle de la page d’administration de l’utilisateur, où la suppression de tous les messages est requise avant de supprimer l’utilisateur.
Je me suis abstenu d’utiliser l’option de suppression d’utilisateur Akismet depuis la file d’examen, car il a été confirmé par l’équipe qu’elle ne supprime pas les messages de l’utilisateur (Discourse Akismet - #10)
Le bouton de suppression sur la page de profil de l’utilisateur me renvoie cette erreur après un long délai (s’ils ont des messages ou du contenu) : « Une erreur s’est produite lors de la suppression de cet utilisateur. Assurez-vous que tous les messages sont supprimés avant de tenter de supprimer l’utilisateur. »
Le drapeau > c’est du spam > supprimer le spammeur me donne la même erreur : « Une erreur s’est produite lors de la suppression de cet utilisateur. Assurez-vous que tous les messages sont supprimés avant de tenter de supprimer l’utilisateur. » C’est un peu irrégulier : cela a échoué pour un spammeur avec environ 500 messages, mais a fonctionné pour un spammeur avec environ 150 messages (malgré l’affichage du message d’erreur). Cela fonctionne bien pour les comptes n’ayant que quelques messages.
Comment diable un spammeur peut-il atteindre 500 messages ?! Cela implique que vous avez fortement modifié les paramètres par défaut de Discourse, car un nouvel utilisateur est limité par le taux de publication en tant que TL0, et dispose en plus d’une limite de publication pour le premier jour.
J’aurai besoin de beaucoup plus de détails, avec des dates et des heures. Il me semble que ce sont des utilisateurs qui se sont inscrits et ont participé de manière plus ou moins normale, et que vous les avez identifiés comme des spammeurs des semaines plus tard ? Pouvez-vous fournir 10 exemples de messages de ces utilisateurs pour que je puisse les examiner ?
J’apprécierais que vous ne mettiez pas de mots dans ma bouche en réécrivant complètement le titre de mon sujet pour le rendre objectivement inexact.
Oui, les spammeurs ne se contentent pas de spammer le premier jour. C’est la plus vieille astuce du livre des spams de forum : publier des présentations ou d’autres courts messages apparemment inoffensifs le premier jour pour « chauffer » le compte en vue de spammer plus tard (généralement pour contourner les approbations manuelles). Ou bien ils n’ont simplement pas été détectés dans les 24 premières heures.
Les nouveaux utilisateurs de niveau TL0 (24 heures après le premier message) sont limités par défaut à 2880 messages et 720 sujets par jour, veuillez m’éclairer si je me trompe.
Ils utilisent des spinners pour rendre chaque message unique et contourner le paramètre « minutes entre les messages uniques », par exemple en ajoutant des émojis, des caractères, des chiffres, etc., de manière aléatoire.
La mise en silence automatique des utilisateurs qui tapent vite sur leur premier message est facilement contournable et ne s’applique qu’au premier message.
Il est trop facile pour les spammeurs de créer des comptes en masse avec des ressources minimales en utilisant un grand pool de proxies. L’utilisation de l’ancienne astuce du point Gmail rend totalement impossible le blocage avec une instance Discourse standard (même si Akismet est utilisé). Vous êtes essentiellement à la merci de la motivation de quelqu’un à spammer votre forum. Voir : Protecting against gmail dot trick in Discourse et Suggestion: Wildcard Block Email Address
Bref, je partage ces insights tirés des tranchées anti-spam dans le but d’aider Discourse à devenir plus infaillible. Les fonctionnalités anti-spam sont vraiment mises à rude épreuve ici.
Les spammeurs ont deux options principales : créer plusieurs comptes et spammer un peu sur chacun, ou créer moins de comptes et spammer beaucoup sur chacun. Si vous devenez plus strict avec les limites de débit, ils répondront simplement en créant plus de comptes, sachant qu’il est si facile et impossible à bloquer de les créer grâce à l’astuce du point Gmail.
Ils peuvent également utiliser un domaine personnalisé avec une adresse de réception unique (catchall) pour avoir des adresses e-mail illimitées pour l’inscription, mais cela ne fonctionne que jusqu’à ce que je mette leur domaine e-mail sur liste noire, ce qui est une défense efficace. Cependant, il serait vraiment utile de pouvoir supprimer tous les comptes utilisant un domaine e-mail spécifique afin de les bannir rétroactivement rapidement et facilement. Encore mieux si cela était possible avec Gmail (et toutes les variations de l’adresse).
Ce dont j’ai parlé, c’est la possibilité de nettoyer le chaos plus rapidement et efficacement en arrière-plan : supprimer les spammeurs qui passent au travers des défenses. Et aussi que cela fonctionne comme prévu, par exemple que l’option « supprimer le spammeur » fonctionne pour les spammeurs ayant un nombre décent de messages.
Honnêtement, votre site semble pathologique. Il est tout simplement impossible que j’aie jamais vu un véritable spammeur atteindre 500 publications sur Discourse, encore moins 150… sur des milliers de sites hébergés au cours des cinq dernières années, y compris plusieurs que je gère moi-même. La seule chose qui me vient à l’esprit est le spam bamwar que vous pouvez rechercher si vous êtes curieux.
Pourriez-vous s’il vous plaît partager des détails précis comme mentionné plus tôt ? Sinon, je ne suis pas sûr que quelqu’un ici puisse vous aider :
Je veux dire, gérez-vous un site blackhat pour les spammeurs ?
J’ai vu ce sujet il y a quelque temps. Il semble que ce soit un problème assez grave qui persiste et qui est source de stress. Je ne sais pas si cela pourrait aider (cela pourrait aider pour les messages mais pas pour les inscriptions), mais avez-vous essayé ces paramètres ?
Nombre de messages à approuver (Le nombre de messages d’un nouvel utilisateur ou d’un utilisateur de niveau de base devant être approuvés)
Approuver sauf si niveau de confiance (Les messages des utilisateurs en dessous de ce niveau de confiance doivent être approuvés)
Approuver les nouveaux sujets sauf si niveau de confiance (Les nouveaux sujets des utilisateurs en dessous de ce niveau de confiance doivent être approuvés)
