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

pkp/pkp-lib#9895 app key and encryption service provider attached to container #9918

Merged
merged 10 commits into from
Jul 1, 2024

Conversation

touhidurabir
Copy link
Member

for #9895

@touhidurabir touhidurabir marked this pull request as ready for review May 3, 2024 13:40
Comment on lines 34 to 36
if (!PKPAppKey::hasKey()) {
return;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is to allow the application to boot and run if app_key not set and we don't want to make it a must requirement for app to run . We can remove it if we decide to it make a must .

Copy link
Member

Choose a reason for hiding this comment

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

Because we're adding the app key automatically both on install and upgrade, I see no downsides to making the app key a requirement right now. It'll become necessary later as we adopt more of Laravel, so we may as well add the requirement now, since it's low burden to the admin. It'll keep our code simpler.

Comment on lines 1028 to 1031
if (!PKPAppKey::hasKeyVariable()) {
error_log("No key variable named `app_key` defined in the `general` section of config file. Please update the config file's general section and add line `app_key = `");
return true;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

If app_key variable not defined, we are not halting the process as not making the app key a must but if we decide to make it a must, we can set error and return false to halt the process .

Comment on lines 1033 to 1040
try {
PKPAppKey::writeToConfig(PKPAppKey::generate());
} catch (Throwable $exception) {
error_log($exception->getMessage());
} finally {
return true;
}
}
Copy link
Member Author

Choose a reason for hiding this comment

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

If app_key writing to config file we are not halting the process as not making the app key a must but if we decide to make it a must, we can set error and return false to halt the process .

Comment on lines 217 to 227
public function checkForAppKey(): void
{
// if the app key variable `app_key` set in the config, nothing to do
if (PKPAppKey::hasKeyVariable()) {
return;
}

printf("\n\e[;43mWARNING: It is noticed that there is not `app_key` variable defined in the `general` section of the config file which is necessary to cookie and other encryption purpose.\nWe suggest add the following line in the `general` section of config file.\e[0m\n\n");

printf("\e[;44mapp_key = \e[0m\n");
}
Copy link
Member Author

Choose a reason for hiding this comment

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

on upgrade check if

  1. app_key variable not defined in the config file, just returning but we can add another warning here .
  2. if app key not set, showing a warning .

if we decided to make the app key a must, we can turn it into error/exception .

Copy link
Member

@asmecher asmecher left a comment

Choose a reason for hiding this comment

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

I've suggested a change in the OJS part of this that'll affect this PR too; otherwise looks good!

Copy link
Member

@asmecher asmecher left a comment

Choose a reason for hiding this comment

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

Some suggestions for change! The biggest shift from the last review is that I think we should pick a side on adding the app key vs. keeping it optional. We're already adding it on upgrade and new install, so I think we should make it mandatory and reduce the redundant checks and messages.

@@ -75,6 +76,7 @@ public function execute()
public function check()
{
$this->checkVersion(VersionCheck::getLatestVersion());
$this->checkForAppKey();
Copy link
Member

Choose a reason for hiding this comment

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

If someone runs php tools/upgrade.php check before running the upgrade process (it's a normal practice), it'll seem to them that they need to manually generate and add the app key, when the upgrade process (https://github.com/pkp/pkp-lib/pull/9918/files#diff-8ae64e2e6552e29dc508801b292812f26856a2d5e80147614e8b39d48e29d906) should take care of it automatically during upgrade. If we're going to add it during upgrade and installation, I think we should trust that process (and make it robust) rather than adding the extra checks here.

*
* @trait CommandInterface
*
* @ingroup tools
Copy link
Member

Choose a reason for hiding this comment

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

Now that we're using namespaces, we shouldn't need @ingroup / @group anymore -- and as we're moving from Doxygen to phpDocumentor, where @ingroup / @group` aren't supported, we'll need to remove them anyhow. (Here and elsewhere)

/**
* @file classes/core/PKPAppKey.php
*
* Copyright (c) 2014-2024 Simon Fraser University
Copy link
Member

Choose a reason for hiding this comment

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

For new code, should just be (c) 2024 (here and elsewhere).

/**
* Get the list of supported ciphers
*/
public static function getSupportedCiphers(): array
Copy link
Member

Choose a reason for hiding this comment

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

I don't think the getter function adds value; in general I'd like to decrease our use of getters/setters (and eventually property hooks will remove more justification for these). I don't have a strong opinion about static variables vs. constants, but we do have an existing pattern for public const MY_CONST_NAME = abc in classes, and the UPPER_SNAKE_CASE convention does make the invariability clear.

*/
public static function hasKey(): bool
{
return !empty(Config::getVar('general', 'app_key', ''));
Copy link
Member

Choose a reason for hiding this comment

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

You can leave the 3rd parameter blank if you don't want to specify a default; also below

Copy link
Member

Choose a reason for hiding this comment

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

(minor, but still needs attention)

Comment on lines 34 to 36
if (!PKPAppKey::hasKey()) {
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

Because we're adding the app key automatically both on install and upgrade, I see no downsides to making the app key a requirement right now. It'll become necessary later as we adopt more of Laravel, so we may as well add the requirement now, since it's low burden to the admin. It'll keep our code simpler.


// will set an error if app key variable not set
// but will not halt the process
if (!PKPAppKey::hasKeyVariable()) {
Copy link
Member

Choose a reason for hiding this comment

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

I think this should add the variable if it's not present; there's no benefit to making the admin go through it manually.

*/
public function down(): void
{
throw new DowngradeNotSupportedException();
Copy link
Member

Choose a reason for hiding this comment

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

I suggest we leave the down() function empty rather than throwing an exception. There's no harm in leaving the variable in the config file, and if the upgrade is run again, it will preserve the existing value.

}

/**
* Reverse the downgrades
Copy link
Member

Choose a reason for hiding this comment

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

Reverses the migration


if (!static::hasKeyVariable()) {
// Error if the config key `app_key` not defined under `general` section
throw new Exception('Config variable named `app_key` not defined in the `general` section');
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

I Think we can keep this one as these are 2 different method (one to set/write the key variable and one to set/write the key itself) which can work independent of each other .

@touhidurabir touhidurabir force-pushed the i9895_main branch 2 times, most recently from 3cbf7f3 to af71ccd Compare June 13, 2024 11:43
@touhidurabir
Copy link
Member Author

@asmecher all tests are passing . Ready for a final look and if all ok, good to merge .

@@ -3,30 +3,23 @@
/**
* @file classes/config/ConfigParser.php
*
* Copyright (c) 2014-2021 Simon Fraser University
* Copyright (c) 2000-2021 John Willinsky
* Copyright (c) 2024 Simon Fraser University
Copy link
Member

Choose a reason for hiding this comment

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

Not a big deal, but don't remove old dates when they're present -- just update the latest date if it's not current.

*
* @throws \Exception
*/
public static function writeAppKeyVaribaleToConfig(): bool
Copy link
Member

Choose a reason for hiding this comment

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

Varibale is a typo: should be Variable. (Here and elsewhere.)

@touhidurabir touhidurabir merged commit 203067f into pkp:main Jul 1, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants