This plugin uses the ProxyTracer API to detect and block VPN, Tor and proxy traffic in Discourse.
Features
It gives you fine control over blocking VPN, Tor and Proxy users during new user registrations, existing user authentication, or globally for all site visitors. If you’re fine with VPN, Tor and Proxy users having read access to your forum then you can save on API requests and only enable it for user registration and authentication.
It uses caching to store recent IP address evaluations thus saving requests to the API and lowering latency. You can control how long to remember an IP address evaluation in the settings.
In the event of an API timeout or network failure, the plugin prioritizes user access to prevent wide-scale lockouts. This behavior can be changed through the options.
Built-in support for exact IP and CIDR subnet whitelisting.
Navigate to your Discourse administration panel: Admin → Plugins → ProxyTracer to find ProxyTracer’s settings.
Input your API key into the ProxyTracer API Key field.
Enable the protection parameters by toggling Enabled during Signup, Enabled during Login and/or Enabled for All Visitors.
Add any trusted IPs or CIDR ranges to the Whitelisted IPs list.
(Optional) Adjust the API timeout and Redis cache duration limits to suit your server’s specific traffic requirements.
(Optional) Customize the Block Message that appears to blocked users. For instance, you can add instructions for contacting the administration of the site in case they believe that the block isn’t warranted and that they’re not accessing the site through a proxy, Tor or VPN.
It depends. There is a site setting that allows you to disable safe mode, which is helpful for the gated topic component and other components/plugins users shouldn’t easily disable like that (advertising, guest gate, …). But while you are logged out, that would also make using safe mode more difficult for admins. I think they can still enable it using admin-login.
For this plugin, I doubt safe mode helps. Safe mode disables only the front-end part of plugins, and this plugin in 100% Ruby. So I don’t think disabling JavaScript customizations is any help. This fact makes me a little skeptical about the plugin, as does the fact that it includes an about.json file as if it were a theme component. But in the end, everyone is responsible for the code they install on their forum.
You are completely right on this, I can confirm this through my own testing with a freshly spun up Discourse instance. I went ahead and updated the documentation with instructions that actually work which consist of logging into the server and manually disabling the addon:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
I can confirm that safe mode is inaccessible when the “Enabled for All Visitors” setting is enabled and someone tries to access safe mode while connecting using a VPN/proxy.
Indeed, an about.json is redundant for standard plugins, I went ahead and removed it from the repo.
Thanks for all of your feedback @Moin. If you have any other remarks or suggestions feel free to leave them here. The code is fully open source and any contribution is welcome: GitHub - ProxyTracer/discourse-proxytracer.
I am testing your service and would like to know if there is any conflict with ‘templates/cloudflare.template.yml’ and whether the plugin will support any future updates to the Discourse core.
Thanks for testing! The documentation in the README.md regarding Cloudflare integration clearly recommends the inclusion of "templates/cloudflare.template.yml" as it’s necessary to ensure that Discourse extracts the user’s real IP when the forum is behind Cloudflare. Hence there’s no conflict with that template, in fact including it is necessary.
And yes, we are committed to follow Discourse’ core updates to ensure full compatibility with newer versions.
I was wondering if the inclusion of an option that - instead of blocking users - would require merely passing an hCaptcha instead, and making such an option the default would constitute a good compromise, as it’s adding just enough friction to make it more difficult for spammers and ban evaders while still allowing legitimate users who want to safeguard their online privacy through VPNs, Tor and the like. Of course, admins who would still want to stick to full bans on those networks would still have that option. What do you think?
Thank you so much! I just ran a test in a sandbox and it’s working perfectly.
Are you planning to add any functionality related to mobile network IPs/ASNs? A common issue on my forum is users switching from their broadband connection to a carrier’s 4G/5G network to get a different IP, which they then use to try to bypass registration or login restrictions in Discourse.
It would be great to be able to identify when an IP belongs to a mobile carrier’s ASN and, optionally, allow these IPs to be handled differently during registration/login.
This might be a bit out of scope for ProxyTracer, since it’s not necessarily related to VPNs/proxies, but it would be useful for a specific problem regarding how Discourse handles per-IP account limits.
In the case of hCaptcha, I already use it in my installation and it has been working very well! Perhaps a combination of the plugin that apparently is already in the Discourse core with your plugin, maybe as an extra feature?
I like the idea of maintaining the full block, after all, that is the goal, but regarding the IPv4 and IPv6 of fixed and mobile networks, it seems very useful to make this access difficult through challenges, given that AI loves creating accounts on forums.
Hello, thanks for taking my reply into consideration. It’s really something that interests me, and I find it to be a particularly sensitive implementation for everyone, both as users and administrators.
Honestly, I feel like a robot completing CAPTCHAs to prove I’m human, deliberately acting like a bot. I’ve mentioned in related topics that Anubis’s implementation (POW) feels much more pleasant and functional to me.
I understand that this is out of scope for this project, but from what I can analyze from my position, the use of the CAPTCHA you mentioned would be feasible and could literally not block users who value their privacy and want to contribute without being kept outside.
For ProxyTracer to function effectively, the Discourse application must receive the true client IP address.