When all users come from 127.0.0.1, new registrations are blocked


(PEB) #1

Greetings,

I’ve tried to solve my problem by reading previous topics, but that didn’t work.

Because of some proxy config in docker (I guess), all the people in our local network are seen by our discourse as coming from 127.0.0.1. 127.0.0.0/8 is whitelisted in “watched IP”, yet, we have a user who is unable to register, he gets the message I pasted in the topic.

There is no blacklist, at least one admin registered under 127.0.0.1, and everything was fine 'till now. I tried to remove the whitelist and to add it again, the error message changed, now it’s “max registration for this address reached”, or something like this.

Looking in our logs, we can’t find anything explaining why the whitelist is not effective.

Do you have any idea?

Thanks!


Urgent: Site down after upgrade to 1.6.4 due to Cloudflare template
(Mittineague) #2

I’m guessing there were quite a few signing up?

If you go to Admin -> Settings -> Spam there’s

max new accounts per registration ip
If there are already (n) trust level 0 accounts from this IP (and none is a staff member or at TL2 or higher), stop accepting new signups from that IP.

The default is 3

Might this be the reason?

Maybe try upping it temporarily?


(Tobias Eigen) #3

I am having this problem happening alot recently as well, and can’t quite seem to nail where it’s coming from. The error message is “Signup is not allowed from this account”. Creating an account on behalf of the user from my machine works.

I’m guessing it has to do with blacklisted IP addresses but am not sure what to look for. Is there any way to turn off IP blacklisting temporarily?


(PEB) #4

As far as I understood, the whitelisted IP are not checked regarding this configuration.

But I can try.


(Jeff Atwood) #5

Correct, @techapj made the error more literal, @Mittineague gave you the right answer on the setting to change here.


(Scott Trager) #6

Either “Signup is not allowed from this account” or “max registration for this address reached” is confusing. The first one is flat-out incorrect making the user think that they can’t sign up using their email- were they banned? Did someone already sign up with their email?!? The second doesn’t specify what kind of address - Email address? Mailing address? Mac Address?


(Jeff Atwood) #7

Neither one of those phrases is the correct copy that exists in the product right now. The latter one at least, is an, uh, “recollected” version.


(PEB) #8

Eh?

In another topic it is said that there is not threshold for whitelisted IP. I don’t understand.

For reference :


(Jeff Atwood) #9

You really, really need to fix this on your end … the IPs should come from the correct ranges.

@techapj can you confim we didn’t have any regressions around whitelisting IPs in Logs, Screened IPs with regards to this setting?


(PEB) #10

The proxy config comes from an unknown magic.

The VM hosting the discourse instance is in the same network as our users (we are a campus ISP), so it shares an IP in a /21, as do the computers of our users. Somewhere between the VM and the docker container, something is translating the incoming IP address in 127.0.0.1.

I made no special config, I just followed the tutorial, and I have no clue where does it come from.


(Tobias Eigen) #11

actually, no - I am getting reports of exactly this error message:

"Signup is not allowed from this account"

I haven’t been able to pinpoint the source of the problem being 127.0.0.1 but will look. @PEB how did you determine this?

Could this be related to cloudflare perchance? Digitalocean? Any other common variables?

I have two sites running right now and only one is on cloudflare - that’s the one preventing new user accounts.


(PEB) #12

@tobiaseigen our discourse instance is on a VM we setup ourselves (a KVM guest), I never tried to run discourse on a droplet.

The only users having this problem are in the same local network than the VM.

In production.log I found some registration requests of users for who the registration fails, they all are behind 127.0.0.1.

As for the 127.0.0.1 magic, is that possible that rails is responsible?


(Tobias Eigen) #13

ok - makes sense. maybe my issue is different. In any case, on my site the 127.0.0/8 range is whitelisted.


(PEB) #14

Yeah, it is the same for me, and, nevertheless, my users can’t register.

Anyway, solving the address translation problem would be enough to solve my own issue.


(Jeff Atwood) #15

It is probably because the site behind CloudFlare shows all users as coming from CloudFlare IP addresses. Make sure you have disabled virtually all CloudFlare “features”, except basic DNS. Any kind of passthrough other than DNS name resolution will be problematic.


(PEB) #16

We do not use CloudFlare nor any other service like that. Our VM is directly reachable with its own address. It is hosted on a KVM host in the campus, and routed behind our school. On the local network (138.231.136.0/21), there is no special feature, everything goes from our users computers to the KVM guest directly, only affected by the iptables nat rules setup by docker when launching the container.

The funny part : users coming from outside the local network are correctly handled, and their IP is not 127.0.0.1.


(Jeff Atwood) #17

I agree that 127 is on the default internal whitelist and should not be blocked here. @techapj will have a look.


(Tobias Eigen) #18

Thanks - that makes some sense to my only part-technical brain. So we’d just need to do this click so it looks like the top one below:

which is sad because it means we lose all the benefits of using cloudflare in the first place. Otherwise we’ve been super happy with our arrangement and all has been working perfectly.

there is this “How do I restore original visitor IP with Nginx?” in the cloudflare support, but I presume that won’t work with our docker setup.


(Kane York) #19

I thought there was a howto about set_real_ip_from directives in the container?

Here we are: Config Nginx to receive real IP when using Cloudflare for noobs

@tobiaseigen, can you try adding this to the run section of your app.yml? If it works, I’ll PR it to discourse_docker so you can add the cloudflare.template.yml template.

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Download list of CloudFlare ips
        wget https://www.cloudflare.com/ips-v4 -O /tmp/cloudflare-ipv4
        wget https://www.cloudflare.com/ips-v6 -O /tmp/cloudflare-ipv6
        cat /tmp/cloudflare-ipv4 /tmp/cloudflare-ipv6 > /tmp/cloudflare-ips
        rm /tmp/cloudflare-ipv4 /tmp/cloudflare-ipv6
        # Make into nginx commands and escape for inclusion into sed append command
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        # Insert into discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Clean up
        
        rm /tmp/cloudflare-ips
  - exec: "/tmp/add-cloudflare-ips"
  - exec: "rm /tmp/add-cloudflare-ips"

(Arpit Jalan) #20

It does specify (also the error message is much more detailed than “max registration for this address reached”):

I agree, that was default Rails locale. Improved that error message as well: