Dieses Plugin nutzt die ProxyTracer-API, um VPN-, Tor- und Proxy-Datenverkehr in Discourse zu erkennen und zu blockieren.
Funktionen
Es bietet Ihnen eine feine Kontrolle über die Blockierung von VPN-, Tor- und Proxy-Nutzern bei neuen Registrierungen, der Authentifizierung bestehender Benutzer oder global für alle Seitenbesucher. Wenn Sie es in Ordnung finden, dass VPN-, Tor- und Proxy-Nutzer Lesezugriff auf Ihr Forum haben, können Sie API-Anfragen sparen und die Blockierung nur für Registrierung und Authentifizierung aktivieren.
Es nutzt Caching, um aktuelle IP-Adressenbewertungen zu speichern, wodurch API-Anfragen reduziert und die Latenz verringert wird. Sie können in den Einstellungen festlegen, wie lange eine IP-Adressenbewertung gespeichert werden soll.
Im Falle eines API-Timeouts oder Netzwerkfehlers priorisiert das Plugin den Benutzerzugriff, um eine flächendeckende Sperre zu verhindern. Dieses Verhalten kann über die Optionen angepasst werden.
Integrierte Unterstützung für die Whitelisting von exakten IP-Adressen und CIDR-Subnetzen.
Navigieren Sie in Ihrem Discourse-Administrationsbereich zu Admin → Plugins → ProxyTracer, um die Einstellungen von ProxyTracer zu finden.
Geben Sie Ihren API-Schlüssel in das Feld ProxyTracer API Key ein.
Aktivieren Sie die Schutzparameter, indem Sie Enabled during Signup, Enabled during Login und/oder Enabled for All Visitors umschalten.
Fügen Sie vertrauenswürdige IPs oder CIDR-Bereiche zur Liste Whitelisted IPs hinzu.
(Optional) Passen Sie das API-Timeout und die Redis-Cache-Dauer an die spezifischen Verkehrsbedürfnisse Ihres Servers an.
(Optional) Passen Sie die Blockiermeldung an, die blockierten Nutzern angezeigt wird. Beispielsweise können Sie Anweisungen hinzufügen, wie sich Nutzer bei der Forum-Administration melden können, falls sie glauben, dass die Blockierung unbegründet ist und sie nicht über einen Proxy, Tor oder VPN auf die Seite zugreifen.
Hier finden Sie eine Tabelle mit den Einstellungen und deren Beschreibungen:
Name
Beschreibung
API Timeout (ms)
Wie lange auf eine Antwort der API gewartet wird, bevor ein Timeout ausgelöst wird.
Cache Duration (hours)
Wie lange eine IP-Adresse im Cache behalten wird, bevor die API erneut abgefragt wird.
Fail Open on Error
Falls die API abstürzt oder ein Timeout auftritt, wird der Benutzer trotzdem zur Registrierung/Anmeldung zugelassen, um eine Sperrung aller Nutzer zu verhindern.
Enabled during Signup
Blockiert Proxies und VPNs, wenn sich ein neuer Benutzer registriert.
Enabled during Login
Blockiert Proxies und VPNs, wenn sich ein bestehender Benutzer anmeldet.
Enabled for All Visitors
Blockiert Proxies und VPNs vom Zugriff auf oder der Anzeige beliebiger Seiten im Forum. (Warnung: Dies prüft jeden Besucher und beansprucht Ihr API-Kontingent stark).
Block Message
Die genaue Fehlermeldung, die dem Benutzer angezeigt wird, wenn er blockiert wird.
Whitelisted IPs
IP-Adressen oder CIDR-Bereiche (z. B. 192.168.1.0/24), die strikt erlaubt sind, um die Blockierung zu umgehen.
[quote] Ausgesperrt? Wenn Sie Ihre eigene IP-Adresse versehentlich blockiert haben, während Sie ProxyTracer konfiguriert haben (z. B. weil Sie derzeit mit einem VPN verbunden sind), können Sie den Zugriff ganz einfach mithilfe des integrierten „Sicheren Modus
Das kommt darauf an. Es gibt eine Site-Einstellung, mit der Sie den abgesicherten Modus deaktivieren können. Das ist hilfreich für die Komponente „Gated Topic
Du hast hier völlig recht. Ich kann das durch eigene Tests mit einer frisch installierten Discourse-Instanz bestätigen. Ich habe die Dokumentation bereits mit Anweisungen aktualisiert, die tatsächlich funktionieren: Dazu loggt man sich auf dem Server ein und deaktiviert das Add-on manuell:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Ich kann bestätigen, dass der **Sicherheitsmodus unzugänglich ist, wenn die Einstellung „Für alle Besucher aktiviert
Ich teste gerade euren Service und würde gerne wissen, ob es Konflikte mit der Datei ‘templates/cloudflare.template.yml’ gibt und ob das Plugin auch bei zukünftigen Updates des Discourse-Kerns unterstützt werden wird.
Danke fürs Testen! Die Dokumentation in der README.md bezüglich der Cloudflare-Integration empfiehlt ausdrücklich die Einbeziehung von "templates/cloudflare.template.yml", da dies erforderlich ist, um sicherzustellen, dass Discourse die echte IP-Adresse des Benutzers ermittelt, wenn sich das Forum hinter Cloudflare befindet. Es besteht daher kein Widerspruch zu dieser Vorlage; tatsächlich ist deren Einbeziehung notwendig.
Und ja, wir verpflichten uns, die Kern-Updates von Discourse zu verfolgen, um die vollständige Kompatibilität mit neueren Versionen sicherzustellen.
Ich fragte mich, ob die Einführung einer Option, die – anstelle des Blockierens von Nutzern – lediglich das Bestehen eines hCaptcha erfordert, und ob die Festlegung dieser Option als Standard einen guten Kompromiss darstellen würde. Denn sie fügt genau so viel Reibung hinzu, dass es für Spammer und Ban-Umgeher schwerer wird, während legitime Nutzer, die ihre Online-Privatsphäre über VPNs, Tor und ähnliche Dienste schützen möchten, weiterhin problemlos Zugang haben. Natürlich hätten Administratoren, die weiterhin bei diesen Netzwerken auf vollständige Sperren bestehen möchten, immer noch diese Option. Was haltet ihr davon?
Vielen Dank! Ich habe gerade einen Test in einer Sandbox durchgeführt und es funktioniert einwandfrei.
Gedenkt ihr, eine Funktion hinzuzufügen, die sich auf IPs/ASNs von Mobilfunknetzen bezieht? Auf meinem Forum kommt es häufig vor, dass ein Benutzer sein Breitbandnetz verlässt und auf ein 4G/5G-Netz des Mobilfunkanbieters wechselt, um eine andere IP-Adresse zu erhalten und damit Versuche unternimmt, Registrierungs- oder Login-Einschränkungen in Discourse zu umgehen.
Es wäre interessant, wenn man erkennen könnte, ob eine IP-Adresse zu einer ASN eines Mobilfunkanbieters gehört, und optional die Möglichkeit hätte, diese IPs bei der Registrierung/Beim Login anders zu behandeln.
Vielleicht liegt das etwas außerhalb des Anwendungsbereichs von ProxyTracer, da es nicht unbedingt mit VPNs/Proxys zu tun hat, aber es wäre nützlich für ein spezifisches Problem, wie Discourse mit Kontolimits pro IP-Adresse umgeht.
Im Fall von hCaptcha nutze ich es bereits in meiner Installation und es funktioniert sehr gut! Vielleicht könnte man den Plugin, der scheinbar bereits im Discourse-Kern enthalten ist, mit deinem Plugin kombinieren – eine zusätzliche Funktion, vielleicht?
Ich mag die Idee, den vollständigen Block zu beibehalten, denn das ist ja das Ziel. Aber was die IPv4- und IPv6-Adressen von festen und mobilen Netzwerken betrifft, scheint es sehr nützlich zu sein, den Zugang über Challenges zu erschweren, da KI gerne Forenkonten erstellt.
Hallo, danke, dass du meine Antwort in Betracht gezogen hast. Das Thema interessiert mich wirklich sehr, und ich empfinde die Umsetzung als besonders heikel für alle, sowohl für Nutzer als auch für Administratoren.
Ehrlich gesagt fühle ich mich wie ein Roboter, der CAPTCHAs löst, um zu beweisen, dass er ein Mensch ist, während ich absichtlich so tue, als wäre ich ein Bot. In verwandten Themen habe ich bereits erwähnt, dass sich mir die Umsetzung von Anubis (POW) deutlich angenehmer und funktionaler anfühlt.
Ich verstehe, dass dies außerhalb des Rahmens dieses Projekts liegt, aber aus meiner Perspektive kann ich analysieren, dass die Verwendung des von dir erwähnten CAPTCHAs machbar wäre und buchstäblich keine Nutzer blockieren würde, die ihre Privatsphäre schätzen und beitragen möchten, ohne ausgeschlossen zu werden.
Damit ProxyTracer effektiv funktioniert, muss die Discourse-Anwendung die echte Client-IP-Adresse erhalten.