Utilizziamo l’SSO per l’accesso e la creazione dell’account. Non esiste alcun altro modo per accedere o registrarsi sul nostro forum.
Tuttavia, l’elenco degli indirizzi IP filtrati contiene decine di indirizzi IP che vengono aggiunti automaticamente ogni giorno. È questo il comportamento previsto? Cosa determina l’aggiunta di un indirizzo IP all’elenco degli indirizzi IP filtrati?
Potrebbe essere, anche se penso di no? Sto utilizzando l’unico endpoint elimina un utente che ho trovato:
DELETE /admin/users/{id}.json
che ha un parametro block_ip impostato di default su true e che io imposto sempre su false. Gli indirizzi IP vengono comunque aggiunti agli indirizzi IP filtrati.
Potresti voler utilizzare Reverse engineer the Discourse API per vedere esattamente quali richieste vengono inviate quando elimini un utente, premendo il pulsante che dice Elimina solo
… perché posso dirti con certezza che se vedi indirizzi IP aggiunti all’elenco filtrato dopo l’eliminazione, stai assolutamente eliminando l’utente come spammer, ad esempio il pulsante centrale: elimina e blocca.
L’avevo già fatto e l’endpoint API per l’eliminazione è quello che ho sempre utilizzato, lo stesso per entrambe le azioni (solo eliminazione ed eliminazione+blocco) — l’unica differenza sta nei parametri utilizzati (block_ip, block_email, ecc.), come ho menzionato sopra.
Penso di aver finalmente capito qual era il problema con le mie richieste: l’API di Discourse vuole le stringhe ‘true’ e ‘false’ invece di valori truthy/falsy. Mia colpa per non aver notato l’avviso a riguardo nella documentazione.
Questo era probabilmente ciò che ha causato tutto questo pasticcio.
Dopo aver corretto i parametri truthy/falsy nelle stringhe ‘true’/‘false’, continuo a vedere voci aggiunte a IP schermati ed Email schermate quando elimino gli utenti.
Ecco i log di Rails per una chiamata API:
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)
E qui la richiesta effettuata tramite l’interfaccia web invece che chiamando l’API:
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)
Quindi, dopo alcuni test, sembra che i parametri per l’endpoint API /admin/users/{id}.json vengano sempre interpretati come true quando sono presenti, indipendentemente dal fatto che siano effettivamente impostati su ‘true’ o ‘false’?
Una volta iniziato a impostare solo i parametri che erano ‘true’, saltando quelli ‘false’, non vengono più aggiunte voci agli IP/Email schermati.
È questo il comportamento previsto? Non è quello che ho capito dalla documentazione.
Finché hai emulato il comportamento che osservi seguendo l’argomento Reverse engineer the Discourse API, dovresti stare tranquillo. Quali chiamate API stai osservando nel monitor di rete quando premi il pulsante “elimina solo”?
In alcuni casi, quando il JS non passa esplicitamente false al server, il server tratta qualsiasi valore presente come vero. È probabile che questo sia ciò che stai riscontrando qui.