Child pages
  • Dealing with bots submitting our forms
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/709f3e710b1139d0#

Any of you probably heard about spam bots, which submit spam to forms on our websites.

Most obvious solution would be to place a captcha on a form. But I don't like captchas because they make entering data on a form a lot harder for me. If I see form with a captcha I'll better go to another website without
captcha and fill out form there.

If you think the same, then reading http://nedbatchelder.com/text/stopbots.html article might become handy. Ned there describes popular techniques to prevent bot submissions.

Related Discussions

4 Comments

  1. I remember you've posted about this 2 years ago, and you were proposing to add a javascript which generate a code. Because bots don't execute JS, they wouldn't have this code in form submission, and wouldn't be able to submit it.
    Would this technique still works?

    Envoy

  2. Sure. Only if I can find that post with details of that technique.

    I don't know why it wasn't implemented right away since it's really
    automatic and doesn't bother user with entering any weird stuff.

  3. After reading http://nedbatchelder.com/text/stopbots.html we've chosen a Honeypot approach to be the one, that is getting us instant benefits.

    The approach can be implemented in the following way:

    1. add an input field with attractive name (e.g. "email" or "firstname") to the form
    2. make that input field hidden through CSS class
    3. upon form submission check if that field was filled-in
    4. since user don't see the field, then in 100% cases filled field means, that bot submitted a form
    5. skip any form processing (e.g. record adding to db) and redirect user to Thank You page as if form was submitted normally

    P.S.

    I also like other protection methods, discussed in the article, like:

    • spinner
    • timestamp
  4. Applying this honeypot approach globally right now isn't possible, because in current OnCreate event implementation (event, that is used to add new records to database) some additional actions are taken (besides doing redirect), that shouldn't be taken in case if Honeypot check fails.

    I see implementation as follows:

    1. we need to introduce new event status called kEvent::erFAIL_HONEYPOT that would mean, that Honeypot check failed and event itself should react to it
    2. every event, that is checking event status through $event->status attribute must be patched to properly react on new status (don't do anything, but redirect template preparations)
    3. create kEventHandler::eventHoneypotFields array (key is event name, value is honeypot field name on that form), that would only contain event, that support Honeypot protection
    4. create kEventHandler::checkHoneypot method, that would be called prior to event name, submitted from Request and set initial event status to kEvent::erSUCCESS or kEvent::erFAIL_HONEYPOT based on method call result

    Not sure though about following things:

    • should we allow to set custom honeypot field name per-event or let it be "email" field all the time
    • would it be possible to enable/disable honeypot protection in Admin Console settings
    • if we enable honeypot protection in PHP and don't update project's theme, then that form:
      • won't be working at all (all form submits will be considered as bot submits and rejected)
      • or trigger a notice, that honeypot protection isn't active until I add a "email" field