Skip to content
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

Merged
merged 29 commits into from
Oct 11, 2017
Merged

Refactor ConfigGenerator to replace/set crypt key instead of append #11155

merged 29 commits into from
Oct 11, 2017

Conversation

renttek
Copy link

@renttek renttek commented Sep 30, 2017

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)

  1. setup:config:set --key append instead of replace #11089: setup:config:set --key append instead of replace

Manual testing scenarios

  1. Install Magento & get sure, that there is a crypt key defined in env.php
  2. Call "bin/magento setup:config:set --key="
  3. New crypt key in env.php should be your new key, instead of "\n"

Contribution checklist

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

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;
Copy link
Contributor

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);
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

public function __construct(
Random $random,
DeploymentConfig $deploymentConfig,
ConfigDataFactory $configDataFactory
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@dmanners dmanners left a 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
@renttek
Copy link
Author

renttek commented Sep 30, 2017

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)
Copy link
Contributor

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,
Copy link
Contributor

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)
Copy link
Contributor

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.

@renttek
Copy link
Author

renttek commented Sep 30, 2017

hey @dmanners I pushed the requested changes

DeploymentConfig $deploymentConfig,
ConfigDataFactory $configDataFactory = null,
CryptKeyGeneratorInterface $cryptKeyGenerator = null
) {
$this->deploymentConfig = $deploymentConfig;
Copy link
Contributor

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.

Copy link
Author

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.
@okorshenko okorshenko added this to the October 2017 milestone Oct 1, 2017
- Remove scalar type and return hints
- Inline mapHostData method & get rid of SupressWarning
- Remove @api on new interface & implementation

/**
* Factory for ConfigData
* @api
Copy link
Contributor

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)
Copy link
Contributor

@orlangur orlangur Oct 2, 2017

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.

Copy link
Author

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?

Copy link
Contributor

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
@renttek
Copy link
Author

renttek commented Oct 4, 2017

Hey @orlangur
I removed the SupressWarnings now

@dmanners
Copy link
Contributor

dmanners commented Oct 6, 2017

@orlangur are you ok with the changes made? If so I will continue to process this.

Copy link
Contributor

@orlangur orlangur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for changes.

@orlangur
Copy link
Contributor

orlangur commented Oct 6, 2017

@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).

magento-team pushed a commit that referenced this pull request Oct 11, 2017
@magento-team magento-team merged commit e8fe7ed into magento:2.2-develop Oct 11, 2017
@renttek renttek deleted the issue/11089 branch October 11, 2017 08:30
@renttek
Copy link
Author

renttek commented Oct 11, 2017

yeah \o/ first code in core

@dmanners
Copy link
Contributor

@renttek congrats on the first PR. I have a t-shirt and some stickers for you from the event.

@okorshenko
Copy link
Contributor

Hi @renttek could you please accept the invite on the GitHub to join magento team?

@renttek
Copy link
Author

renttek commented Oct 27, 2017

Hi @okorshenko I just accepted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants