Better results if honeypot-field is placed as first field

Hi,

We have the same issue in Drupal 8. Here is a patch we want to try out.

Cheers.
Tobbe

Any idea on how to do this for webforms? I tried changing the weight but it doesn't move the field.

I had a decent amount of spam messages with Honeypot in Drupal 8. Applied the patch from comment #2 to see if it improves results. FYI for me, it does not move the field to the very top but right above the submit button (which sounds like it may have better results then below).

@albertski - any better results in this position?

@geerlingguy Just took a look and I am still seeing some spam submissions.

To share some of my findings: yes, honeypot works better, when it's appearing higher in the form, at least it should be above submit buttons.

I'm using version 7.x-1.22, but not the patch provided in #2.
To be able to observe behavior over some time without worrying about patched code, I wrote a custom module using hook_form_alter().

My conclusion: moving the honeypot input field further to the top of forms significantly works better.

So either making weight configurable, or using a random weight would be a cool feature.
But at least a default weight not higher than 1 would help.

Following.
The module has been very helpful but just recently started letting spam through - after the security update to 8.5.1

I agree, the honeypot field should be above the submit button.

Thanks

Recreated the Drupal 8 patch with the latest.

@SalAG I have a feeling that the patch no longer applied. Try the updated patch.

Drupal 8 patch works perfectly.
Honeypot is not really stopping spam without this patch applied on the two sites I have it running on.

Setting appropriate status so patch gets tested.

Added a patch for 8.x.1.x-dev version so that it get tested again.

With the latest patch #14 the honeypot field is placed just before the submit button. So it works for me and hopefully prevents SPAM.

Thanks for the patch! I'm uploading a new patch because the one at #14 is no longer applying to the latest Dev code.

Please ignore patch at #16 - I messed up. This patch works on latest Dev release.

Sorry to spam the issue about spam (lol), but I just discovered I need to also weight the honeypot_time form element to get this to work (new patch attached).

For me, the patch in #18 does in fact put the honeypot input items at the top of the form.

Though, my form spam hasn't decreased noticeably.

Echoing @kentr -- #18 works in that the honeypot field is moved to the top of the form, but we've seen no decrease in spam as a result of the change.

@geerlingguy The patch in #18 still applies cleanly to 8.x-1.x. Several folks reported this change has no effect in reducing the number of spam submissions, but I suppose it wouldn't hurt to make the change if it would help even in the slightest way.

New features should go into the most-current version of this module first, then be backported if there is community interest.

Version 2.1.0

@kaloyan.damyanov: Why did you leave out the changes to the timestamp form element? See #18.

[IGNORE THIS PATCH]

I'm contributing a patch for 7.x once the 2.x patch gets committed.

Switching back to 2.x.

Played arround a little bit with the weight. 100 as default, which puts the hidden field behind submit actions, makes Honeypot nearly useless. -1 has for some reason a similar effect. Getting it between name and mail-Field with 2 reduced Spam to 0 (for the moment) and effectively triggering the "trap".

In my opinion this value should be configurable by the user via UI to find out which position fits best and give some flexibility over time to the user and less predictability for bots.

Also (but this is an other issue) the field label should be configurable. Last has at least some effect. I run multilingual sites and I changed the non-english label via translation, which reduced spam at least a little bit. But this may be just a subjektive point of view, so giving the user config-options adds flexibility and the comfort of best fit.

I still don't know how to make or work with patches yet (some day). But I did alter the code in the module's HoneypotService.php file to this:

		// Build the honeypot element.
    if (in_array('honeypot', $options)) {
      // Get the element name (default is generic 'url').
      $honeypot_element = $this->config->get('element_name');
			$alt_titles = [
				'website_address',
				'fax_number',
				'apartment_number',
				'maiden_name',
				'favorite_cereal'
			];
			if($honeypot_element == 'url'){
				$random_number = rand(0, 4);
				$honeypot_element = $alt_titles[$random_number];
			}
			$replace_underlines = str_replace('_', ' ', $honeypot_element);
			$label_title = ucwords(strtolower($replace_underlines));
      // Build the honeypot element.
      $honeypot_class = $honeypot_element . '-textfield';
      $form[$honeypot_element] = [
        '#theme_wrappers' => [
          0 => 'form_element',
          'container' => [
            '#id' => NULL,
            '#attributes' => [
              'class' => [$honeypot_class],
              'style' => ['display: none !important;'],
            ],
          ],
        ],
        '#type' => 'textfield',
        '#title' => $this->t($label_title),
        '#size' => 20,
        '#weight' => 0,
        '#attributes' => ['autocomplete' => 'off'],
        '#element_validate' => [
          [$this, 'validateHoneypot'],
        ],
      ];

    }

Based on some of the ideas in some of these related issues, I've added an array of element name options to be selected randomly if you leave the default 'url' option in the config page. It then replaces the underscore for a blank space to create the #title, redefining the element label and the element machine name at the same time. Lastly, I set the #weight option to 0.

Now the field appears first in the forms and randomly changes the field label and input ID and classes based on the 5 options I've provided.

The resulting HTML look slike this:

<div class="maiden_name-textfield" style="display: none !important;"><div class="js-form-item form-item js-form-type-textfield form-item-maiden-name js-form-item-maiden-name"><label for="edit-maiden-name">Maiden Name</label><input autocomplete="off" data-drupal-selector="edit-maiden-name" type="text" id="edit-maiden-name" name="maiden_name" value="" size="20" maxlength="128" class="form-text"></div></div>

I will continue to monitor the results. I just started using this module today and prior to making these changes, I was only seeing "time-base" results in the logs and still getting spam submissions. I will be trying additional methods but I will give this a few more days. Over the weekend we got hit with a non-stop attack that I was only able to stop by changing the access level of each of my webforms. Within minutes I had over 700 spam submissions come into my email. I just turned the forms back on this morning.

If anyone would like to turn this into a patch for me, I will love you forever.
:)

Drupal 9.5.11
Webform 6.2.2
Honeypot 2.1.3

As of today, spam is still coming through but Honeypot is registering more blocking in the log reports due to "honeypot field" usage rather than just "time" blocking. Before these edits to the module, I was not seeing "field" logs.