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.
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
ownerMattJ
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.
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
tagMilestone-0.9
MattJ
on
Changes
tagStatus-Accepted
tony
on
Got it. I'll look out for 0.9.9. Thanks a lot for your help, Matt.
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
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.
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!
ChangesHi 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.
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.
ChangesGot it. I'll look out for 0.9.9. Thanks a lot for your help, Matt.
This seems to have evaded both 0.9.9 and 0.9.10
MattJZashFixed in https://hg.prosody.im/trunk/rev/b4a0bc46c82d
Changes