Only passwords are one-way encrypted, ie for comparison only purposes. Credit card numbers and other such fields must be decrypted otherwise they are of no value as the user would have to enter their credit card number each time, and the system could not do things such as automatically retrying card transactions.

-David


On May 30, 2008, at 11:45 AM, BJ Freeman wrote:

I may be off on this, but my understanding is you can not decode
encrypted fields. you have to encrypt the new data then compare the
encryption data against each other.

Ritz123 sent the following on 5/30/2008 9:29 AM:
Thanks BJ for the pointer. I guess from next time onwards, I will search the
dev list too.

But seems like there is a bug or atleast the functionality is not fully coded. When you use tables with encrypted fields in view entity - the fields are NOT decoded. They are decoded only if you do a findBy on that entity
directly or atleast that is what I am seeing happening at runtime and
looking at the code.

May be an Ofbiz commiter can confirm.


BJ Freeman wrote:
did a search through google
ofbiz credit card entity encrypt
here is a link
http://lists.ofbiz.org/pipermail/dev/2004-September/006391.html


Ritz123 sent the following on 5/29/2008 5:43 PM:
Hi,

Does createCreditCard service store Credit Card Number in the CREDIT_CARD table as some kind of encoded or garbled text or stores it in clear?

I see the values encoded but looked at the service code and it doesnt
seem
like it is encoded.

Thanks





Reply via email to