Impossible de se connecter via SSO en raison d'adresses IP bloquées

Soutien SSO
6

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 ?