Questo plugin utilizza l’API ProxyTracer per rilevare e bloccare il traffico VPN, Tor e proxy in Discourse.
Funzionalità
Offre un controllo preciso sul blocco di utenti VPN, Tor e Proxy durante le nuove registrazioni, l’autenticazione di utenti esistenti o globalmente per tutti i visitatori del sito. Se sei d’accordo che gli utenti VPN, Tor e Proxy abbiano accesso in lettura al tuo forum, puoi risparmiare sulle richieste API abilitando la funzionalità solo per registrazione e autenticazione.
Utilizza la memorizzazione nella cache per conservare le valutazioni recenti degli indirizzi IP, riducendo così le richieste all’API e diminuendo la latenza. Puoi controllare per quanto tempo ricordare una valutazione dell’indirizzo IP nelle impostazioni.
In caso di timeout dell’API o guasto della rete, il plugin dà priorità all’accesso degli utenti per prevenire blocchi su larga scala. Questo comportamento può essere modificato tramite le opzioni.
Supporto integrato per l’aggiunta di whitelist di indirizzi IP esatti e sottoreti CIDR.
Accedi al pannello di amministrazione di Discourse: Admin → Plugins → ProxyTracer per trovare le impostazioni di ProxyTracer.
Inserisci la tua chiave API nel campo ProxyTracer API Key.
Abilita i parametri di protezione attivando Enabled during Signup, Enabled during Login e/o Enabled for All Visitors.
Aggiungi eventuali IP fidati o intervalli CIDR alla lista Whitelisted IPs.
(Opzionale) Regola il timeout dell’API e i limiti di durata della cache Redis in base alle esigenze specifiche del traffico del tuo server.
(Opzionale) Personalizza il messaggio di blocco visualizzato agli utenti bloccati. Ad esempio, puoi aggiungere istruzioni per contattare l’amministrazione del sito nel caso in cui ritengano che il blocco non sia giustificato e che non stiano accedendo tramite proxy, Tor o VPN.
Ecco una tabella delle impostazioni e delle relative descrizioni
Nome
Descrizione
API Timeout (ms)
Tempo di attesa per la risposta dell’API prima del timeout.
Cache Duration (hours)
Durata di conservazione di un indirizzo IP prima di effettuare un nuovo controllo all’API.
Fail Open on Error
Se l’API si blocca o va in timeout, consente comunque all’utente di registrarsi o accedere per evitare di bloccare tutti.
Enabled during Signup
Blocca proxy e VPN quando un nuovo utente tenta di registrarsi.
Enabled during Login
Blocca proxy e VPN quando un utente esistente tenta di accedere.
Enabled for All Visitors
Blocca proxy e VPN dall’accesso o dalla visualizzazione di qualsiasi pagina del forum. (Attenzione: questo controlla ogni visitatore e utilizza intensamente la tua quota API).
Block Message
Il messaggio di errore esatto mostrato all’utente quando viene bloccato.
Whitelisted IPs
Indirizzi IP o intervalli CIDR (ad es. 192.168.1.0/24) che possono bypassare il blocco.
Configurazione di Rete: Cloudflare e Proxy Inversi
Affinché ProxyTracer funzioni correttamente, l’applicazione Discourse deve ricevere il vero indirizzo IP del client.
Per garantire il corretto inoltro degli indirizzi IP, puoi seguire queste istruzioni dettagliate.
Accesso di Emergenza
Se ti sei bloccato fuori, puoi riaccedere seguendo questi semplici passaggi.
Se desideri effettuare dei test, puoi registrarti su ProxyTracer e ottenere alcuni crediti API gratuiti per le prove.
Dipende. C’è un’impostazione del sito che permette di disattivare la modalità sicura, utile per il componente dei topic protetti e per altri componenti/plugin che gli utenti non dovrebbero poter disattivare facilmente (pubblicità, accesso per gli ospiti, …). Tuttavia, quando sei disconnesso, ciò renderebbe più difficile per gli amministratori utilizzare la modalità sicura. Penso che possano comunque attivarla tramite admin-login.
Per questo plugin, dubito che la modalità sicura sia d’aiuto. La modalità sicura disattiva solo la parte front-end dei plugin, mentre questo plugin è scritto interamente in Ruby. Quindi, non credo che disabilitare le personalizzazioni JavaScript sia di alcuna utilità. Questo fatto mi rende un po’ scettico riguardo al plugin, così come il fatto che includa un file about.json come se fosse un componente di tema. Ma alla fine, ognuno è responsabile del codice che installa sul proprio forum.
Hai assolutamente ragione su questo punto; posso confermarlo attraverso i miei test su un’istanza di Discourse appena creata. Ho aggiornato la documentazione con istruzioni che funzionano davvero, che consistono nell’accedere al server e disabilitare manualmente il componente aggiuntivo:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Posso confermare che la modalità sicura è inaccessibile quando l’impostazione “Abilitata per tutti i visitatori” è attiva e qualcuno tenta di accedere alla modalità sicura mentre si connette tramite una VPN/proxy.
Effettivamente, un about.json è ridondante per i plugin standard; l’ho rimosso dal repository.
Grazie per tutti i tuoi feedback @Moin. Se hai altre osservazioni o suggerimenti, sentiti libero di lasciarli qui. Il codice è completamente open source e qualsiasi contributo è benvenuto: GitHub - ProxyTracer/discourse-proxytracer.
Sto testando il vostro servizio e vorrei sapere se ci sono conflitti con ‘templates/cloudflare.template.yml’ e se il plugin supporterà le eventuali aggiornamenti del core di Discourse.
Grazie per i test! La documentazione nel file README.md relativa all’integrazione con Cloudflare raccomanda chiaramente di includere "templates/cloudflare.template.yml", poiché è necessario per garantire che Discourse estragga l’IP reale dell’utente quando il forum si trova dietro Cloudflare. Di conseguenza, non c’è alcun conflitto con tale template; anzi, la sua inclusione è indispensabile.
E sì, siamo impegnati a seguire gli aggiornamenti del core di Discourse per garantire la piena compatibilità con le versioni più recenti.
Mi chiedevo se l’inclusione di un’opzione che, anziché bloccare gli utenti, richiedesse semplicemente il superamento di un hCaptcha, rendendo tale opzione quella predefinita, potesse rappresentare un buon compromesso. Aggiunge infatti solo l’attrito necessario per rendere più difficile l’attività di spammer e di chi evade i ban, consentendo al contempo agli utenti legittimi di proteggere la propria privacy online tramite VPN, Tor e strumenti simili. Naturalmente, gli amministratori che desiderassero continuare ad applicare il blocco totale a quelle reti avrebbero comunque a disposizione tale opzione. Che ne pensate?
Molte grazie! Ho appena fatto un test in un ambiente sandbox e funziona perfettamente.
State pensando di aggiungere qualche funzionalità relativa agli IP/ASN delle reti mobili? Una situazione che si verifica spesso nel mio forum è che l’utente esca dalla rete a banda larga e passi a una rete 4G/5G dell’operatore per ottenere un IP diverso e, in questo modo, tentare di aggirare le restrizioni di registrazione o accesso su Discourse.
Sarebbe interessante poter identificare quando l’IP appartiene a un ASN di un operatore mobile e, opzionalmente, consentire che questi IP vengano trattati in modo diverso durante la registrazione/accesso.
Forse questo è un po’ fuori dallo scope di ProxyTracer, dato che non ha necessariamente a che fare con VPN/proxy, ma sarebbe utile per un problema specifico su come Discourse gestisce i limiti di account per IP.
Nel caso di hCaptcha, lo sto già usando nella mia installazione e funziona molto bene! Forse una combinazione del plugin che sembra già presente nel core di Discourse con il tuo plugin, chissà, una funzionalità extra?
Mi piace l’idea di mantenere il blocco totale, dopotutto questo è l’obiettivo, ma per quanto riguarda gli indirizzi IPv4 e IPv6 delle reti fisse e mobili, sembra molto utile rendere più difficile l’accesso tramite sfide, dato che l’IA ama creare account nei forum.
Ciao, grazie per aver preso in considerazione la mia risposta. È un argomento che mi interessa davvero e lo ritengo un’implementazione particolarmente delicata per tutti, sia come utenti che come amministratori.
Onestamente, mi sento come un robot che completa CAPTCHA per dimostrare di essere umano, agendo deliberatamente come un bot. In argomenti correlati ho già menzionato che l’implementazione di Anubis (POW) mi sembra molto più piacevole e funzionale.
Capisco che questo esca dall’ambito del progetto, ma da ciò che posso analizzare dalla mia prospettiva, l’uso del CAPTCHA da te menzionato sarebbe fattibile e potrebbe letteralmente non bloccare gli utenti che valorizzano la propria privacy e desiderano contribuire senza essere tenuti all’esterno.