No longer protecting D7

Thank you for your effort. Much appreciated.

I applied the patch to two live sites. I will keep you posted on the results.

Thank you so much for this patch. I applied to one of my Drupal 7 websites.
I had a conflict though, with the https://www.drupal.org/project/minifyjs → v7.x-1.9
When I have the Javascript minification enabled in the Performance screen, the login form was always failing.
Now I disabled it and the form works fine.

All spam is gone here

I do not use the minifyjs project. I use AdvAgg on recommended settings with JSMin file compression.

All works fine. Thank you! :)

Thank you !
I'll move this to RBTC and commit this patch to the 7.x-1.x branch.

Thanks @danrod, confirming this works for D7, so it's RTBC.

It's also the same approach that was committed and working for D10+ in 🐛 No longer protecting Fixed .

Committed to the 7.x-1.x branch and created a new release: https://www.drupal.org/project/antibot/releases/7.x-1.3 →

Thanks a lot to everyone involved.

@danrod:

After updating to 7.x-1.3, I'm getting the error "Submission failed. Please reload the page and try again" similar to the one referenced in https://www.drupal.org/project/antibot/issues/3419697#comment-15455166 🐛 No longer protecting Fixed .

It happens with a clean browser or a used one, normal mode or private/incognito, and every browser I tried (Firefox, Chrome, Opera, Edge), all up-to-date.

It happens on a live site with JS compression enabled and a development site with JS compression disabled.

Suggestions? Rolling back to 7.x-1.2 fixes the problem.

Thanks for reporting this @rclemings , I didn't see this problem myself, reviewing now.

Thanks. Let me know if you need any more details off list.

Hi @rclemings I did some test on a branch new and I didn't see this issue again, maybe the JS files of your site are being cached externally somewhere (Varnish/Cloudflare..)? Is anyone else having the same issue?

No external caching. I wonder if there's some js conflict with another module. Not sure where to start looking.

I'm seeing this on a second site now, different server (both are Knownhost with cPanel but different OSs, Centos 7 vs. AlmaLinux 8, not that any of that would matter).

Here are the contrib modules they have in common, fwiw:

better_exposed_filters
ctools
date
entity
entityreference
field_group
globalredirect
libraries
link
masquerade
metatag
pathauto
profile2
redirect
rules
search_api
token
views_data_export
views
wysiwyg
xmlsitemap

Another site on the same server as the first one (CentOS) doesn't seem to have the problem. I think I'm going to have to figure out what's different about those two sites.

Thanks @rclemings , I'll move this back to "Fixed" for now, let me know you findings on that, I can always look back on this issue.

I am seeing the same behavior as @rclemings on our production server but am unable to reproduce locally. .

I added some watchdogs to the .module file and figured out how to fix the problem, although I don't understand why it wasn't working in the first place.

I added this after line 199:

watchdog("_antibot", "form_state_input_antibot_key: <pre>" . print_r($form_state['input']['antibot_key'], TRUE) . "</pre>");
watchdog("_antibot", "form_id in antibot_form_validation: <pre>" . print_r($form['#form_id'], TRUE) . "</pre>");
watchdog("_antibot", "antibot_generate_key: <pre>" . print_r(_antibot_generate_key($form['#form_id']), TRUE) . "</pre>");
watchdog("_antibot", "form_state_key: <pre>" . print_r($form_state['input']['antibot_key'], TRUE) . "</pre>");

I added this after line 212:

watchdog("_antibot", "form_id in _antibot_generate_key: <pre>" . print_r($form_id, TRUE) . "</pre>");

That gave me the following results in the watchdog log (in order):

form_id in _antibot_generate_key: job_advertisement_node_form
form_id in _antibot_generate_key: comment_node_article_form
form_state_input_antibot_key: 1eaa6fbfdb079197d7f04912d6aa1f79
form_id in antibot_form_validation: comment_node_article_form
form_id in _antibot_generate_key: comment_node_article_form
antibot_generate_key: 4f287b465e1f4cfd8eeb32033a1e28bf
form_state_key: 1eaa6fbfdb079197d7f04912d6aa1f79

I added another watchdog to check the value of $form['#form_id'] and it was "comment_node_article_form." Why, I don't know. Comments are closed on that comment type and the comment form doesn't appear anywhere on the page. If I search the page source for "comment" I get no hits.

Anyway I changed line 199 to get the form_id from the form element:

//    $expected_key = _antibot_generate_key($form['#form_id']);
    $expected_key = _antibot_generate_key($form['form_id']['#value']);

And now it seems to work. (Haven't moved it to the live site yet, but it's working in devel.)

Here's what I get in the watchdog now (only the second line is different):

form_id in _antibot_generate_key: job_advertisement_node_form
form_id in _antibot_generate_key: job_advertisement_node_form
form_state_input_antibot_key: 1eaa6fbfdb079197d7f04912d6aa1f79
form_id in antibot_form_validation: comment_node_article_form
form_id in _antibot_generate_key: comment_node_article_form
antibot_generate_key: 4f287b465e1f4cfd8eeb32033a1e28bf
form_state_key: 1eaa6fbfdb079197d7f04912d6aa1f79

Does that clarify anything? I'm pretty much at the limit of my understanding of how forms work but the fact that $form['#form_id'] and $form['form_id']['#value'] are different seems significant.

Several D7 sites get the message as in #12, others don't. I will try to figure out with which combination of modules the error occurs.

I had one site with the error and one without. The site with the error had these modules that weren't on the unaffected site:

globalredirect (PATH MANAGEMENT)
metatag (SEO)
better_exposed_filters (VIEWS)
profile2 (OTHER)
search_api (SEARCH)

I disabled them one by one (along with their dependencies) and it made no difference.

Just one more data point.

Wazup,

i had the Problem, that i could not Login anymore to my Website bec. Login Security had Blocked me.

After reviewing the code, i saw its a misstake from Antibot bec. it always fails to Validate the User and in my case it was triggering the Module Login Security to Block me.

The Patch should do the trick.

I made a cross reference of the modules and libraries of 17 D7 sites. 10 of them are experiencing a block when logging in, 7 are not. I could not find a specific module or library that could cause the blockage. All sites use a different set of modules.
The strange thing is that the blockage occurs one day and not the next (found at 3 sites).
I disabled antibot in the sites which are blocked b the module.