Antibot locked me out of my own site

Maybe this is a double of #3318161

I do not use Advanced CSS/JS Aggregation (installed, bud not activated).

After 'composer update' I would login as admin to run /update.php, bud the site locked me out. I can't login in any way. So go back with a backup and removed the antibod module, then update all and run /update.php after set "$settings['update_free_access'] = TRUE;" and delete the caches (local and server/drupal).
So far so good. Now install antibod again, expected it shoud work as normal. Bud guess what.. same problem! :-}

Again go back with a backup, remove antibot, update all (with composer), install antibot bud now as suggested in issue #3318161 #4 in /admin/config/user-interface/antibot remove ' user_login_form '. Now it kind of works, bud the user-login form is not protected anymore, and this is one who is important to protect..

When locked out this message is displayed:
"You have reached this page because you submitted a form that required JavaScript to be enabled on your browser. This protection is in place to attempt to prevent automated submissions made on forms. Please return to the page that you came from and enable JavaScript on your browser before attempting to submit the form again."

And I see this warning in the log of Drupal (maybe this help to resolve this issue):
Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsSettingsAssets() (line 199 of /home/realister/public_html/core/lib/Drupal/Core/Asset/AssetResolver.php)

So for now it works bud whithout the protection of the user login page.
Drupal 9.5.3. - antibot 2.0.2 - PHP 8.1

Something is going on... I can log in to my own production site, but I see that SOME logins get redirected to /antibot. I do not see anything common yet...

We implemented a story to install both Honeypot and Antibot and noticed this problem right after rolling it out to acceptance (not sure why this was not caught in the review process). So, consider this another datapoint. I think the workaround will be to exclude the login form from the module, if it turns out it is the inly form that is affected.

I think this will at least needs a revision to the steps to reproduce. Are we even certain that the problem can be reproduced by installing a fresh Drupal with all the modules mentioned in the summary? I've been debugging the JS in the browser and it seems to do what it is designed to do (replace the action), but the old action (/antibot) still seems to apply then.

FWIW, a simplytest.me with only this module added works fine, so it would appear to be some interaction. Another option might be something to do with JavaScript order.

This was happening on one of my sites and it was being caused by applying the uniqueid Twig filter to the id of the form. In form.html.twig we had this code: <form{{ attributes.setAttribute('id', attributes.id|unique_id) }}>.

By creating template overrides for the user login, password reset, and user registration forms, we were able to resolve this issue by removing the uniqueid filter, resulting in <form{{ attributes}}>.

I didn't look into the javascript of the antibot module at all to see if it can be adjusted to support forms that use the uniqueid filter, but wanted to share in case it helps anyone else.

I had a similar issue, where if JS aggregation was disabled, and a user logged out, they wouldn't be able to log back in and would only see the error message that JS needed to be enabled on their browser.

same issue, I just uploaded a new D10.2 site to the host.
it worked ok on my local environment, but on the host antibot falsely claims javascript is not enabled.

Same problem. Fine on local dev; locked out of prod. This should be a great module, but it will have to be removed for the moment. Cannot see any clear reason why the login form is such an issue.

This may be worth investigating for anyone who has this issue:
I had a similar issue in some of our websites and after completely tracing the process that this module uses I found out that the module (in our case) was working correctly, but it broke because we had a bug in our own templates:
Due to something we did both the form and a wrapper div had the same HTML ID (i.e. id="user-pass"), because of which the Antibot module spoke to the div instead of the form.

I'm not sure the ID issue is the culprit. I'm using the Gin Login module and don't see any duplication of IDs, although I wonder if that's common to other users who flagged this issue?

@robcarr, out of all the sites I maintain, the 1 site using the Gin Login module is triggering this login issue. The other sites not using Gin Login are just fine.

#24: The same for me.
I also use Gin-Login. Attempts to log in via "/user/login" fail as described above several times.
But logging in via "login-block" (i.e. outside the Gin login theme) is successful.

#22: I could not detect identical id's used several times in the Gin.login theme.

Addition to my previous entry:
I have been observing the described behavior since updating the Drupal core to 10.2.3.

I get this error on webforms but not in the login page. Drupal 9.5.11, php 8.1, Antibox 2.0.3

I also have same issue after updating Drupal core to 10.2.4.
PHP8.1.27. I am using Bootstrap Barrio 5.5.16 theme.

If the problem occurs in connection with Gin Admin Theme, you will probably find the solution here:
https://www.drupal.org/project/gin/issues/3419180 🐛 Resolve Missing Dependency 'core/once' in Gin_accent Library Closed: duplicate

The addition of the 'core/once' library in Gin module 🐛 Resolve Missing Dependency 'core/once' in Gin_accent Library Closed: duplicate hasn't changed the error on login.

I can only replicate the error described in this thread with Gin Login enabled, and JS aggregation on. When the error occurs, Console flags up an error: Uncaught TypeError: Cannot set properties of undefined (setting 'human') indicating a problem linked to antibot.js - with the aggregated JS error at https://git.drupalcode.org/project/antibot/-/blob/df2cc22726e9f88a39f316...

drupalSettings.antibot.human = false;

Which seems odd, as this line is initialising an object. I changed the way human is initialised:

drupalSettings.antibot = {
  human: false
};

And whilst the Console error went away (and no other JS errors), the Antibot 'Submission Failed' error page returned, preventing login.

I thought the problem might be down to using a password manager to login, but the JS is capturing mouse moves after form is submitted (see JS code 21-38).

I'm stumped - don't really think this is a JS error. Only current option in production is either not use the module, or remove the user_login_form from the Antibot settings.

Whilst this was postponed and kicked into the long grass 2 years ago, I think it warrants a little more inspection as an issue.

Can we conclude that the steps to reproduce can be reduced to using Gin Login? Because the list of modules that the issue summary claims are needed for reproduction is a bit off-putting. Our project does not use Gin Login, so no guarantees it will in fact be the same issue.

Nope.. Just tried with Gin Login on Simplytest.me, works fine. If it is related to JS aggregation, the number of modules might be a factor. Core has also seen some recent changes to JS aggregation (10.2, I think). It might be interesting to know what core versions are involved.

okay, here is more weird information:

I have just updated a site from 9.5.11 to 10.2.4 on my local windows environment. everything is working well there.

then, I uploaded the working site to the server (same PHP version)

symptoms :
- theme was not applied
- after entering login details to /user/login , brwoser is redirected to /antibot with message "
Submission failed
You have reached this page because you submitted a form that required JavaScript to be enabled on your browser. This protection is in place to attempt to prevent automated submissions made on forms. Please return to the page that you came from and enable JavaScript on your browser before attempting to submit the form again.
"

now the ultra weird part :
I had uninstalled antibot (by using uninstall option in the admin interface) before upgrading the site to avoid this exact problem... so antibot should not even be active.

We're experiencing similar problems in several sites here (D9.5.11). We've pinned it down to a combination Antibot → and Cookiebot → . We've been using Antibot without any problems for years, but recently replaced EU Cookie Compliance → banner with Cookiebot and that's when we started having problems logging in.

The problem disappears when we remove the user/login form from the Antibot protection settings, but that is obviously not an ideal workaround.

If a user accepts all cookies (in the Cookiebot banner), logging in is not a problem. If the user denies or does not click anything in the Cookiebot banner, the login form submission fails with the error stated in #35.

I've also encountered a similar problem.

This ticket fixes the problem:
https://www.drupal.org/project/gin/issues/3432512 🐛 Missing once dependencies on sticky and gin_accent libraries even tho it uses it Fixed

Not sure oif this problem is Gin-related. We don't use any Gin-related themes or modules but are still experiencing this issue on multiple websites.

In the case of Gin the problem is visible in the console.

Antibot use JavaScript, checks your console, you must have a JS error.

There are no errors in my console:

I only see blocked cookies, which makes sense because Cookiebot is doing what it's supposed to do.

The error occurs in the loggin screen. Look at the console before submitting it.

Cookie-fencing modules often have a way to suppress the loading of certain Javascript. Antibot uses... Javascript to replace the action of a form. So maybe that's an area to look into.

I think this is slowly becoming a dumping ground of everything where antibot for one reason or another fails to work on the login form, which can have many different causes. We really need more than "it doesn't work" to be able to pinpoint a specific problem. *Why* was antibot unable to run its JavaScript that is supposed to replace the form action? And was that a problem with Antibot in the first place? I think we're even at a point that when someone does actually manage to put together some steps to reproduce, those would warrant their own issue (which happened in a few instances where Gin was involved), because this one is becoming too broad.

It seems to me to be a caching issue. When I rebuild the cache I can login once...after which it starts failing again.

Not sure how this would only affect login though.

same, can't login.
it is drupal 10.2 issue?
I think I only had the problem after the update. I have 10.2.5

I've tried (again) to isolate/reproduce the problem on a clean Drupal (9.5.11) install with only the Antibot and Cookiebot modules enabled, but I was unsuccessful.

The issue does still persist in several different client sites, but I cannot figure out what combination of modules and settings is causing this. In my case(s) it seems Cookiebot is blocking the Antibot script that should replace action="/antibot" with action="/user/login" in the form element, until the user agrees to all cookies and reloads the page. I'm seeing the problem in all forms that have Antibot protection applied.

Question to others who see this issue: does this problem still persist when you disable Automatically block all cookies in /admin/config/cookiebot?

Same here, it's OK at DEV (where cache, etc. are cleared every run) and fail on Production.

I had opened an issue here: https://www.drupal.org/project/antibot/issues/3446650 🐛 Javascript error when webform block and views_exposed_filter are present on the same page Active

but I think my issue is one more of lots of issues with D10 and Antibot

For those experiencing this issue with a cookiebot implementation, see my fix in 🐛 stopped working after adding cookie consent JS Fixed .