Wir verwenden SSO für die Anmeldung und die Kontoerstellung. Es gibt keine andere Möglichkeit, sich in unserem Forum anzumelden oder zu registrieren.
Allerdings enthält die Liste der blockierten IP-Adressen Dutzende von Einträgen, die täglich automatisch hinzugefügt werden. Ist das zu erwarten? Warum wird eine IP-Adresse in die Liste der blockierten IP-Adressen aufgenommen?
Der einzige Weg, an den ich denken kann, ist, wenn Sie ein Konto löschen und die Option „Spammer löschen“ wählen.
Guter Punkt – das passiert, wenn wir ein Konto über die API entfernen, wird die IP zu den „Screened IPs
[quote=“codinghorror, post:4, topic:192588”]
Es klingt so, als würdest du die Funktion „Löschen als Spammer
Vielleicht möchten Sie Reverse engineer the Discourse API konsultieren, um genau zu sehen, welche Anfragen gesendet werden, wenn Sie einen Benutzer löschen und auf die Schaltfläche klicken, die besagt Nur löschen
… denn ich kann Ihnen mit Sicherheit sagen, dass Sie, wenn Sie nach dem Löschen sehen, dass IP-Adressen zur Liste der blockierten Adressen hinzugefügt werden, den Benutzer auf jeden Fall als Spammer löschen, also über die mittlere Schaltfläche – löschen und blockieren.
Das hatte ich bereits erledigt. Der API-Endpunkt zum Löschen ist derselbe, den ich für beide Aktionen verwende (nur löschen und löschen & blockieren) – der einzige Unterschied liegt in den Parametern, die damit verwendet werden (block_ip, block_email, …), die ich oben erwähnt habe.
Ich glaube, ich habe endlich herausgefunden, was das Problem mit meinen Anfragen war: Die Discourse-API erwartet die Strings ‘true’ und ‘false’ anstelle von truthy/falsy-Werten. Es war mein Fehler, dass ich den Hinweis dazu nicht in der Dokumentation bemerkt habe.
Das war wahrscheinlich der Grund für all dieses Durcheinander.
Ich habe mich vielleicht zu früh gefreut. 
Nachdem ich die wahrheitswerten/falschen Parameter auf die Strings ‘true’/‘false’ korrigiert habe, werden beim Löschen von Benutzern weiterhin Einträge zu „Gescannten IPs“ und „Gescannten E-Mails“ hinzugefügt.
Hier sind die Rails-Logs für einen API-Aufruf:
Started DELETE "/admin/users/9553.json" for 123.123.123.123 at 2021-06-10 00:01:21 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"delete_posts"=>"false", "block_email"=>"false", "blocked_urls"=>"false", "block_ip"=>"false", "id"=>"9553"}
Can't verify CSRF token authenticity.
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 8ms (Views: 1.4ms | ActiveRecord: 0.0ms | Allocations: 2301)
Und hier ist die Anfrage, wenn sie über die Weboberfläche statt über die API durchgeführt wird:
Started DELETE "/admin/users/49.json" for 123.123.123.123 at 2021-06-10 08:24:47 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"context"=>"/admin/users/49/XXX", "delete_posts"=>"true", "id"=>"49"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 23ms (Views: 4.7ms | ActiveRecord: 0.0ms | Allocations: 1778)
Nach einigen Tests scheint es also, als würden die Parameter für den API-Endpunkt /admin/users/{id}.json immer als wahr interpretiert, wenn sie vorhanden sind, unabhängig davon, ob sie tatsächlich auf ‘true’ oder ‘false’ gesetzt sind?
Sobald ich nur noch die Parameter setzte, die ‘true’ waren, und die ‘false’-Parameter übersprang, wurden keine weiteren Einträge zu den Gescannten IPs/E-Mails hinzugefügt.
Ist dies das beabsichtigte Verhalten? Das entspricht nicht meinem Verständnis aus der Dokumentation.
Solange Sie das Verhalten nachgeahmt haben, das Sie beobachten, wenn Sie dem Thema Reverse engineer the Discourse API folgen, sollte alles in Ordnung sein. Welche API-Aufrufe sehen Sie im Netzwerkmonitor, wenn Sie auf die Schaltfläche „Nur löschen
In einigen Fällen, wenn JS nicht explizit false an den Server übergibt, behandelt der Server jeden vorhandenen Wert als wahr. Das ist höchstwahrscheinlich das Problem, das Sie hier haben.