Wir verwenden SSO, und seit einigen Tagen berichten einige unserer Mitglieder, dass sie nicht mehr auf ihr Konto zugreifen können, mit folgender Fehlermeldung:
Es liegt ein Problem mit Ihrem Konto vor. Bitte wenden Sie sich an den Administrator der Website.
Ich dachte zunächst, dies könnte auf ein Problem zurückzuführen sein, das ich bereits gemeldet habe. Daher habe ich geprüft, ob deren IP-Adresse unter „Gesperrte IPs" (Screened IPs) gelistet war – eine davon war es, aber nicht alle anderen.
Nachdem ich verbose sso logging aktiviert hatte, bat ich andere Benutzer, es erneut zu versuchen. In den Logs steht nun, dass ihre IP-Adresse blockiert ist:
Verbose SSO log: IP address is blocked xxx.xxx.xxx.xxx
Ich habe jedoch nochmals sorgfältig geprüft, und die IP-Adresse taucht nicht unter „Gesperrte IPs" auf. Auch eine direkte Abfrage der PostgreSQL-Tabelle screened_ip_addresses ergab keinen Eintrag für diese IP-Adresse.
Ich habe langsam keine Ideen mehr… Gibt es einen anderen Bereich, in dem IP-Adressen blockiert werden könnten, den wir überprüfen sollten? Oder werden IP-Adressen nur für sehr kurze Zeit in die Liste der „Gesperrten IPs" aufgenommen, sodass ich sie nach der Meldung nie mehr erfassen kann (innerhalb weniger Stunden)?
Um es klarzustellen: Wir fügen keine IP-Adressen manuell zu den „Gesperrten IPs" hinzu – sie scheinen automatisch hinzugefügt zu werden, wenn wir über die API ein Konto schließen (siehe Link oben). Wir konnten dies bisher nicht stoppen, auch nicht mit dem dokumentierten Parameter block_ip: false.
Das Problem, dass IPs zu den ‘Gescannten IPs’ hinzugefügt werden, ist ein separates Thema von dem, was ich hier melden möchte. Wir sehen Mitglieder, die nicht durch die ‘Gescannten IPs’ blockiert sind, aber sich angeblich wegen „IP-Adresse blockiert
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?
Das Problem lag nicht am verwendeten Endpunkt, sondern an den Parametern, da die API erwartet, dass boolesche Werte als die Zeichenketten ‘true’/‘false’ übergeben werden, was mir nicht bewusst war.
Es gibt noch einige andere Fehler, auf die ich oben gestoßen bin, bei denen ich nicht weiß, ob sie behoben werden sollen. Andernfalls kann dieser Vorgang geschlossen werden. Vielen Dank.