Grazie per aver chiarito, seguirò i consigli e finora il servizio è ottimo, non vedo l’ora di ricevere l’aggiornamento con la nuova funzione e altre novità 
1 Mi Piace
Siamo lieti di rilasciare una nuova versione beta, ricca di alcune funzionalità molto attese:
- Gli amministratori possono ora scegliere tra il blocco totale (block) o la verifica delle connessioni sospette tramite CAPTCHA (captcha). Attualmente sono supportati sia Cloudflare Turnstile che hCaptcha.
- Token di autorizzazione indipendenti per le azioni visitor, login, signup, email_login e forgot_password, per garantire che la risoluzione di una verifica in un contesto non conceda un accesso indiscriminato ad altri.
- Analisi visive interattive a 30 giorni (estendibili) basate su Chart.js, che mostrano il totale delle verifiche rispetto al traffico proxy/VPN rilevato.
- Log che visualizzano gli ultimi 500 tentativi bloccati, inclusi timestamp, indirizzo IP, nome utente (se abilitato) e azione.
Per testare questa nuova versione beta, è sufficiente modificare la riga nel file containers/app.yml da:
git clone https://github.com/proxytracer/discourse-proxytracer.git
a:
git clone -b beta-testing https://github.com/proxytracer/discourse-proxytracer.git
Dopo aver eseguito ./launcher rebuild app, tutto dovrebbe essere pronto per l’uso.
Saremmo lieti di ricevere qualsiasi feedback o suggerimento su come migliorare ulteriormente il plugin.
2 Mi Piace
Wow, è stato più di quanto mi aspettassi. Apprezzo il tuo impegno per Discourse e riconosco il valore del tuo servizio, e intendo continuare a pagare e a fornire feedback.
Non so in quale giurisdizione sia stata costituita la vostra azienda, ma per quanto riguarda, ad esempio, il fatto che catalogare le reti di VPN e proxy sia un gioco del gatto e del topo, sarei disposto a inviare informazioni specifiche sulle reti che hanno superato il vostro filtro, in modo da poter contribuire a migliorare la rilevazione. Vivendo in Brasile, devo rispettare determinate regole simili al GDPR, chiamate LGPD, quindi credo che sarebbe interessante capire prima quali dati sarebbero necessari e come verrebbero trattati. Detto questo, si tratta di un’ulteriore riflessione su come le istanze, che utilizzino Discourse o Flarum, possano contribuire e su come si possa ottenere un vantaggio reciproco per entrambe le parti.
1 Mi Piace
Sto clonando la beta ora, presto darò un feedback.
1 Mi Piace
Ho fatto un piccolo test e ha funzionato come previsto! Ora non resta che aspettare i tentativi in produzione, grazie per la disponibilità a introdurre queste nuove funzionalità.
1 Mi Piace
Grazie per le belle parole, siamo lieti che l’estensione aggiornata si sia rivelata utile per te!
Stiamo pensando di aspettare un po’ di tempo in più per eventuali altri feedback o segnalazioni di bug prima di spostarla nel canale stabile.
1 Mi Piace
Ho notato che, quando il login viene effettuato tramite SSO, essendo questa un’azione di login, non viene assegnato né un utente né un indirizzo e-mail.
Un altro dettaglio è che l’azione create viene registrata anche quando l’account esiste già. Ad esempio, ieri ho effettuato un test utilizzando un account alternativo che era già esistente, ma il log ha registrato l’azione come se l’account fosse stato creato in quel momento. Questo può generare un po’ di confusione nell’interpretazione dei log.
Infine, tornando alla questione delle reti mobili, ho notato che si è verificato un falso positivo. Le ASN 26599 e 22085, che è un operatore brasiliano di dati mobili, sono apparse nei log di blocco sia in tentativi tramite SSO sia in un tentativo che coinvolgeva un utente esistente.
Qui torno alla stessa questione della confusione nei log: un utente ha tentato di accedere al proprio account utilizzando un range appartenente a questa ASN, ma l’azione appare come create, quando in realtà non c’è stata alcuna creazione di account. Questo può rendere difficile distinguere tra un tentativo di creazione di un account e un tentativo di login di un utente già esistente.