In a server where all outputs are blocked (no access to mollom server), Even if "Block all form submissions" is checked, anonymous user can submit forms.
I'm using mollom on the user register form. On it's first display _mollom_falback function is called and displays the error message
The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.
After filling all required fields, submit functions are played and user is created, and it must not.
After investigate, I've found that in the 3 validation functions "mollom_validate_captcha", "mollom_validate_analysis" and "mollom_validate_post" there are no test for the service availability.
_mollom_fallback() is never called so validation pass through.
This is due to the fact that if mollom serveur is not available variables
$form_state['mollom']['require_analysis']
$form_state['mollom']['require_captcha']
$form_state['mollom']['require_moderation']
are all set to FALSE.
After having a look at the firsts lines of mollom_validate_captcha()
if (!$form_state['mollom']['require_captcha'] || $form_state['mollom']['passed_captcha']) {
$form['mollom']['captcha']['#access'] = FALSE;
return;
}
This condition is always TRUE when service is not available so following operations are allways skipped without adding an error to the form that would break it's validity.
And so the form is submitted.
I guess the cleaner way to sove this problem would be to add a fourth validation function as below :
/**
* Form validation handler for Mollom's CAPTCHA form element.
*
* Validates whether Mollom's server is available.
* If not, call _mollom_fallback function to take care about "Block all form submissions" option.
*/
function mollom_validate_service_availability(&$form, &$form_state) {
$mollom_error_codes = array(
MollomDrupal::NETWORK_ERROR,
MollomDrupal::RESPONSE_ERROR,
MollomDrupal::AUTH_ERROR,
);
if (in_array((int)$form_state['mollom']['class']->lastResponseCode, $mollom_error_codes)) {
_mollom_fallback();
}
}
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | mollom.fallback.7.test-only.patch | 703 bytes | sun |
| #7 | mollom.fallback.7.patch | 1.21 KB | sun |
| #7 | mollom.fallback.7.test-only.patch | 1.21 KB | sun |
| #5 | mollom.fallback.5.patch | 1.21 KB | sun |
| #5 | mollom.fallback.5.test-only.patch | 707 bytes | sun |
Comments
Comment #1
jgtrescazes commentedHere's a patch including these changes.
Comment #2
dgiamporcaro commentedThank you jgtrescazes it works.
@Maintainers : do you think this issue will be integrated in next release ?
Comment #3
sunWow, that's indeed a major bug. Thanks, @jgtrescazes for this excellent analysis!
Attached patch should fix this issue.
Comment #5
sunThanks for reporting, reviewing, and testing! Committed to 7.x-2.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #7
sunoh, D6 constant names...
Comment #8
sunSorry, the test-only patch also contained the fix.
Comment #10
sunCommitted the backport to 6.x-2.x. Thanks again!