-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor ConfigGenerator to replace/set crypt key instead of append #11155
Conversation
Originally a call so "bin/magento setup:config:set --key='foobar'" did not replace the crypt key, but append it with a newline. This does not only "break" handling of values, encryptwed with the old key, but also don't allow use of new key, because the new key is composed of the old one, a newline and the new one.
@@ -50,15 +51,25 @@ class ConfigGenerator | |||
protected $deploymentConfig; | |||
|
|||
/** | |||
* @var ConfigDataFactory | |||
*/ | |||
protected $configDataFactory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be made private rather than protected to start with.
@@ -99,7 +109,7 @@ public function createCryptConfig(array $data) | |||
*/ | |||
public function createSessionConfig(array $data) | |||
{ | |||
$configData = new ConfigData(ConfigFilePool::APP_ENV); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work, good to see this being moved out to a factory.
@@ -70,15 +81,14 @@ public function createCryptConfig(array $data) | |||
{ | |||
$currentKey = $this->deploymentConfig->get(ConfigOptionsListConstants::CONFIG_PATH_CRYPT_KEY); | |||
|
|||
$configData = new ConfigData(ConfigFilePool::APP_ENV); | |||
// TODO: refactor configData to factory in constructor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest leaving the create as it is rather than moving it into the factory. You could always make a getConfigData
method that checks for $this->configData
being null and if so calls the factory create.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like https://github.com/magento/magento2/pull/11152/files#diff-dfb3ee5a7f863458afea75f5524cd2e5R233 might work in this case also.
public function __construct( | ||
Random $random, | ||
DeploymentConfig $deploymentConfig, | ||
ConfigDataFactory $configDataFactory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the optional dependency and I think we are good to go here.
Add CryptKeyGeneratorInterface and a default implementation "CryptKeyGenerator". Refactor ConfigGenerator to use CryptKeyGeneratorInterface
to make this code easier to understand, the chained ?? was refactored to 2 simple uses of '.. ?? ..' with some comments
Random class is now optional in constructor. If no class is given on construct, the objectmanager will be used to create an instance
Fixed Magento/Setup/Test/Unit/Module/ConfigGeneratorTest.php
I made the dependency optional. Also, I refactored the createCryptConfig method a little bit. (Introduced a new Interface on the way) |
Make it a little more simple
Put "ConfigOptionsListConstants::CONFIG_PATH_DB_CONNECTION_DEFAULT . '/'" into a variable to shorten some function calls
One test reported an undefined "offset 1" for data, that has no port. Simple solution: remove list() and just work with the array.
It has to stay there, so that no older code breaks
* @param string $fileKey | ||
* @return ConfigData | ||
*/ | ||
public function create(string $fileKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can update this to use PHP 7's return type declaration if you would like. http://php.net/manual/en/migration70.new-features.php#migration70.new-features.return-type-declarations
{ | ||
$this->random = $random; | ||
public function __construct( | ||
DeploymentConfig $deploymentConfig, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned we need to keep the random
parameter here but can mark the property as deprecated.
*/ | ||
private $random; | ||
|
||
public function __construct(Random $random = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a new class we do not need random
to be defaulted to null.
hey @dmanners I pushed the requested changes |
DeploymentConfig $deploymentConfig, | ||
ConfigDataFactory $configDataFactory = null, | ||
CryptKeyGeneratorInterface $cryptKeyGenerator = null | ||
) { | ||
$this->deploymentConfig = $deploymentConfig; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we still need to assign $this->random = $random
here in-case someone is using it in an extension to this class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aah, I thought I added id back.
I Think a shorter variable naming in tests would not only shorten the code, but also make it harder to understand.
- Remove scalar type and return hints - Inline mapHostData method & get rid of SupressWarning - Remove @api on new interface & implementation
|
||
/** | ||
* Factory for ConfigData | ||
* @api |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So since it is a patch release we cannot add these tag currently. @renttek Can you check all the classes and remove the @api
tag if you added it in.
{ | ||
/** | ||
* @var ConfigGenerator | ||
*/ | ||
private $configGeneratorObject; | ||
|
||
/** | ||
* @SuppressWarnings(PHPMD.LongVariable) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe such rule was removed from Magento 2 PHPMD configuration. If it's just Codacy complains, simply ignore this and don't add suppressing annotations. Please remove both @SuppressWarnings(PHPMD.LongVariable)
introduced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I will remove them. Can such Issues be hidden/ignored on Codacy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know, you can simply ignore it overall. There are some other dumb rules like "never use else
" :)
@SuppresssWarning should not be used
Hey @orlangur |
@orlangur are you ok with the changes made? If so I will continue to process this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for changes.
@dmanners yeah, please proceed, I didn't do a full review, just small note on phpmd suppression. Looks like "Changes requested" cannot be changed to neutral resolution (and "Approved" is not suitable if I didn't dig into details). |
yeah \o/ first code in core |
@renttek congrats on the first PR. I have a t-shirt and some stickers for you from the event. |
Hi @renttek could you please accept the invite on the GitHub to join magento team? |
Hi @okorshenko I just accepted |
Fix the command "setup:config:set --key=..." to replace existing crypt key instead of append it.
Description
Originally a call so "bin/magento setup:config:set --key='foobar'" did
not replace the crypt key, but append it with a newline.
This does not only "break" handling of values, encryptwed with the old
key, but also don't allow use of new key, because the new key is
composed of the old one, a newline and the new one.
Fixed Issues (if relevant)
Manual testing scenarios
Contribution checklist