Bug #57289
closed
Respect additional configuration file for silent configuration upgrade
0%
Description
The SilentConfigurationUpgradeService only uses values from the LocalConfiguration.php due to using \TYPO3\CMS\Core\Configuration\ConfigurationManager::getLocalConfigurationValueByPath().
However, the AdditionalConfiguration.php may also contain user values for configuration settings which should be respected.
An example: if you move SYS/encryptionKey from LocalConfiguration.php to AdditionalConfiguration.php (e.g. to keep it out of a VCS), a new encryption key is generated in SilentConfigurationUpgradeService::generateEncryptionKeyIfNeeded() and stored every time the installation tool is accessed. The value from the AdditionalConfiguration.php should be considered instead. If the value is present in the AdditionalConfiguration.php but not in the LocalConfiguration.php, the value should not be written to the LocalConfiguration.php, of course.
Updated by Markus Klein about 10 years ago
- Target version deleted (
6.2.0)
If you override the key in AdditionalConfiguration, it shouldn't matter which key is there in the LocalConfiguration.
Updated by Mathias Brodala about 10 years ago
Markus Klein wrote:
If you override the key in AdditionalConfiguration, it shouldn't matter which key is there in the LocalConfiguration.
Please see the SYS/encryptionKey example written above. That key is not present in the LocalConfiguration.php, only in the AdditionalConfiguration.php. This is intended to add the LocalConfiguration.php to a VCS without the danger of publishing this sensitive value.
As I read this again, a possible workaround for this very case could be to keep a non-empty value (e.g. "placeholder") in the LocalConfiguration.php. This way the SilentConfigurationUpgradeService is satisfied but the actual value is still only present in the AdditionalConfiguration.php. But again: this is only a workaround and a proper solution would be configuration per application context as in #61066.
Updated by Markus Klein about 10 years ago
- Status changed from New to Needs Feedback
Yes that's what I mean. It does not matter what is in LocalConfiguration if you override it in AdditionalConfiguration. Let the SilentConfigurationUpgradeService generate an arbitrary encryptionKey and you're good.
Still I don't understand why "config per application context" would solve this issue for you, since you would have the key in CVS again.
May I close this issue here?
Updated by Mathias Brodala about 10 years ago
Markus Klein wrote:
Yes that's what I mean. It does not matter what is in LocalConfiguration if you override it in AdditionalConfiguration. Let the SilentConfigurationUpgradeService generate an arbitrary encryptionKey and you're good.
I'd prefer the placeholder approach to avoid confusion due to two basically valid values.
Still I don't understand why "config per application context" would solve this issue for you, since you would have the key in CVS again.
That's the trick: none of the context-specific configuration would be added to VCS but simply exist on each corresponding system.
May I close this issue here?
Since the core of this issue is not fixable (and I understand very well why), yes. The workaround seems to do the trick, as long as the evaluating code does not perform any sanity checks.
Updated by Markus Klein about 10 years ago
- Status changed from Needs Feedback to Closed
Well, personally I also want the configuration of the production env in my repos, but that's a matter of taste.
Please continue and implement #61066.
Thanks