Compulsory 6 seconds delay when logging in.

[Graham-72]

I have been regularly receiving the following error message when trying to log in

I think I have located and solved the problem and will submit a PR.

[herbdool]

One of the recent updates to the Drupal 7 branch might help. I'll leave this here to document pulling the Drupal 7 commits in.

[herbdool]

@Graham-72 I've merged in Drupal 7.x-1.22, can you test it? I'm not sure if it'll help the issue you're experiencing. I haven't run the tests.

[Graham-72]

@herbdool I have just now loaded your latest, thanks for this. Quite a few inbuilt tests fail. I will wait and see whether the 6 second one appears.

[herbdool]

I've updated the tests. There was a new one that I had merged from the Drupal version that wasn't working. All tests are passing for me now.

There are a couple methods that seem to be testing the time limit: HoneypotFormTestCase::testProgrammaticSubmission() and HoneypotFormTestCase::testProtectNodeFormTooFast()

[Graham-72]

@herbdool I have now upgraded to the latest release and the 6 seconds warning is still coming up. It is possible that there is some interaction with the Auto Logout module I have installed, so I will uninstall Auto Logout for 48 hours and see if this stops the problem.

[Graham-72]

@herbdool - no change, I am still getting the 6 second warning quite often.

[herbdool]

Try fully uninstalling and reinstalling. See if you still get the same message.

[Graham-72]

@herbdool I have now tried uninstalling and reinstalling, and have had 6, 11, 24 and 58 second messages!

[herbdool]

@Graham-72 I suspect it got introduced in 1.x-1.0.3 because I just noticed it on a blog of mine and hadn't had the issue before.

[herbdool]

@Graham-72 my mistake, not 1.0.3 but I'll keep looking

[herbdool]

I noticed that I had forgotten to deploy 1.0.4 so I've done that now. I now can't replicate the issue when I try to log in. I did have to set the schema version lower because of a previous issue in the code that set it to 2xxx instead of 1xxxx. It prevented the db updates with the new code. After all that it worked for me.

@Graham-72 you mentioned you had uninstalled (fully uninstalled and removed db table?) so maybe your issue has a different cause? Can you try to replicate the issue on a bare install?

I did see, however, a stray variable_get() in the module so I'll fix that. I'm not sure if it's related.

[herbdool]

@Graham-72 please upgrade from github to latest commit, run cron and test. I'm holding off making a release.

[Graham-72]

Will do. Thanks for attending to this.

[Graham-72]

The result so far is that on a fresh build with only one other contrib module I am not getting this problem.

But on a larger site with several contrib modules I am still getting it, even after uninstalling honeypot and checking that the database has been cleared, and then installing your latest.

Tomorrow I will try to track down exactly what is happening by using Devel.

[Graham-72]

After looking into what is happening I am puzzled! Reading some of the issues and responses in d.org it seems that this module should not be operational for the log-in form, and I see there is a setting "unprotected_forms": "user_login_form".

What seems to be happening on my site is that if you log-off or are logged-off and immediately attempt to log in again, you are subject to this mimimum time interval check. I think there must be something wrong with the logic of the module.

My immediate solution is to reduce the value of the time_limit setting from 5 to 3 seconds.

[klonos]

It is sort of a flaw in the logic depending of how one sees it. The amount of time limit that is set for each form should be proportional to the time it would take an average human being to fill in the form ...and I believe that this should depend on the amount of fields in each form. The login form is (usually) a two field form and if you add to that the fact that most users have their browsers set to remember and auto-fill those two specific fields (username & password), than it is simple a matter of 2-3 seconds.

[Graham-72]

It is sort of a flaw in the logic depending of how one sees it

Yes, perhaps, and maybe because there is no clear specification. There are two reasons why I think something is wrong:

1. The documentation suggests that honeypot does not operate on the user log-in form.
2. It is responding to the time interval between logging off and attempting to log back in, whereas I thought, perhaps wrongly, that it was there to detect log-in attempts that happen in quick succession.

[klonos]

whereas I thought, perhaps wrongly, that it was there to detect log-in attempts that happen in quick succession.

...then perhaps that is a solution: implement the time limit only after a form is submitted and there is an error. This way, the time limit will be applied on successive attempts but not the first one.

[herbdool]

I wonder if either of you can start a thread on the Drupal issue queue on this? It's a bit self-interested but I don't want to diverge from the Drupal 7 project too much at this point. If this is a general issue it's better to fix it there first than port it here.

[geerlingguy]

I haven't heard any reports of this issue on the Drupal 7 (or 8) version of the module... so I'm wondering if it's something to do with the Backdrop port / form structure.

[Graham-72]

I will install Honeypot on one of my Drupal 7 sites and see if I get the same behaviour, then I will know whether it is something specific to Backdrop.

[Graham-72]

After some fairly simple testing I can confirm that the problem shows up in Backdrop but not in Drupal.

An easy way to show it in Backdrop is to set the Honeypot time limit to 20 seconds, then log out and immediately try to log back in. Error message says to wait 21 seconds. Do the same thing with a Drupal 7 site, no problem.

[geerlingguy]

It could be that the login form ID is different in Backdrop than it is in Drupal. (Is it user_login_form?).

[Graham-72]

Form id = user-login in Backdrop

[herbdool]

@Graham-72 Please test the fix.

A couple dumb mistakes have been fixed. I added "user_login", "user_login_block" to json instead of just an update hook in .install. I've also fixed the comparison of forms to determine which to protect. Ideally we can drop the "honeypotform" altogether since it's on CMI not the db. But not necessary for this fix.

[Graham-72]

@herbdool thanks for this. I am doing some tests now and it does seem to have stopped Honeypot from protecting the log in page and imposing this timeout.

However, I am having a problem with the user registration page because spammers are submitting false registrations which Honeypot is detecting and logging, but not preventing the sending of an email response from the system. Do you know whether Honeypot is meant to stop the normal response to a user registration?

[herbdool]

@Graham-72 thanks for testing. I'll make a release and close this.

Your second item is best as a new issue, though if you've enabled honeypot for the registration page it'll work as well as it does for any other form.