#540 mod_watchregistrations reports registrations from 127.0.0.1 instead of real user's IP

Reporter tony
Owner MattJ
Created
Updated
Stars ★★ (2)  
Tags
  • Milestone-0.9
  • Priority-Medium
  • Type-Defect
  • Status-Accepted
  1. tony on

    mod_watchregistrations.lua reports new registrations from 127.0.0.1 instead of the user's source IP. I can't be certain if updating mod_register_web has anything to do with it, but it seems doubtful. This was the only module last updated prior to mod_watchregistrations.lua reporting 127.0.0.1 and not a user's actual source address. I have no custom configuration for mod_watchregistrations. http://modules.prosody.im/mod_register_web.html * prosody 0.9.8 * http://prosody.im/doc/modules/mod_watchregistrations * https://github.com/bjc/prosody/blob/master/plugins/mod_watchregistrations.lua

  2. tony on

    I want to add that I did try testing mod_watchregistrations in conjunction with the *older* mod_register_web, but could no longer get new account confirmations from mod_watchregistrations.

  3. MattJ on

    Hi, thanks for the report! Do you have a reverse proxy (e.g. through Apache, nginx, etc.) for users to get to Prosody? Prosody relies on the proxy forwarding the user's IP address, otherwise it only sees the address of the proxy (generally 127.0.0.1). Some more info about your setup might help us track down where the issue lies. Thanks!

    Changes
    • owner MattJ
  4. tony on

    Hi there, thanks for your response! I do have a reverse proxy setup through Apache and it seems that is the culprit. If a user registers through example.net:5281 then the correct source of the IP is reported and not 127.0.0.1. This is what I have in Apache for the VirtualHost which serves the registration page. ProxyPreserveHost On ProxyPass / https://0.0.0.0:5281/ ProxyPassReverse / https://0.0.0.0:5281/ I added X-Forwarded headers to the VirtualHost serving the registration page, but still found 127.0.0.1 being reported. LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_forwarded SetEnvIfNoCase X-Forwarded-For "." from_proxy=1 CustomLog /var/log/httpd/access_log combined env=!from_proxy CustomLog /var/log/httpd/access_log combined_forwarded env=from_proxy I'm trying to understand why this behavior is now occurring. The above config has been in place for some time while reporting the true source IP of the registration.

  5. MattJ on

    Ok, I just checked the code - and I'm not actually sure that it's going to pick this header up. We use it for when users connect through BOSH (i.e. when they're actually establishing an XMPP connection over HTTP). But our web server modules don't extract the IP from X-Forwarded-For. I'm going to move the function from mod_bosh, and into our util.http module so that any plugin that needs the real IP can use it. I expect this will be released in 0.9.9, which is coming soon.

    Changes
    • tag Milestone-0.9
  6. MattJ on

    Changes
    • tag Status-Accepted
  7. tony on

    Got it. I'll look out for 0.9.9. Thanks a lot for your help, Matt.

  8. Zash on

    This seems to have evaded both 0.9.9 and 0.9.10

New comment