Project

General

Profile

Actions

Bug #57289

closed

Respect additional configuration file for silent configuration upgrade

Added by Mathias Brodala almost 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2014-03-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #53417: ConfigurationManager->getConfigurationValueByPath() ignores AdditionalConfiguration.phpRejected2013-11-07

Actions
Related to TYPO3 Core - Feature #61066: Configuration per application contextRejected2014-08-19

Actions
Actions #1

Updated by Markus Klein over 9 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.

Actions #2

Updated by Mathias Brodala over 9 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.

Actions #3

Updated by Markus Klein over 9 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?

Actions #4

Updated by Mathias Brodala over 9 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.

Actions #5

Updated by Markus Klein over 9 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

Actions

Also available in: Atom PDF