Not a single one. At least I’ve pasted the IP to Users / different page’s “username, email or IP address” and I got no result on any of the pages.
Is it possible to view a log of recent registration attempts? My only idea is that the user’s email is not the one he wrote in the email, but there wasn’t even a similar block of addresses on the screened ip list.
I see. And is there any kind of log internally or somewhere within the docker container’s file system where I can see what happened? Also, any ideas for simulating an IP address?
Have you seen any other users register since the user reported the problem? Is it possible that nobody is able to register but only one has come forward thus far?
Are you using a reverse proxy in front of Discourse, or Cloudflare?
Ok so your server isn’t getting the client IPs at all. It thinks all of your visitors are coming from the cloudflare network. You’re missing the cloudflare.template.yml in your app.yml
Turn the orange cloud off - do registrations work then?
Assuming you’re using the standard install add this to the templates: section of your app.yml:
- "templates/cloudflare.template.yml"
And rebuild:
./launcher rebuild app
To avoid any future pain, make sure you add the following rule to CloudFlare for your Discourse install:
Those features at best can undo some of the optimisations on your site and at worst cause a raft of issue with Discourse. Also be sure to disable Brotli under the ‘Speed’ settings for your domain:
Since about Oct 2018, the blocked IPs have been all from Cloudflare ranges. I guess I slowly added more and more Cloudflare IPs until no one could register anymore.
I guess it was since I upgraded to 2.1, probably something has changed, as I never used the Cloudflare config and I always got the right IPs.
Now I guess I’ll clean up the IP block list first.
You can turn off cloudflare to verify that it’s the lack of the template causing the blocks, that’s an entirely optional step.
Creating the rule mentioned above to disable their “optimisations” isn’t optional though, we can’t support installations where a reverse proxy is known to tamper with both code and communication. Discourse is already optimised automatically during the build process by the experts who write the code. Cloudflare can’t do any better than that.
Sure I did that and I’m rebuilding now. I also turned off Brotli. I just wanted to know what were the Cloudflare optimisations that were causing problems with Discourse, as I’d prefer to switch them off entirely for my domain, not only for Discourse.
You can use an extended rule with a wildcard to do that. Cloudflare is fine for web stuff like WordPress, Discourse is a great deal more sophisticated though, and Cloudflare periodically causes a bunch of pain, particularly after big updates.
Sure, I totally understand that. I was just interested to know what settings are bad, as I wanted to turn them off on my main domain to make sure they don’t cause any problems on there either, unrelated to Discourse.
Also thanks for the help, I’ve rebuilt it and now it works fine, with real client IPs.