Allow overriding of auth provider settings.

Bumping this in priority and tagging it as it's a security issue to not support overriding the OAuth settings via PHP in e.g. settings.local.php.

I updated the included README.md file in the MR to note the correct variable name and structure.

Ran into a symptom of this today: 🐛 Failed authentication should not change default Active

One interesting detail is that if you override $config['salesforce.settings']['salesforce_auth_provider'] in settings.php the admin/config/salesforce/authorize/list page shows the change immediately.

There's a bug with the proposed change when multiple configurations are defined - the connection details from the default auth provider is shown on the authorize/list page for all connections, not just the one it affects.

This shows the list page without the patch or any changes to settings.php:

This shows the list page without the patch and with the $config['salesforce.settings']['salesforce_auth_provider'] and $config['salesforce.salesforce_auth.legacy_oauth']['provider_settings'] defined in settings.php:

This shows the list page with patch and without changes to the settings.php file:

This shows the list page with the patch and with the settings.php changes:

As you can see, with multiple configurations it retains the default settings when it shows all settings items.

Another issue is that the state value named "salesforce.auth_tokens.IDENTID" is an object, which will be hard to override.

FYI I ended up handling this via an extra Drush command that runs after we run "drush deploy", with this code:

    $config_name = 'salesforce.salesforce_auth.legacy_oauth';
    $old_config = \Drupal::config($config_name);
    if ($old_config->hasOverrides()) {
      $config_factory = \Drupal::configFactory();
      $new_config = $config_factory->getEditable($config_name);
      $new_config->set('provider_settings.consumer_key', $old_config->get('provider_settings.consumer_key'));
      $new_config->set('provider_settings.consumer_secret', $old_config->get('provider_settings.consumer_secret'));
      $new_config->save();

      $this->io()->writeln(dt('Salesforce credentials updated.'));
    }
    else {
      $this->io()->writeln(dt('Did not update the Salesforce credentials'));
    }

It loads the configuration of the "legacy_oauth" authentication config, checks to see if it was overridden via settings.php, and if so re-saves the values into the config object.

When inspecting the incoming patch, my IDE flagged "Too many arguments to function getConfig(). 1 provided, but 0 accepted.".

I have created a new merge request, correcting ->getConfig($this->id()) to ->getConfig().

On another note, I tried using https://www.drupal.org/project/coi → alongside this patch, and it didn’t work out of the box for the Salesforce auth provider form.

This is because the form elements do not include a ['#config']['key'] definition, so COI has no context about which configuration keys they relate to. While this can be resolved by modifying the form to include these keys, it might be worth discussing whether this should be handled upstream in the module.

As a workaround, I added the following hook_form_alter() implementation in a custom module:

use Drupal\Core\Render\Element;

if (
  $form_id === 'salesforce_auth_form' &&
  ($provider_id = $form['id']['#default_value'] ?? NULL) &&
  ($provider_settings = $form['settings']['provider_settings'] ?? NULL)
) {
  foreach (Element::children($provider_settings) as $setting) {
    $form['settings']['provider_settings'][$setting]['#config']['key'] =
      "salesforce.salesforce_auth.$provider_id:provider_settings.$setting";
  }
}

I hope this helps!

Further to my previous comment, i’ve updated the merge request and attached a new patch that includes support for #config_target on the salesforce_auth_form.

Previously, I noted that the form did not work out of the box with the Config Override Inspector (COI) module because it lacked the necessary context to identify which configuration keys the form elements relate to. I was working around this by injecting ['#config']['key'] values using a custom hook_form_alter().

With this patch, that workaround is no longer necessary. Adding #config_target directly to the form provides the needed context. This benefits both COI and Drupal core, as core’s config override system (since Drupal 10.2) now uses #config_target for identifying and reacting to overridden config values.

I have also submitted a patch to the COI module to support #config_target, which complements this change:
https://www.drupal.org/project/coi/issues/3409747#comment-16201736 📌 Use the new #config_target Form API property Active

Together, these updates ensure that configuration override behaviour works as expected, without requiring contrib or custom modules to add missing metadata.

Let me know if any adjustments are required.