Spambots targeting Drupal sites are already a plague, so we should force reasonable default policy for new accounts registration, as below:

* Visitors, but administrator approval is required (forced default)
* Require e-mail verification when a visitor creates an account (enabled)

If you wish to disable e-mail verification or set "Who can register accounts" to "Administrators only" or "Visitors", you must create a control file in sites/ and then change these settings in the site.

Wed don't force "Administrators only", because it could immediately break many commerce or community sites essential features. But for other sites, "Administrators only" is strongly suggested.

It is also a good idea to check (really, do this, you may be surprised) if your sites are not already "taken over" by spambots - we have seen too many sites with 10k or even 50k spambots accounts created, not to mention *tons* of spam added, which even if not published, can slow down your site seriously anyway.


omega8cc’s picture

Status: Active » Fixed
omega8cc’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Jim Kirkpatrick’s picture

Status: Closed (fixed) » Active

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 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 into an opt-in by removing NOT in the if IF logic on line 438 of and having the .info file called '' 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

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.

omega8cc’s picture

Status: Active » Closed (works as designed)

Have you read related docs?

This is a kind of one-time inconvenience to provide an absolute minimum of protection for hosted environment without introducing problems for the end-users - sites visitors, since we can't assume that you control/administer all sites hosted on the system.


Jim Kirkpatrick’s picture

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.

omega8cc’s picture

"It's not properly designed" is a bold statement. Feel free to suggest something better, which would work not only for your own use-case.

I would recommend to watch our Twitter and/or streams for updates, or at least subscribe to our RSS feeds on the site, as we have announced this there.


Jim Kirkpatrick’s picture

Status: Closed (works as designed) » Active

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 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, but the 'make drupal safer/cleaner/better site prefs can be managed from within Drupal where it logically sits. Another idea would be a '' on both site and platform levels that are included early in which can control these things more cleanly (kinda like the 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.

omega8cc’s picture

Status: Active » Postponed

Well, the way this change was handled was for sure unfortunate.

In fact, it was introduced in an emergency mode, because many of our servers suffered from sudden and random load spikes for a few weeks, and we have determined that it was because of some wide spread spambots attacks we have never seen before on that scale, affecting sites with too open new accounts registration policy.

We have tried to fight this for a few weeks, hunting for sites targeted and improperly configured, but it was not effective enough, so to protect all our clients who do care about security and proper configuration like you do, from being indirectly affected by this new wave of spambots attacks emerged, we have decided to force settings, which introduce protection for unprotected sites, but also don't break possibility to self-register, when required, and introduce a one-time inconvenience as a price for a long-term protection from systems instability.

Also, we have applied this to the stable, because the head is not yet ready for production. We normally announce such changes on BOA releases and upgrades, but since there is no new Drupal core version expected this month, so probably also no BOA new release, we could only announce this on our website, Twitter and - we should probably do this better, post something on g.d.o etc.

So, we are open for any good ideas. It just almost never happens that we could review someone else patches, just requests for features etc. so if you have an idea on how to do this particular change/feature better, please share the concrete ideas!

Note also that almost everything included in the simply can't be converted to module, for rather obvious reasons. And scattering this around in many sub-sub-includes etc sounds like a recipe for serious trouble to me. There are already two includes in the supported for early and final overrides.

I'm postponing this until there will be some patch for review! :)


mattman’s picture

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 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. ;)

Anonymous’s picture

What about the user_verify module (

This module extends Drupal's user verification in order to bug site spammers' lives at least a little bit. For sites configured to allow user registrations without admin approval, new users are not immediately activated but remain in status "blocked" and an additional verification code is being generated. This code may be sent out instantly as well or (recommended) with a configurable delay so the efforts to configure a spambot will at least increase a bit. The new user remains blocked until he verifies properly and if he does not within a custom time limit, his account will be deleted automatically and in the background. There is some more little bullying - hardly harmful to serious users but annoying for the unwanted ones.


Although the user's chosen password is valid instantly after registration, all login attempts will fail until the user has verified with the special token. If he tries too early and too often, he will remain blocked and if he fails to validate, he will be auto-removed after a configurable time. However: No spam prevention is perfect or eternal as spammers evolve. But if playing cat and mouse helps it for a while, why not try.
It is strongly recommended to alter your registration email templates on the accounts settings page to clearly instruct your new users about the verification process.

Installing it automatically bypasses the normal user registration flow, so would this boa control file still be needed?



Anonymous’s picture

Additionally, re the original post - In order to get modifications to the user registration settings to be saved - so the change appears in the admin GUI, I had to disable user locations from the location module, make the change, which then did show as changed in the GUI, and then re-enable user locations. This does not mean that the change was actually having an effect - just that it appeared changed in the admin GUI.

omega8cc’s picture

@EdNet - Using extra module doesn't solve the problem and even makes it harder to solve.

omega8cc’s picture

@mattman - The correct solution to this is to simply never modify Stable Edition like this and just release new Stable when any change like this is required, so we can use normal and expected communication channels -- release notes, changelog and upgrade e-mail.

geoff’s picture

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.

omega8cc’s picture

Status: Postponed » Needs work

I think that both the "fix" and the way it was introduced was really a bad idea. While it is not possible to determine on the level if the site already has secure settings and what security measure would be best etc. we should do this in the /var/xdrago/ script instead, where we can:

1. Check the value of the actual variable per site.
2. Create an "OFF" control file only if the registration is wide open and there is no "ON" control file present.
2. Force/set secure variable in the DB directly, but only if the registration is wide open and there is no "ON" control file present (site and platform level)

The implemented method to force "Admin only" mode per platform and per Octopus instance is for sure useful, but the other part of this "fix" must be changed.

omega8cc’s picture

Status: Needs work » Fixed

This should be fixed in the commit: (will be applied also to stable, since we don't have any ETA for a new release yet)

We no longer force anything live in the file (with exception of feature_server and hostmaster profiles). Instead, we use the running maintenance script to detect actual variable per site and set it in the database directly, only if needed. This allows us to avoid opening moderated registration if the site already has "Administrators only" mode turned on. The logic for control files, as explained at remains the same - we just use it in the running script instead of check them live on every request. This allows to force safe defaults daily and to override them still in the site admin area (until the next run).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.