Problem/Motivation
When provider settings are loaded for auth plugins they don't always include overrides.
This code from the drush command to refresh loads overrides:
if ($provider = SalesforceAuthConfig::load($providerName)) {
$auth = $provider->getPlugin();
but the way it is loaded on the edit form does not (at /admin/config/salesforce/authorize/edit/{salesforce_auth})
I suspect there are other places where it isn't loading overrides, because when it's loaded through the SalesforceAuthConfig class it lacks overrides
We are using one auth plugin and switching values on the plugin between production and and test environments. Our default config is like this:
uuid: abc123
langcode: en
status: true
dependencies:
config:
- key.key.salesforce_key
module:
- salesforce_jwt
id: salesforce
label: Salesforce
provider: jwt
provider_settings:
consumer_key: 'Overridden in settings.php'
login_user: 'Overridden in settings.php'
login_url: 'http://overridden-in-settings-php.com'
encrypt_key: salesforce_key
When we pull the production site down to the test site, we run the drush command to refresh the token, which sometimes works and sometimes doesn't.
I find that when the plugin is loaded through the UI, such as on the editing form, it doesn't show the overrides. I suspect in some other instances, it's being loaded without the overrides.
I think if it loads incorrectly through the UI, it fails to refresh or revoke the token.
When you are editing the provider, due to the temporary values not passing validation, you can't save the edit form, which says it would refresh the token.
So it appears there's no way through the UI to refresh the token. Can't we have a "refresh default token" button in the UI?
I can fix this by entering the values for an environment, saving the provider form and clearing the cache, then the mapping objects show the correct instance URL.
I think loading the overrides from settings.php is an important thing to do, it works for drush, which I believe is right, but it doesn't work other places. I know other configs will show overrides on the config edit form. So I don't think it's going to break anything to display the overrides on the edit form. Resaving an edit form on an environment so that the config matches the overrides doesn't break anything. Having them mismatch is a bigger problem, and I recommend we update the way the settings for the plugins are loaded to include the overrides.
Steps to reproduce
1. Upload the config above and set as default provider
2. Override as follows with valid credentials:
$config['salesforce.salesforce_auth.salesforce']['provider_settings']['consumer_key'] = 'valid consumer key';
$config['salesforce.salesforce_auth.salesforce']['provider_settings']['login_user'] = 'it@mysite.com.devfull';
$config['salesforce.salesforce_auth.salesforce']['provider_settings']['login_url'] = 'https://test.salesforce.com';
3. try save the config form.
Proposed resolution
add this code:
$this->provider_settings = $this->authManager()
->getConfig($this->id())
->get('provider_settings');
into SalesforceAuthConfig::getProviderSettings
/**
* Wrapper for provider settings to inject instance id, from auth config.
*
* @return array
* Provider settings.
*/
public function getProviderSettings() {
// Get overrides.
$this->provider_settings = $this->authManager()
->getConfig($this->id())
->get('provider_settings');
return $this->provider_settings + ['id' => $this->id()];
}
This will pull the provider_settings with overrides from settings.php
This will allow resaving the form on an environment, then clearing the cache to fix when the urls are pointing to production.
Ideally, you would be able to edit the original values within the form, but if you are going to validate, you can't use placeholder data as I'm doing.
The alternative would be to have two providers and switch dynamically, but that doesn't work right now either, because the default provider isn't overridable as mentioned in
✨
Add ability to detect config overrides and invalidate token
Needs review
Remaining tasks
User interface changes
API changes
Data model changes