in reply to enabling "Submit" button after X seconds.

Those robots don't use the button per say. Disabling it is useless.

What you could do is include the time the form was generated in a hidden field, then compare the current time against that field when the form is submitted.

I'm not saying that "disabling" the submit button for a period of time is the best solution, just how to achieve it.

  • Comment on Re: enabling "Submit" button after X seconds.

Replies are listed 'Best First'.
Re^2: enabling "Submit" button after X seconds.
by mrc (Sexton) on Jun 13, 2010 at 18:12 UTC
    With recaptcha it worked just fine till now, many, many months. I'm sure recaptcha was hacked recently because I started to get automatic submissions (different IPs) every 4-5 seconds during 1-2h, resulting in thousands of submissions and big server load. As disabling the button is impossible to achieve with perl I have to meter first access and last access. If difference is less than X seconds submission will not be processed. Seems the only solution at this time.
[reply]

      Are you sure that reCAPTCHA was hacked/cracked?

      And it's not a problem within your code? Show us your implementation

[reply]
        Yes, I'm sure. See also http://www.allspammedup.com/2010/01/google-recaptcha-cracked/ or check for "recaptcha cracked". Before implementation of recaptcha I had a lot of issues then script worked perfectly few months. We no longer can rely on captcha. None is secure.
[reply]
Re^2: enabling "Submit" button after X seconds.
by ahmad (Hermit) on Jun 13, 2010 at 23:19 UTC

    I don't think this is a good idea, a hidden field can be filled by those robots easily (it's just another input type).

[reply]

      The robot he described is a generic robot. It *won't* change the value to an older timestamp. It doesn't matter that it *could*.

      If we were talking about a robot that specifically targets his site, then you'd have a point. There are solutions for that too, such as the aforementioned encryption. (Public key encryption is unnecessary, though. Symetric encryption would be faster.)

[reply]

        That's what I mean, if his site was targeted specifically no matter what you have in that hidden field (encrypted or not) he'll keep getting those registration.

        For someone who would want to flood his form, he can spend 1 day fetching that form page 1 time/sec and save the "encrypted data" of that form, and in the next day he can do '86400' successful registration according to your method.

        if he locks it up to maximum of 1 hour , then it's 3600 successful registration per hour.

        if he's specifically targeted the only possible way is using 'recaptcha' and if that doesn't work , I would suggest saving the requesting ips and block them using .htaccess file "Deny from xxx.xxx.xxx.xxx"

[reply]
      a hidden field can be filled by those robots easily (it's just another input type).

      Use public key encryption, and encrypt the timestamp. If you can't decrypt the timestamp or its missing, you know a robot is trying to circumvent your throttling attempts, so you throttle it :)

[reply]

In Section Seekers of Perl Wisdom