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!

CommentFileSizeAuthor
#6 mollom.verify-ip.6.patch3.59 KBsun

Comments

sun’s picture

Title: Potential for 100% failure if Drupal configuration not set » Determine and show whether correct IP addresses are sent
Component: Documentation » Code
Assigned: Unassigned » dries

I 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:

  1. Add an 'ip' column to {mollom} to additionally record the author IP per session.
  2. On Mollom's administration pages and/or on Drupal's Status report page, perform some nifty statistical calculations on all IP values and throw an error message in case the amount of identical values compared to total amount of values exceeds a certain treshold.

Pinging Dries to decide on this proposal (or won't fix).

sun’s picture

#1711634: Build in IP error checking into hook_requirements(). proposed a check running in hook_requirements()

dries’s picture

I 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".

sun’s picture

Yeah. 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:

  1. The Mollom backend provides a special endpoint à la http://rest.mollom.com/v1/whatismyip which does nothing else than to print the IP that it sees (i.e., identical to services à la http://whatismyipaddress.com/ but without all the additional garbage, just the IP string)
  2. Mollom clients (e.g., the Drupal module) implement an application-specific way to verify the client/plugin's configuration. In this case, 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.
alan d.’s picture

Code 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:

// As if no reverse proxy header...
$ip_address = $_SERVER['REMOTE_ADDR'];

// then if reverse proxy header
// Tack direct client IP onto end of forwarded array.
$forwarded[] = $ip_address;

// Eliminate all trusted IPs.
$untrusted = array_diff($forwarded, $reverse_proxy_addresses);

// The right-most IP is the most specific we can trust.
$ip_address = array_pop($untrusted);

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 :)

sun’s picture

Status: Active » Needs work
StatusFileSize
new3.59 KB

Attached 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.