Removed the getName() method, updated the parent name to the fully qualified class, and changed setDefaultOptions() to configureOptions().

The parent class name is in the format of Namespace\ClassName instead of ClassName::class for < PHP 5.5.

This PR add a RedirectListener, loaded only if redirect is enabled.

The to option is replaced with url, and I added a route options (with route_parameters).

autocomplete="off" does not work in some cases, leaving the user alone with an unsendable form. Setting autocomplete="somerandomstring" works, so I propose setting it to "nope".

See https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

The implemented RedirectListener is not working anymore since Symfony 4.4+

Since Symfony 4.3, most of the event classes were renamed. The following old classes were deprecated: ... FilterResponseEvent renamed to ResponseEvent

See: https://symfony.com/doc/4.3/components/http_kernel.html#creating-an-event-listener

Because version 2.0 suggests to support Symfony 5, this must be changed as well.

Using Symfony 4.2.4 and HoneypotBundle 1.2.1 I get a Twig_Error_Loader Exception because your template can't be found/resolved. Template reference "EoHoneypotBundle:Form:div_layout.html.twig" not found, did you mean "@EoHoneypot/Form/div_layout.html.twig"?

I suggest using the @EoHoneypot/Form/div_layout.html.twig resource instead of EoHoneypotBundle:Form:div_layout.html.twig in your FormCompilerPass class.

Since the documentation says we should add the bundle with dev-master I'm currently getting failed requirements when updating composer since the dev-master requires symfony 3.0 and my project runs on ~2.3

In Symfony 2.8 your Bundle throws a deprecated notice.

You need to add the configureOptions() Function to replace the setDefaultOptions() Function in HoneypotType.

Can we get a new tagged release? I just ran into this error

  [Doctrine\Common\Annotations\AnnotationException]                                                                           
  [Semantical Error] The annotation "@Doctrine\ODM\MongoDB\Mapping\Annotations\Document" in class Eo\HoneypotBundle\Document  
  \HoneypotPrey does not exist, or could not be auto-loaded.                                                                  

Locking version against dev-master fixes.

Hi,

I just moved the form type to the request scope in order to remove the container injection. I didn't use the RequestStack to stay compatible with sf < 2.4.

I also refactored a bit the files.

An error was not solved with commit 95d297627a

1. Using $this when not in object context in %mydir%/vendor/eo/honeypot-bundle/Eo/HoneypotBundle/Form/Type/HoneypotType.php line 44

To solve this problem please replace row 42 with the followings two lines:

$container = $this->container; 
$builder->addEventListener(FormEvents::PRE_BIND, function(FormEvent $event) use ($container) {

then replace every occurence of $this->container with $container (in rows 45, 46 and 52).

This works with

database:
     enabled: false

and

file:
     enabled: true 

in config.yml (not tested with different config)

Fixes #17.

The option is set in such a way that the default remains the same as before and is backwards compatible.

The reasoning behind not showing an error is primarily not to make bots suspicious; some bots that encounter errors after submit, will try submitting again with different combinations of data until they get a 200 status code.

Of course, this assumes that the user handles the "bird in cage" or "honeypot triggered" event or status by himself, which is intended.

In order to complicate automated mass-submissions of forms, one possible solution would be to include a hidden field in the form that includes a timestamp, plus a second field that contains an HMAC for this timestamp value + a secret value.

Upon submission, we could check if the timestamp is legit (the HMAC signature is correct) and falls into a configurable range – so for example, only accept form submissions for forms rendered at least 30s ago and not older than 4 hours.

This does of course not prevent automated form submissions, but would at least require that forms be fetched periodically and kept on hold for some time before they can be ~~ab~~used.

The timestamp + HMAC cannot prevent the same form from being submitted multiple times, but it has the advantage that we do not need to keep state in the backend.

Another approach would be to issue unique form-IDs, but that would require some tracking mechanism (a database, key-value-store, ...) to keep the issued IDs, remove submitted and expire old ones. That would be more involved to set up.

For sure, it's not a perfect solution – but anyway, is that something you would support in this bundle and that you would accept a PR for? Or is this outside of what this bundle tries to provide?

I am under the impression that if the submitted form does not contain the honeypot field at all, it is accepted as well.

Would it make sense to make this check more strict and also reject the form if someone tries to submit an older (cached) version of the form without the field?

Would you accept a PR for that?

The login form in FOSUserBundle does not have a LoginFormType or equivalent, is just a form HTML markup added in a twig template which I can override: https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/views/Security/login_content.html.twig

I'm still not sure how to add the Eo\HoneypotBundle\Form\Type\HoneypotType field provided by this bundle under this scenario.

Can someone help to point me in the right direction?

Using the class HoneypotPrey extends BaseHoneypotPrey configuration as shown in the example, I was getting this error when running app/console doctrine:schema:update --dump-sql:

[Doctrine\ORM\Mapping\MappingException]
Duplicate definition of column 'id' on entity 'ExampleBundle\Entity\HoneypotPrey' in a field or discriminator column mapping.

I then tried extending Eo\HoneypotBundle\Model\HoneypotPrey instead of Eo\HoneypotBundle\Entity\HoneypotPrey, and that worked as far as the schema update was concerned. I had two tables - HoneypotPrey with just the id column, and honeypot_prey with the columns id, ip, and createdAt. However, after submitting some test spam registrations with the honeypot field populated with data, I was only getting new rows in the HoneypotPrey table (and lines appended to honeypot.log), but nothing in the honeypot_prey table.

So, instead, I mapped the schema like so (sorry, not a fan of annotations)...

ExampleBundle\Entity\HoneypotPrey:
    type: entity
    table: HoneypotPrey
    id:
        id:
            type:   integer
            generator:
                strategy: AUTO
    fields:
        createdAt:
            type:     datetime
        ip:
            type:     string

... generated the entities, copied the __construct() method from Eo\HoneypotBundle\Model\HoneypotPrey into my Entity class, modified my Entity class like so...

namespace ExampleBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Eo\HoneypotBundle\Model\HoneypotPreyInterface;

/**
 * HoneypotPrey
 */
class HoneypotPrey implements HoneypotPreyInterface
{
    ...

... dropped the honeypot_prey table, and reran the schema update command. I'm now getting records in my HoneypotPrey table...

mysql> select * from HoneypotPrey;
+----+---------------------+-------------+
| id | createdAt           | ip          |
+----+---------------------+-------------+
|  4 | 2015-01-14 00:05:56 | 172.16.61.1 |
+----+---------------------+-------------+

Configs are set like so:

# Honeypot
eo_honeypot:
    storage:
        # Record for reporting
        database:
            enabled: true
            driver:  orm
            class:   ExampleBundle:HoneypotPrey
        # Log for IP banning using fail2ban
        file:
            enabled: true
            output:  %kernel.root_dir%/logs/honeypot.log