When moderating comments via the hosted Mollom moderation system, and assigning a post as spam, two warnings pop up in my logs:

  1. access denied at mollom/moderate/120801f7f781ffed5f/spam
  2. "Missing protocol parameters Missing protocol parameters Request headers:"

The comment successfully removes from the Mollom moderation page after flagging it as spam, but the spam comment is not removed from my Drupal page. After turning off redirects to the Mollom moderation pages, I can find all the comments still unpublished and need to manually delete them. For some reason, Mollom isn't getting access to my Drupal installation to remove comments itself.
I am running Drupal 7.15 with the Mollom 7.x-2.1 module.

Files: 
CommentFileSizeAuthor
#8 mollom-cgi-d6.patch1.24 KBdixon_
PASSED: [[SimpleTest]]: [MySQL] 6,803 pass(es).
[ View ]
#7 mollom.cmp_.cgi_.7.patch1.24 KBsun
PASSED: [[SimpleTest]]: [MySQL] 6,800 pass(es).
[ View ]
#5 mollom.cmp_.cgi_.5.patch1.11 KBsun
PASSED: [[SimpleTest]]: [MySQL] 6,800 pass(es).
[ View ]

Comments

Status:Active» Postponed (maintainer needs more info)

Hm. This interaction is constantly tested actually. And I even took the time to test the full interaction once more manually for this issue now, but I'm not able to reproduce the issue.

Since you're saying that you're moderating the content from the moderation system, this means that your site is actually able to send content to it. There just seems to be some glitch in the other direction.

Perhaps that was a temporary thing? Can you test again?

I just tried it again (after performing the Mollom update) to moderate ham comments and got a ton of errors...see this screen capture. Everything with Mollom seems to work fine as long as I don't use Mollom's moderation system.

This morning I uninstalled Mollom and re-installed the 7.2 module. I waited until I got a few spam posts and moderated them from the Mollom moderation system. I still got the same errors as before: missing protocol parameters and access denied. The comments were not removed from the site. After turning off redirection to Mollom's moderation pages, the spam comments were still there. I was able to successfully delete them and I reported as spam to Mollom the standard way.

Version:7.x-2.1» 7.x-2.x-dev
Status:Postponed (maintainer needs more info)» Active

I'm having the same problem on a Drupal 6 site.

I think the problem originates in MollomDrupal::getServerAuthentication() where there's a check for the function apache_request_headers(). This function only exists when PHP is installed as an Apache module, which is not always the case.

In my case we're running our site on Acquia Cloud which seems to have PHP set up in FastCGI mode.

However, there's an alternative check made in MollomDrupal::getServerAuthentication() for HTTP Basic Auth, but requests from the Mollom Content Moderation Platform doesn't seem to include the necessary headers for that.

Status:Active» Needs review
StatusFileSize
new1.11 KB
PASSED: [[SimpleTest]]: [MySQL] 6,800 pass(es).
[ View ]

I investigated the situation and indeed, when PHP runs as CGI, the HTTP request headers are not made available in the usual variables.

I'm relatively confident that attached patch will fix the problem.

@dixon_, can you confirm that this patch fixes this issue in your environment?

StatusFileSize
new1.24 KB
PASSED: [[SimpleTest]]: [MySQL] 6,800 pass(es).
[ View ]

Studying this further:

  1. PHP 5.4+ enables the getallheaders() function not only when running as Apache module, but also for FastCGI.
  2. $_ENV does not always contain the HTTP header variables. Specifics on when exactly they're made available are hard to find.
  3. If all fails, the most common workaround mentioned on the net seems to be to add the following lines to .htaccess:

    RewriteEngine On
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    Alternatively the following, although it appears unnecessarily complex to me:

    RewriteEngine on
    RewriteCond %{HTTP:Authorization} ^(.*)$ [NC]
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

    These rewrite rules essentially copy $_ENV['HTTP_AUTHORIZATION'] into $_SERVER['HTTP_AUTHORIZATION'].

Attached patch slightly revises #5 to take the PHP 5.4 improvement into account.

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new1.24 KB
PASSED: [[SimpleTest]]: [MySQL] 6,803 pass(es).
[ View ]

These rewrite rules essentially copy $_ENV['HTTP_AUTHORIZATION'] into $_SERVER['HTTP_AUTHORIZATION'].

I think this statement is a bit missleading. I think what it actually does is creating (or "updating") the environment variable called HTTP_AUTHORIZATION with the value from the HTTP header Authorization. Why is this useful? Because in certain situations (like before PHP < 5.4) it's difficult to fetch the Authorization header consistently. It's more common/easier to access $_SERVER['HTTP_AUTHORIZATION'] I guess.

So, the patch itself didn't make any difference for me, in my case at least. But the problem was solved after applying the .htaccess rule you provided. Only then the headers became available in $_SERVER['HTTP_AUTHORIZATION'] and things started to work:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

In any case, I think the patch might be useful, so attached is a D6 version of it.

Moving forward we should probably add a note about the .htaccess rule in README.txt as well as asking hosting companies as Acquia to document this properly for their platforms that run PHP as CGI.

Title:"Missing protocol paramaters" and "access denied" when moderating from Mollom's moderation systemPHP as CGI: Missing OAuth HTTP Authorization header for inbound moderation requests
Status:Reviewed & tested by the community» Fixed

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Additionally committed notes and instructions to both the README of the Mollom class/library as well as the README.txt of the module.

I'll also try to get in touch with Acquia Ops to ensure that this is part of their default PHP/CGI server configuration when applicable.

@sun Awesome! Thanks for quick response and commit!

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

Fixed formatting