botcha preventing first time registration, then allow second time

"no resubmit" block happens only when Botcha detects that an old form id was submitted. if the user did not use that form before, it means that somehow he was served a cached version of the form. Please check your webserver configuration. Any second-level caching will cause this problem. There's nothing that can be done in Botcha to work around server-side caching.

Botcha ensures there's no caching in Drupal for the protected forms, so each form is always built anew. If your webserver has other page caching mechanism enabled, or have another caching software, it will mess it up. BTW, if your Drupal configuration change HTTP headers to allow client-side caching (in the web browser), it will also break Botcha.

When first submission fails Botcha, the URL actually is different from the first one. It makes the cache think the page is new and let Drupal build it. That's when Botcha works correctly and second submission is passed the validation.

I did some poking around your website, and your problem looks more Drupal-related. It looks like only the very first register page fails with Botcha "no resubmit". Then either second try (when Botcha presents new form with new URL), or if I go to initial registration form with minimal URL, then Botcha passes. I would recommend isolating potential suspects in Drupal: disable all performance or caching related features (core and any contrib modules). If Botcha starts working properly, then enable them one by one, until the culprit is found.

Thanks for this additional information. It does narrow the problem down significantly. This means that somehow Drupal core cached the registration page despite Botcha's mechanism of disabling cache for this particular page. There must be something else with your setup and configuration that messes up the no-cache mechanism, as there's no other site that has been reported to do that. Since you already tried clearing Drupal caches, I'm out of ideas.

I didn't get whether it is about drupal setup or apache configuration, php.ini , .htaccess.

In #7 I said that the problem is narrowed down to Drupal alone, nothing to do with your server.

Disabling "no resubmit" recipe is a viable workaround, however it is one of the most powerful protections against spammers who can manually submit a form, then copy its fields and submit as many times as they want (from a script).

I just ran into this today. I have been using botcha on my wife's site with no problems. However, today it just started doing this exact same thing on the registration page. Sucks because she ran a promotion that had a ton of traffic and no one was able to sign up for the site and take part. Enough for me to never be able to trust this module again but I still wanted to come over and let you know that it's happening on more than one person's site. I have no 3rd party caching modules and use only core.

For other people who are thinking about this this module, I would highly recommend you look elsewhere. Normally I don't like knocking people's work but we did lose a lot of money today and that warrants negative reviews. This may be a core issue or maybe some other module, but it's your module's error that is getting triggered and if it is a core issue, it's up to you to make your module play nice with core. A 3rd party, ok. You can't make it work for every other module on the planet, but so far it seems like you've identified only core modules.

I have to take this module down and try to salvage some of the loss from today but if you do happen to want to see it in action, let me know and I can turn it back on in a dev environment or just for a few minutes on the production if you wanted to coordinate some time or something.

user_register_form post blocked by BOTCHA: submission looks like from a spambot.

Failed 1 of 5 recipes [no_resubmit] from "default" recipe book.

@RKS

Normally I don't like knocking people's work but we did lose a lot of money today and that warrants negative reviews.

Your story is truly touching.... How much exactly did you pay for development of Drupal and contrib modules? How much money are you planning on making?

If you are loosing money, maybe you should hire someone to make it work for you if you can't make it work yourself. This module was written during very long UNPAID hours by volunteers. Your expectation for a software which is "free as in beer" needs reality check. I won't quit my day job to fix it for you. If you don't like a module, your options are:
1. Don't use it
2. Fix it and submit patches
3. Hire someone to fix it.
Otherwise be polite and stay constructive. So far you posting has zero value to advance state of things.

Oh boo hoo. Sing the sad song of the Drupal module maintainer and hope your cries and violins are fooling everyone. We all know how open source works yet you Drupal maintainers love using "unpaid volunteer" card whenever you can try to deflect the quality of your work. We all know you aren't Stallman over here working tirelessly to improve the industry for the good of all man. We know in the end you do this work the same reason why Dries created Drupal in the first place; so he can get paid a lot of money to use it and create sites like whitehouse.org. I know you love painting the picture of you slaving away at a computer for long hours trying to write a module that will revolutionize the way people use Drupal and all you expect in return is feeling that you have helped your fellow man and because of this, we should all just be grateful for your "unpaid volunteer" hours regardless of whether it is of high quality or not. It does not need to work because it is "unpaid volunteer" hours. Yes, please tell me, to which account should I deposit some bitcoins for your well-deserved work? Obviously you have shown you are worth paying for this support.

Insinuating I am unwilling to pay for development work is laughable and the first recourse for any maintainer who feels threatened by a comment. Please tell me, as a developer, do you immediately rewrite every module you find from scratch? Have you rewritten the blog module in Drupal core? Or do you know this module is already finished and in production and it is safe to use? No. I did not immediately hire someone to write a module that already exists, is not in rc or beta and I assumed you were of reputable integrity and would stand behind your declaration that your module was production ready. I guess not.

As far as reality goes, you, sir, are the one who needs a reality check. If you truly believe users will not expect your module not to break their registrations then you are the one who needs to look in the mirror. It seems to me from your statements that you don't even fully grasp what maintaining a module is all about. If you cannot, or are unwilling to maintain a module without crying about your "unpaid volunteer" hours, you have several options yourself:

1) Don't write free modules.
2) Get a co-maintainer or a few.

Otherwise, just be upfront and honest with everyone. I never demanded you "quit your day job to fix it" or anything like that. I didn't bump the thread every hour waiting on a response, I actually told you I was willing to let you look it it in production and see for yourself at a time convenient for you. Every report about the exact problem is valuable. You should know this as it means this isn't a one-off type issue that is only happening to a single user. You should understand this and it goes to add to the statement I made above that you aren't fully grasping what a module maintainer is supposed to do. No one demanded anything from you but if you can't take criticism, you need to go do something else. Do you really truly feel people don't have a right to give you a negative review because you didn't get paid by this one site for using your module? Do you really expect the burden to be on everyone else who trusted your production ready claims and it broke their registration? So you really think when someone loses a lot of valuable traffic they are just going to say, "Well golly...it's all my fault because I trusted the Botcha module. He said it was production ready but I sure should have known better than to trust that. I should've known it wasn't going to work and just hired someone from the start to rewrite the module." Your statements basically mean no one should ever even use Drupal. You can't trust Drupal to work because you haven't hired someone to rewrite it. Get a life and start standing behind your work. If you don't have time, say you don't have time but don't try to be a jerk and try and pass the buck on to everyone else.

I also spent some of my hard "unpaid volunteer" hours looking over your code and I've determined where the issue is. I have fixed it on my side; however, after your display you're going to have to ask very politely for me to take more of my "unpaid volunteer" hours to submit a patch. Sorry to everyone else, but that's the "reality" of poor module maintainers.

Nice attitude, dude.
1. Other modules are patched and submitted in volume.
2. Co-maintainers are welcome - check the project page.
Check facts before trolling.
3. Criticisms are welcome, but issue queue is not for negative reviews or flame wars - it helps no one here. I'm fully aware of the situation and wish I could change it, but I have very little bandwidth these days. Demands or threats or negative reviews like yours are not helping anyone and have no constructive value. "Invitation" to check your devsite is very cute, but not sweetening the pill since you open with flames.

Your submitted patch will go much longer way and maintain world peace.

Stop trying to deflect. I perfectly stated in my post I made no demands from you. I also don't see where the "threat" and "troll" part of your statement comes in. You don't have to respond to my comments. It's obvious you have no response since you keep wanting to make things up like stating there has been a "threat" and you certainly don't want to address any of the real issues I noted. It's fine, you have nothing to say in response because I'm I'm right but stop making things up as well. Don't call people trolls when your actions are the trollish ones. You take one sentence, realize you cannot defend against anything else, and focus on only that one point, trying to create a straw argument and deflect the responsibility to everyone. Had you just manned up and said you don't have bandwidth in the first place that would have been the end of it. But you played the pity card and started this whole mess. Take a deep breathe, forget about trying to respond to this message. Reread my post above, take notes and let it teach you in the future how you should think about your role as module maintainer. Take this all as a valuable lesson on how to take responsibility for the modules you create and not try to put it it off on other people. You don't have time, then you don't have time.

Taking responsibility will go "much longer and maintain world peace."

I must have missed the part in GPL stating one must commit to master and never fork. Please tell me more about this important clause as many open source projects will certainly be affected. No wait, I think I might have figured out where it is. I think it's probably in the same section detailing how you must contribute to people's projects when they're being total jackholes. Is it in that section?

While we seem to be getting a bit off-topic here, I think this is a good object lesson. Never trust any software, whether you pay for it or not. As a site maintainer it is your responsibility to make sure that a module works as promised before you put in on a production site.

And if it breaks something, don't get mad at the author unless you find out that it was something that he did or ignored on purpose. Maybe you didn't mean it @RKS , but that's how you sounded in #14. Did you expect iva2k to do a couple test registrations on your wife's site before you took it live?

In the future, keep it simple. State the nature of the bug, offer any pertinent data, and suggest that the bug is critical enough that it be reported on the front page until it is fixed. There's no need to get personal. You'll get a lot more cooperation this way. And if you find the solution, share it. That's how Open Source works. To state publicly that you know how to fix something but will not share it so that other people can lose money as well is just wrong.

Hello,

BOTCHA is a module based on a great idea. Thank you for the efforts.

I just would like to share my experience. (I found the issue is related to ObscureUrl, not cache!!!)

I installed it one month ago (in my production site). I read this post before I installed. BOTCHA did block some robots attacks (thanks), but it also block some real users. BOTCHA blocked re-summit in the registration from, even it was just a little error such as without checking Terms and conditions or the password was not matched (I suppose this according my personal tests on the tested site in PC).

In my cache setting, there is nothing cache function checked (as I said, I read this post before). In my test web, I even change DEVEL module Configuration → Development → Devel settings. check "Rebuild the theme registry on every page load". The BOTCHA still block my register actions.

So I start to think it is not cache problem. I then find https://www.drupal.org/node/1926150. Finally, when I disable ObscureUrl recipe, it stops blocking registration. I spent hours to know this so please ensure to check this post too if you have this issue.

hosais

I also fixed this by disabling ObscureUrl in the settings (Configuration > People > Botcha > Recipe Books > Default). Checking my logs revealed that each false positive was associated with the [obscure_url] recipe.

As @hosais pointed out in #24, there is a separate thread dealing with this, in which they are trying to find a solution that doesn't involve disabling ObscureUrl.

This really sounds like it's a dup of #1926150: Resubmitting a failed form always fails with ObscureUrl enabled - feel free to reopen if there's evidence this is not the case.

Re-opening as I think there is indeed a different issue here in addition to the obscureUrl problem. I've just had some reports of real users being blocked when they attempt to register on a site and the site already has obscureUrl disabled because I'm aware of the other issue.
I've just reproduced it as well. I clicked once on the register link on my site home page, filled in the username and email address then clicked once to register, nothing else. No back button used. I got the exact same error message reported in the first post in this thread. In the log I have:
Failed 1 of 4 recipes [no_resubmit] from "default" recipe book.
I then went back to the site home page and repeated the process again. This time it worked. I'm going to try disabling the page cache for anonymous users since my site is mostly used by registered users anyway to see if that fixes it, but there does seem to be an underlying problem.

Sorry - re-opening as stated above.