We had a server behind a proxy and we were getting a 100% failure rate. All submissions were being blocked 100% of the time. After a week in the mollom support queue, we finally resolved it and this doesn't appear to be documented anywhere, so to save everyone some time, this would be nice to do:
Firstly, new sites, this will not be an issue. The IP is new, so it will not be blacklisted
However, add 10,000 spam hits, the IP becomes blacklisted and all that mollom sees is that the remote address is the website address, so everything becomes blocked.
To ensure that the correct IP is sent, the following variables (D6) need setting
// Tells Drupal that we are running behind a proxy
variable_set('reverse_proxy', 1);
// This is the standard $_SERVER parameter on Apache that we see, but it is different on different servers.
variable_set('x_forwarded_for_header', 'HTTP_X_FORWARDED_FOR');
Clean the cache and start loving rather than hating mollom!
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | mollom.verify-ip.6.patch | 3.59 KB | sun |
Comments
Comment #1
sunI don't think that any amount of additional documentation in the Mollom module will help in any way to resolve this issue. This is documented in settings.php and more than once in handbook pages on drupal.org already. Hence, plenty of documentation exists already; people just don't read it.
What we could do:
'ip'column to {mollom} to additionally record the author IP per session.Pinging Dries to decide on this proposal (or won't fix).
Comment #2
sun#1711634: Build in IP error checking into hook_requirements(). proposed a check running in hook_requirements()
Comment #3
dries commentedI agree that we should try to detect incorrect IP address configurations. Documentation should always be the last resort.
Just a few thoughts:
* I wonder if there is a basic check that we can perform that doesn't require a lot of bookkeeping or number crunching on the client/Drupal site. A basic check may fix 70% of the problems. If such check exists, let's start there.
* In addition to that, the Mollom backend could return a code when it believes the IP addresses are misconfigured. The number-crunching could possibly live on the server-side so different clients (Drupal, Joomla, Wordpress, custom implementations, etc) don't have to reinvent this. We already try to detect this in the backend so way be able to get a relatively quick win here. (Maybe there are unique advantages to detecting this in the client though.)
Before we implement anything, let's brainstorm some ideas "on paper".
Comment #4
sunYeah. The bookkeeping of IP addresses I suggested earlier is probably needless overhead.
Likewise, I also wouldn't want to put any more special code into the handling of Mollom responses, as this check/condition would have to be placed into many different functions and technically is out of scope for them.
I think the ideal solution would work like this:
hook_requirements()would issue a request to aforementioned endpoint, compare the result with the IP address it determines on its own (here:ip_address()), and flags a requirements error.Comment #5
alan d. commentedCode added in D7 in ip_address() would probably be catching many people un-aware during a D6 to D7 upgrade, and this issue is so simple to detect in code (
$_SERVER['SERVER_ADDR'] == ip_address(). The offending lines:I think that a run time requirements warning rather than error is all that is needed, and would at least detect most related issues. Anything else would just be icing on the cake :)
Comment #6
sunAttached patch implements the basics for #4, whereas the concept got slightly revised in the meantime.
This patch is not complete, since I wasn't able to authenticate against the new /site/$PK/ping endpoint.