Thanks for clarifying. I’ll follow the advice, and so far the service has been great. I’m looking forward to the update with the new feature and others 
1 like
We’re happy to release a new beta version that comes packed with some highly anticipated features:
- Administrators can now choose between outright blocking (block) or challenging suspicious connections with a CAPTCHA (captcha). Both Cloudflare Turnstile and hCaptcha are currently supported.
- Independent clearance tokens for visitor, login, signup, email_login, and forgot_password to ensure solving a challenge in one context does not grant blanket access to others.
- Interactive 30-day (can be extended) visual analytics powered by Chart.js displaying total checks vs. detected proxy/VPN traffic.
- Logs displaying the last 500 blocked attempts including timestamp, IP address, username (if enabled), and action.
To test this new beta release all you have to do is to change the line in your containers/app.yml from:
git clone https://github.com/proxytracer/discourse-proxytracer.git
to the following:
git clone -b beta-testing https://github.com/proxytracer/discourse-proxytracer.git
And after a ./launcher rebuild app you should be set and ready.
We’d appreciate any feedback and suggestions on how to further improve the plugin.
2 likes
Wow, it was more than I expected. I appreciate your dedication to Discourse and I see the value in your service. I intend to keep paying and providing feedback.
I’m not sure which jurisdiction your company is based in, but regarding the fact that, for example, cataloging VPN and proxy networks is a game of cat and mouse, I would be willing to share specific information about networks that have passed through your filters, so that I can help improve detection. Living in Brazil, I need to follow certain rules similar to GDPR, known as LGPD, so I think it would be best to first understand what data would be required and how it would be handled. That said, this is just a thought on how instances, whether running Discourse or Flarum, could contribute and how there could be a mutually beneficial arrangement for both sides.
1 like
Cloning the beta now. I’ll share feedback soon.
1 like
I ran a quick test and it worked as expected! Now we just have to wait for the production attempts. Thanks for making these new features available.
1 like
Thanks for the kind words, we’re glad that the updated extension proved to be useful to you!
We’re thinking of waiting a bit more for any additional feedback/bug reports before bumping it to the stable channel.
1 like
One thing I noticed is that when a login is performed via SSO, since this is a login action, it does not assign a user or an email.
Another detail is that the create action appears even when the account already exists. For example, yesterday I ran a test using an alternative account that already existed, but the log recorded the action as if the account had been created at that moment. This can cause some confusion in interpreting the logs.
Finally, returning to the issue of mobile networks, I realized that a false positive occurred. The ASN 26599 and 22085, which is a Brazilian mobile data operator, appeared in the block logs both in SSO attempts and in an attempt involving an existing user.
I return to the same issue of confusion in the logs: a user attempted to log into their own account using a range belonging to this ASN, but the action appears as create, when, in reality, no account was created. This can make it difficult to distinguish between an account creation attempt and a login attempt by an existing user.