Utilizziamo l’SSO e, da qualche giorno, alcuni dei nostri membri segnalano di non riuscire ad accedere al proprio account con il seguente errore:
C’è un problema con il tuo account. Contatta l’amministratore del sito
Pensavo potesse essere dovuto a un problema che ho segnalato in precedenza, quindi ho verificato se il loro indirizzo IP fosse presente negli IP filtrati: uno di loro lo era… ma non tutti gli altri.
Dopo aver attivato verbose sso logging, ho chiesto ad altri utenti di riprovare e i log mostrano che il loro indirizzo IP è bloccato:
Verbose SSO log: IP address is blocked xxx.xxx.xxx.xxx
Tuttavia, ho controllato attentamente e l’indirizzo IP non appare tra gli IP filtrati. Ho anche consultato direttamente la tabella PostgreSQL screened_ip_addresses e non c’è alcuna voce per quell’indirizzo IP.
Sto esaurendo le idee… Esiste un’altra sezione dove gli indirizzi IP possono essere bloccati e che dovremmo esaminare? Oppure gli indirizzi IP vengono aggiunti agli IP filtrati solo per un brevissimo periodo e non riesco a individuarli dopo la segnalazione (questo accade nell’arco di poche ore)?
Per essere chiari, non aggiungiamo mai manualmente IP agli IP filtrati: sembrano essere aggiunti automaticamente quando chiudiamo un account tramite l’API (vedi il link sopra) e non siamo riusciti a impedire che ciò accada utilizzando il parametro documentato block_ip: false.
Il problema relativo agli indirizzi IP aggiunti agli IP filtrati è distinto da quello che sto cercando di segnalare qui. Stiamo riscontrando che alcuni membri non bloccati dagli IP filtrati non riescono ad accedere al proprio account tramite SSO, presumibilmente perché “l’indirizzo IP è bloccato”.
Esistono altre posizioni oltre agli IP filtrati che potrebbero bloccare gli indirizzi IP e che dovrei esaminare?
Sembra che tu stia chiamando la funzione “elimina come spammer”, che blocca automaticamente l’indirizzo IP e l’indirizzo email. Penso che dovresti rivedere quel codice. Dovresti usare “eliminazione semplice” come previsto dall’interfaccia utente, non “elimina come spammer”.
Potrebbe essere vero, ma il modo in cui stiamo eliminando gli utenti è discusso qui.
Non sono sicuro se si tratti di un problema separato, ma ho notato che la colonna “Corrispondenze” nella sezione IP schermati mostra 0 corrispondenze in tutte le voci. Ho controllato l’esportazione di quella tabella e conferma che tutti gli IP hanno 0 corrispondenze. Eppure, ogni giorno vediamo utenti bloccati dall’accesso tramite indirizzo IP (tramite SSO).
Tuttavia, guardando gli indirizzi email schermati, la maggior parte ha una corrispondenza! E c’è anche una colonna con gli indirizzi IP… quindi pensavo di aver trovato il colpevole, ma nessuno degli indirizzi IP che vengono bloccati è elencato nemmeno lì.
Questo è tratto dai nostri /logs di pochi minuti fa:
Ho anche controllato gli indirizzi email schermati e né l’indirizzo IP né l’indirizzo email dell’account che è stato appena bloccato dall’accesso risultano presenti.
Credo di aver individuato il problema (alla fine era dalla nostra parte), ma ci sono alcuni bug da segnalare. Anche se non mi sento a mio agio con questo stack, spero che qualcuno possa dare un’occhiata più approfondita.
Innanzitutto, la causa. Esaminando direttamente la tabella del database screened_ip_addresses, ho scoperto che stava bloccando due interi blocchi che non avrebbe dovuto (176.59.0.0/16 e 109.252.0.0/16). Onestamente non so come siano stati aggiunti e le due voci erano presenti da febbraio. C’è qualche pulsante nell’amministratore di Discourse per bloccare un intero blocco /16 in una sola volta!?
Comunque, è probabile che questo sia il colpevole del mio problema iniziale. Ci sono ancora alcuni problemi che il team di Discourse potrebbe voler esaminare, dato che è stato proprio questo a rendere la cosa particolarmente difficile da risolvere:
Quei range bloccati non appaiono nell’elenco degli IP filtrati per qualche motivo. Ho dovuto cercare direttamente nel database per trovarli. Tuttavia, utilizzando la ricerca con “176.59” o “109.252” li mostra. C’è un limite di risultati applicato su /admin/logs/screened_ip_addresses?
Nell’esportazione, appaiono come 176.59.0.0 e 109.252.0.0, cioè non mostrano alcuna informazione sul blocco. Questo vale anche per i range predefiniti (127.0.0.0/8, 10.0.0.0/8, ecc.) — nessuna maschera è mostrata nel file di esportazione.
Anche se queste voci hanno bloccato gli utenti, hanno un valore match_count pari a 0 e last_match_at è vuoto (per l’intera tabella). È intenzionale? Probabilmente non si vuole contare tutte le corrispondenze allow, ma se i blocchi non vengono contati, queste colonne sembrano inutilizzate/non necessarie. O forse l’accesso tramite SSO non attiva quelle corrispondenze?
Ancora una volta, devo dirti che sono quasi sicuro che tu stia chiamando “elimina come spammer” tramite l’API. Se ci sono abbastanza eliminazioni di spammer da indirizzi IP correlati, il blocco dell’indirizzo IP inizia ad ampliarsi automaticamente. Sono abbastanza convinto che sia questo ciò che stai osservando.
E questo, sì. Forse il motivo per cui la tua lista di IP filtrati è così grande è perché stai “eliminando come spammer” da molto tempo? Non vuoi questo.
Vuoi “Elimina solo”, non “Elimina e blocca”, ma quasi tutto ciò che hai pubblicato fornisce prove che stai chiamando “Elimina e blocca” tramite l’API..
Il problema non era l’endpoint utilizzato, ma i parametri, poiché l’API si aspetta che i valori booleani siano le stringhe ‘true’/‘false’, e non ne ero a conoscenza.
Ci sono ancora alcuni altri bug menzionati sopra che ho riscontrato, ma non so se debbano essere risolti. Altrimenti, questa può essere chiusa. Grazie.
