Impossibile SSO a causa di IP addresses bloccati

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?