Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When moderating comments via the hosted Mollom moderation system, and assigning a post as spam, two warnings pop up in my logs:
- access denied at mollom/moderate/120801f7f781ffed5f/spam
- "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.
Comment | File | Size | Author |
---|---|---|---|
#8 | mollom-cgi-d6.patch | 1.24 KB | dixon_ |
#7 | mollom.cmp_.cgi_.7.patch | 1.24 KB | sun |
#5 | mollom.cmp_.cgi_.5.patch | 1.11 KB | sun |
Comments
Comment #1
sunHm. 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?
Comment #2
nwehner CreditAttribution: nwehner commentedI 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.
Comment #3
nwehner CreditAttribution: nwehner commentedThis 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.
Comment #4
dixon_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 functionapache_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.Comment #5
sunI 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.
Comment #6
sun@dixon_, can you confirm that this patch fixes this issue in your environment?
Comment #7
sunStudying this further:
getallheaders()
function not only when running as Apache module, but also for FastCGI.$_ENV
does not always contain the HTTP header variables. Specifics on when exactly they're made available are hard to find..htaccess
:Alternatively the following, although it appears unnecessarily complex to me:
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.
Comment #8
dixon_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 headerAuthorization
. Why is this useful? Because in certain situations (like before PHP < 5.4) it's difficult to fetch theAuthorization
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: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 inREADME.txt
as well as asking hosting companies as Acquia to document this properly for their platforms that run PHP as CGI.Comment #9
sunThanks 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.
Comment #10
dixon_@sun Awesome! Thanks for quick response and commit!
Comment #11.0
(not verified) CreditAttribution: commentedFixed formatting