Many Drupal contrib modules have inverse "feature flag" implementations vis-a-vis a killswitch variable added to settings.local.php to disable a feature:

// Killswitch setting.
$settings['disable_captcha'] = TRUE;

// Config override.
$config['google_analytics.settings']['account'] = '';

However, the Drupal 8 version of CAPTCHA does not yet have the disable_captcha killswitch that existed in Drupal 7 (see related issue #2836076).

The module does have another kind of killswitch via a Drupal permission skip CAPTCHA. This got me wondering:

Is it possible to dynamically add a permission to the current site visitor—both anonymous or authenticated users—at runtime for a specific environment without affecting the standard roles & permissions store so that configuration management/sync is not adversely affected by the environment-specific permission?

Ideally this logic would be located in settings.local.php to avoid the following risks and technical debt

  1. the chance that unintended environments would be affected, and
  2. to have to copy/paste/commit solutions to this problem in every client project only to have to later remove that code once the proper killswitch solution in issue #2836076 lands.

Yes you can but why not just remove the field ? here is a few ideas on to how to do it..

in settings.local.php

$settings['stop_captcha_from_being_stupid'] = TRUE;
// or 
$settings['enviroment_name'] = 'dev';

in some hook_form_alter

use Drupal\Core\Site\Settings; // above ^^^
$stop_capcha = Settings::get('stop_captcha_from_being_stupid') ;
if ($stop_capcha === TRUE) {

// or enviroment with custom header ;)
$current_request = $request = \Drupal::request();
if (!empty($current_request->headers->get('shutup-captcha'))) {
  if ($current_request->headers->get('shutup-captcha') == 'somesalt') {
    $environment_name = Settings::get('enviroment_name') ;
    $environments_to_allow_bypass_captcha = [
    if (in_array($environment_name, $environments_to_allow_bypass_captcha)) {
  • "but why not just remove the field?" Thanks. Those are novel solutions to the original problem but actually they don't answer the title of this question. The solutions are a bit more hackish than what I want to maintain (read copy/paste/commit) into every client project. The goal here was to look for a tidy solution without polluting the app with more custom logic & remove it later, hence why I'm asking if you can add a permission to a user on the fly in settings.local.php -- which you answered "yes, but"... so it would be interesting to see a followup answer to your "yes", if you know of one. – JamesWilson Jan 10 at 11:50

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.