-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Payment config settings not decrypted when used? #2984
Comments
I'm experiencing this as well. The value decrypts fine on the config settings page somehow, but not if I call e: It's not to do with 2.0.1. I can reproduce it on a PHP 7 environment running 2.0.1, but not on a 5.6 environment running 2.0.1. May or may not be PHP. |
created internal ticket MAGETWO-48387 |
If I understand correctly, yes, there is some issue with PHP 7 and encrypted configuration. But in this particular case, I believe the value that's loaded from config is supposed to by encrypted. After it's loaded, using something like the method When I do something like your example in php 5.6, I get encrypted text, but when I decrypt it, I get the plain text. The reason it shows up as plaintext on the configuration page is that the backend model, which is responsible for augmenting the save/load behaviors of config fields, decrypts it in that particular situation (but not in all cases where the config is loaded). Does that sound right? |
@dsikkema I don't think that's entirely correct. Normally the backend model runs seamlessly somewhere in the process, such that getConfigData from a payment model returns the unencrypted value in and of itself. It has always worked in this fashion for me, on 1.x and 2.x, except for on one environment running PHP7 as noted earlier. I'm not sure the exact nature of it, but clearly there's some discrepancy at play. |
Possibly related to issue reported on #3054 as well. |
We have made some changes which should resolve this for now, can you guys confirm it works as expected on PHP7? |
@dsikkema I can't as I'm using your composer release 2.0.2 at the moment. Could you point out the commit and I could try that however? |
@craigcarnell it's probably this one: 32ca5c9 |
I applied the fix manually; can confirm it fixes the problem for me. |
This solved my issue mentioned in #2878 |
As of Magento 2.0.4, this fix still hasn't been included. In the mean time, if you're running on PHP 7, you'll need to patch the Data.php manually. Here's the patch: 32ca5c9 |
This really needs fixing ASAP in a RELEASE, not just a patch. It affects all the shipping carriers (USPS, UPS, FedEx, DHL) that have encrypted fields, we have tested with UPS XML standalone to confirm issue. Causing major support issues, especially as PHP 7.x is now the recommended version to run Magento 2 on. Will also affect SAAS apps or any app that has encrypted password data being stored in config db table. |
Hello @craigcarnell, this issue has been fixed in the 2.0.7 patch release and I'm closing it. Thanks for reporting the issue! If you have additional questions or proposals you are welcome to create another one. |
I can see the patch has been applied in 2.1.0 but I am still seeing backend data that is not decrypted. Example;
When echo out this; When like this; Its decrypted and fine. Any Answers? |
Maybe this can help someone: I found that putting a Example:
With this, there is no need to call decryption yourself, the |
In my system.xml:
In my payment class which extends \Magento\Payment\Model\Method\Cc
$this->secret is still encrypted? it should be a plain text value
I'm using PHP 7.0.2
Inchoo/magento2-Inchoo_Stripe#6
The text was updated successfully, but these errors were encountered: