Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I ran into an issue where I have this module being enabled by features while having some settings in the settings.php file.
At the end in my settings.php:
$conf['aes_cipher'] = 'rijndael-256';
$conf['aes_key_storage_method'] = 'File';
$conf['aes_key_path'] = '/some/secret/location/aes.key';
A dependency to this module is set in a feature which means that when I revert the feature, this module is enabled. I do this using drush: drush fra -y
The problem is that the settings.php variables are loaded, this module is installed and in its install hook there are some variables set. Within the same request, these new settings will be used. As you can see, the defaults are different from my settings.php. Which means that the other module (dbee in this case) asks aes to encrypt some data with the wrong cipher, storage method and storage key.
I've added some if-statement in the hook_install so that it only sets the variables if they do not exist yet. (Patch attached in first comment)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | setting_variables-2394761-1.patch | 653 bytes | SpadXIII |
Comments
Comment #1
SpadXIII CreditAttribution: SpadXIII commentedComment #2
dpovshed CreditAttribution: dpovshed commentedSpadXIII, thanks for your report and patch.
Patch looks technically OK but I never seen that module doing such kind of paranoid checks on install. As we see from code of variable_set() the variable replacements work only till the end of current execution, on all later requests you will have your data from settings.php .
Please check my propositions about module usage below. Maybe one of those will work and then we do not need code bloating.
1) It is possible that you have a different result just because you saved only part of your config in settings.php
Since you using 256 bits I assume you're with mcrypt. For mcrypt the initialization vector is also important. Could you please test - will the system work if you add also your other variables to the $config array:
$conf['aes_encryption_iv'] = ...;
$conf['aes_implementation'] = ...;
2) If this does not work - could you please check how the system work if you enable just AES module before reverting feature .
Please let me know what do you think.
Comment #4
dpovshed CreditAttribution: dpovshed commentedUpdate:
could you please test the current 7.x-1-x for your case?
I made some simplification and more careful works with variables, so they should not become overwritten at all.
As long as someone supplies in settings.php strings like
$conf['aes_cipher'] = 'rijndael-128';
$conf['aes_encryption_iv'] = "80XS7aSxx3uziCa7tvFurA==";
$conf['aes_key'] = "scLCLtURz3Lodq3Esmv6BglflnMbyTKQ";
$conf['aes_implementation'] = "mcrypt";
the module works persistent and give the same result for all possible reinstall. I assume in the feature anyone can save variables he/she needs.
Thanks in advance!
Comment #5
SpadXIII CreditAttribution: SpadXIII commentedI did check the commit, and it looks much better like this! (Un)fortunately, I won't be able to check if this works with my current setup until I get back from vacation :)
But I think it will work fine. Perhaps the only thing I need to do, is also set the other default variables in the settings.php, but that might also be fixed by the feature revert (as long as all variables are in there as well).
Much cleaner solution that my quick-fix "hack" ! :)
Comment #6
dpovshed CreditAttribution: dpovshed commentedThanks SpadXIII for rapid response!
I also think code is more clear now, and this is also your merit as a topicstarter. I close the ticket but do not hesitate to reopen if needed after real life tests.
Have a great vacation! :) Later in case you find something else and have time - you're welcome to proposed more patches here!