Even though it's possible to go into the configuration options for the module and change the field name, I still feel it's a bug to have the default name be "homepage." The comment form uses a field named homepage (at least for an anonymous commenter) that needs to be validated and is used to create a link to the person commenting. The comment form's field won't work properly when using Honeypot with the default settings. Therefore, I suggest that the default be changed so that people won't always have to go in and change it. Many people probably wouldn't even realize the conflict that is occurring.

How about choosing a default value of something like "viewpoint" since it's still general but not likely to be used by other modules?

I'm happy to write a patch if we can agree on a new default value.

I have not checked whether this is an issue in D6.

CommentFileSizeAuthor
#3 1811244-default-honeypot-field-1.patch3.45 KBfizk

Comments

geerlingguy’s picture

geerlingguy commented

Thanks for the bug report; I haven't noticed a problem on the comment form, though I don't know if I've used Honeypot on a site with anonymous comments yet... So I'll have to try it.

I might also want to make sure we test honeypot on a comment form, so automated testing catches bugs like this.

I want the field name to still be something that spam bots couldn't refuse to fill in, like website, or URL... They love fields like that, but might ignore innocent things like "nickname".

fizk’s picture

fizk commented

Looking at the HTML, Drupal's Homepage field is:

<input type="text" id="edit-homepage" name="homepage" value="" size="30" maxlength="255" class="form-text">
and Honeypot has:

<input autocomplete="off" type="text" id="edit-homepage--2" name="homepage" value="" size="20" maxlength="128" class="form-text">

so they're conflicting on the name attribute. This didn't prevent me from successfully submitting a comment, but it might throw someone of if they've written Javascript that acts on input elements with name="homepage".

I suggest making the default honeypot name "email". It won't conflict with Drupal's mail field:

<input type="text" id="edit-mail" name="mail" value="" size="30" maxlength="64" class="form-text">

fizk’s picture

fizk commented
Version: 7.x-1.13 » 7.x-1.x-dev
StatusFileSize
new 1811244-default-honeypot-field-1.patch3.45 KB

Here's a patch.

fizk’s picture

fizk commented
Status: Active » Needs review
geerlingguy’s picture

geerlingguy commented
Status: Needs review » Needs work

How about changing the field name to 'website' or 'url' instead of 'homepage'? I think having it be 'email' wouldn't be quite as helpful, because spammers don't care to fill out that field as much as a field with any kind of URL in it...

Any way we go, we'll run into the same issue that some forms will have an existing field with the same name (thus, the field is configurable :).

I would rather the field be a more enticing trap (like website, url, homepage, etc.) than have it not conflict.

fizk’s picture

fizk commented

I would rather the field be a more enticing trap (like website, url, homepage, etc.) than have it not conflict.

Really? Conflicting names would be a bug IMHO.

geerlingguy’s picture

geerlingguy commented

The trouble is, with the incredible number of forms out there (including user-generated forms, like those built by webform and custom node types), there's always going to be a risk that we conflict with a field name on some form.

So, the best option has to have the following aspects (ranked in order of importance):

  1. Desirable for spammers to fill out (URL-type fields are the most helpful and are targeted most often).
  2. Not conflicting with other field names (core uses 'homepage', 'mail', 'name', and a few others).
  3. Not randomly-generated or nonsensical (see #1).
geerlingguy’s picture

geerlingguy commented
Status: Needs work » Fixed

I decided to switch to 'url', since it doesn't conflict with anything in core. As a default, I think it's pretty safe. Obviously, this will conflict for some people on custom forms with fields named "url", but I would imagine this will be relatively rare otherwise, because core fields (from the Field API) are always prefixed with a 'field-[name]').

Commit for 6.x: http://drupalcode.org/project/honeypot.git/commit/8ff9222
Commit for 7.x: http://drupalcode.org/project/honeypot.git/commit/7365cc4

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) commented
Issue summary: View changes

clarify when the homepage field is presented