Kein SSO wegen blockierter IP-Adressen

Unterstützung SSO
6

Ich glaube, ich habe das Problem gefunden (am Ende lag es an uns), aber es gibt einige Bugs zu melden, auch wenn ich mit diesem Stack nicht so vertraut bin. Daher hoffe ich, dass jemand genauer hinschauen kann.

Zuerst die Ursache. Beim direkten Betrachten der Datenbanktabelle screened_ip_addresses stellte ich fest, dass sie zwei ganze Blöcke blockierte, die es nicht sollten (176.59.0.0/16 und 109.252.0.0/16). Ehrlich gesagt weiß ich nicht, wie sie hinzugefügt wurden, und die beiden Einträge waren seit Februar dort. Gibt es im Discourse-Admin-Bereich einen Button, um einen gesamten /16-Block auf einmal zu blockieren!?

Wie auch immer, das ist wahrscheinlich der Übeltäter für mein ursprüngliches Problem. Es gibt dennoch einige Probleme, die das Discourse-Team untersuchen sollte, da diese es besonders schwierig gemacht haben, das Problem zu beheben:

  • Diese blockierten Bereiche erscheinen aus irgendeinem Grund nicht in der Liste der „Screened IPs“. Ich musste direkt in der Datenbank nachschauen, um sie zu finden. Die Suche mit „176.59“ oder „109.252“ zeigt sie jedoch an. Gibt es ein Ergebnislimit für /admin/logs/screened_ip_addresses?

  • Beim Export werden sie als 176.59.0.0 und 109.252.0.0 angezeigt, d. h., es werden keine Blockinformationen angezeigt. Das gilt auch für die Standardbereiche (127.0.0.0/8, 10.0.0.0/8, usw.) – im Export-Datei wird keine Maske angezeigt.

  • Obwohl diese Einträge Benutzer blockieren, haben sie einen match_count-Wert von 0 und last_match_at ist leer (für die gesamte Tabelle). Ist das beabsichtigt? Wahrscheinlich möchte man nicht alle allow-Übereinstimmungen zählen, aber wenn die Blockierungen nicht gezählt werden, scheinen diese Spalten nicht verwendet/benötigt zu werden. Oder vielleicht löst die Anmeldung über SSO diese Übereinstimmungen nicht aus?