Force user_register policy unless modules/disable_user_register_protection.info exists

OK so this actually MAKES spam accounts happen. I realise there's a fix (make the control file) but I think BOA has overstepped its remit here...

My site was set to 'Admin only' for user account creation for years, then I updated, now I get loads of (blocked) spam user accounts because there's a change of behaviour and I haven't yet put in the disable_user_register_protection.info file. This logic is backwards!

My point is that BOA shouldn't be changing this at all outside some specific platforms (like Feature Server). It's a site-level config change that might well be wanted to be changed by a non-techie at many times during a site's lifetime. BOA shouldn't be forcing such changes IMHO. There are dozens of use-cases where an admin might want to change this.

I would like to see this feature fixed so it does not interfere with already built sites, and their administrator's work. Correct behaviour/Fixes would therefore include:

1. Making disable_user_register_protection.info into an opt-in by removing NOT in the if IF logic on line 438 of global.inc and having the .info file called 'enable_user_register_protection.info' instead, and tweaking the logic accordingly.
2. Doing this only on host8 systems as already done in the same file on line 85.
3. If BOA must force something, force email confirmation only.
4. Drop the whole IF section from line 483 and do this only on Feature Server platforms, effectively reverting much of the commit http://drupalcode.org/project/barracuda.git/commit/3b85755c8ec3efb74328a...

FWIW the sentiment behind these fixes is a good one, but the execution is clumsy. Another approach would be to include the either/both the excellent BOTCHA or SpamBot modules in the Octopus contrib modules and force-enable one of these -- it's a smarter way to stop spam IMHO.

Thank you.

Thanks. I didn't know abou the docs because they're new and were not linked in this issue, or in either commit.

It's just strange that an anti-spam feature actually allows spam where there wasn't any. It's not properly designed IMHO.

I'll make the appropriate control file.

Hi Robert, (and Grace and all the others that make BOA so good)...

Poor choice of words by me there, sorry... I completely appreciate all the thought, dedication and hard work that goes into BOA, and in turn the making my hosting of my client's sites a happier experience. In this case I was just surprised because I only ran octopus up-stable o1 platforms to install a platform and the next morning my inbox was full of spam account requests from several of my sites.

So in this (rare) case I think the decision to do this a hosting/server level wasn't ideal. It's a site-level thing, and the implementation made some assumptions that didn't work at all well for me. Already follow @Omega8cc, missed the announcement this time.

I think BOA is fantastic, but I have a suspicion that the global.inc logic is on the verge of needing a refactor, or even a Drupal/Aegir helper module. This way, the performance/bot stuff that should be done before Drupal boots can be done in global.inc, but the 'make drupal safer/cleaner/better site prefs can be managed from within Drupal where it logically sits. Another idea would be a 'local-boa-config.inc' on both site and platform levels that are included early in global.inc which can control these things more cleanly (kinda like the custom.global.inc approach) and allow a standard set of defaults to be more cleanly overridden.

I suppose what this boils down to is that I believe control files are great for many things outside Drupal (in Bash/Perl), but since we're already in PHP at this point a standardised config file and some nice clean functions might be more appropriate as the system grows. And, if those settings were editable from Aegir or the site itself then that would be really great -- not to mention better UX/DX since the help would be right there by the settings.

FWIW I'd be happy to assist in this should you guys be at all interested.

So I'm re-opening this one last time so that these thoughts can be commented on and if you consider these ideas as having potential please let me/us know how we can engage and build something nice. Otherwise close this and thanks for your help.

Because I too was affected by this on two of my sites, I would like to point to my proposal of #2034391: Document all control files and make it easy to find.

A registry of control files, with notifications when one or more is added, would be a nice direction.

While Twitter and App.net are great, they are not the most ideal solution to being notified about such changes. Personally, I rarely have Twitter open because I don't like distraction based working.

If you can show me 9 out of 10 people who DON'T open up email daily, then I will grant you that I am behind the times and should be checking Twitter just as much as I check email.

sendmail is already on the box and .barracuda.cnf has my address. ;)

Ouch! After this recent update, about 200 sites that where set to "Admin Only" have started to have spam accounts being created. They have all be forced down in security so now they are open to abuse.

I agree with the locking up when "Admin approval was NOT needed" - but it should never have locked down if the "Admin only" was set.

A better solution would have been to lock out the insecure option and to upgrade security for anyone with that set. But allow changes between "Admin Only" and "Admin Verification" - without needing the config file.