Nous utilisons SSO et, depuis quelques jours, certains de nos membres signalent ne pas pouvoir accéder à leur compte avec l’erreur suivante :
Il y a un problème avec votre compte. Veuillez contacter l’administrateur du site.
J’ai pensé que cela pouvait être dû à un problème que j’avais déjà signalé, alors j’ai vérifié si leur adresse IP figurait dans les IP filtrées : l’une d’elles y était… mais pas toutes les autres.
Après avoir activé verbose sso logging, j’ai demandé à d’autres utilisateurs de réessayer et les journaux indiquent que leur adresse IP est bloquée :
Journal SSO détaillé : l'adresse IP est bloquée xxx.xxx.xxx.xxx
Cependant, j’ai vérifié à nouveau, et l’adresse IP n’apparaît pas dans les IP filtrées. J’ai également vérifié directement dans la table PostgreSQL screened_ip_addresses et aucune entrée ne correspond à cette adresse IP.
Je commence à manquer d’idées… Y a-t-il une autre section où les adresses IP peuvent être bloquées que nous devrions examiner ? Ou les adresses IP sont-elles ajoutées aux IP filtrées pendant très peu de temps et je ne les repère jamais après le signalement (quelques heures) ?
Pour être clair, nous n’ajoutons jamais manuellement d’IP aux IP filtrées — elles semblent être ajoutées automatiquement lorsque nous fermons un compte via l’API (voir le lien ci-dessus) et nous n’avons pas réussi à empêcher cela en utilisant le paramètre documenté block_ip: false.
Le problème des adresses IP ajoutées aux IP filtrées est un problème distinct de celui que je tente de signaler ici. Nous constatons que des membres ne sont pas bloqués par les IP filtrées, mais ne peuvent pas se connecter à leur compte via SSO, apparemment parce que « l’adresse IP est bloquée ».
Y a-t-il d’autres endroits, en dehors des IP filtrées, qui pourraient bloquer des adresses IP et que je devrais examiner ?
Il semble que vous appeliez la fonction « supprimer comme spammeur », qui bloque automatiquement l’adresse IP et l’adresse e-mail. Je pense que vous devriez revoir ce code. Vous souhaitez une « suppression simple » comme dans l’interface utilisateur, et non « supprimer comme spammeur ».
Cela peut être vrai, mais la façon dont nous supprimons les utilisateurs est discutée ici.
Je ne sais pas si c’est un problème distinct, mais j’ai remarqué que la colonne « Correspondances » dans la section « Adresses IP filtrées » affiche 0 correspondance pour toutes les entrées. J’ai examiné l’exportation de ce tableau, ce qui confirme que toutes les adresses IP ont 0 correspondance. Pourtant, chaque jour, nous constatons que des utilisateurs sont bloqués par adresse IP lors de la connexion (via SSO).
Cependant, en examinant les e-mails filtrés, la plupart ont une correspondance ! Et il y a aussi une colonne « Adresse IP »… j’ai donc pensé avoir trouvé le coupable, mais aucune des adresses IP bloquées n’y figure non plus.
Voici ce qui est indiqué il y a quelques minutes dans nos /logs :
Voici la recherche dans les adresses IP filtrées :
J’ai également consulté les e-mails filtrés, et ni l’adresse IP ni l’adresse e-mail du compte qui vient d’être bloqué lors de la connexion n’y figurent.
Je pense avoir trouvé le problème ici (au final, le problème venait de notre côté), mais il y a quelques bogues à signaler, bien que ce ne soit pas une stack avec laquelle je me sente à l’aise, donc j’espère que quelqu’un pourra mieux les examiner.
Tout d’abord, la cause. En examinant directement la table de base de données screened_ip_addresses, j’ai constaté qu’elle bloquait deux blocs entiers qu’elle ne devrait pas (176.59.0.0/16 et 109.252.0.0/16). Je ne sais vraiment pas comment ils ont été ajoutés et les deux entrées étaient présentes depuis février. Y a-t-il un bouton dans l’administration de Discourse pour bloquer un bloc /16 entier en une seule fois !?
Quoi qu’il en soit, cela est probablement la cause de mon problème initial. Il reste quelques problèmes que l’équipe de Discourse voudra peut-être examiner, car c’est ce qui a rendu cette situation particulièrement difficile à résoudre :
Ces plages bloquées n’apparaissent pas dans la liste des IPs filtrées pour une raison quelconque. J’ai dû consulter directement la base de données pour les trouver. Cependant, l’utilisation de la recherche avec “176.59” ou “109.252” les affiche. Y a-t-il une limite de résultats appliquée sur /admin/logs/screened_ip_addresses ?
Lors de l’exportation, elles s’affichent sous la forme 176.59.0.0 et 109.252.0.0, c’est-à-dire qu’aucune information de bloc n’est affichée. Cela est vrai même pour les plages par défaut (127.0.0.0/8, 10.0.0.0/8, etc.) — aucun masque n’est affiché dans le fichier d’exportation.
Bien que ces entrées bloquent des utilisateurs, elles ont une valeur match_count de 0 et last_match_at est vide (pour toute la table). Est-ce intentionnel ? On ne veut probablement pas compter toutes les correspondances allow, mais si les blocages ne sont pas comptés, ces colonnes ne semblent pas utilisées ou nécessaires. Ou peut-être que la connexion via SSO ne déclenche pas ces correspondances ?
Encore une fois, je dois vous dire que je suis presque certain que vous appelez « Supprimer comme spammeur » via l’API. S’il y a suffisamment de suppressions de spammeurs provenant d’adresses IP liées, l’interdiction d’adresse IP commence à s’élargir automatiquement. Je suis assez convaincu que c’est ce que vous observez ici.
Et cela, oui. Peut-être que la raison pour laquelle votre liste d’adresses IP filtrées est si grande, c’est parce que vous « supprimez comme spammeur » depuis longtemps ? Vous ne voulez pas cela.
Vous voulez « Supprimer uniquement », et non « Supprimer et bloquer », mais presque tout ce que vous avez publié indique que vous appelez « Supprimer et bloquer » via l’API..
Le problème ne venait pas du point de terminaison utilisé, mais des paramètres, car l’API attend que les booléens soient transmis sous forme de chaînes de caractères ‘true’ ou ‘false’, ce dont je n’avais pas conscience.
Il reste quelques autres bogues mentionnés ci-dessus sur lesquels je ne sais pas s’ils doivent être corrigés. Sinon, ce ticket peut être clôturé. Merci.
