|
|
So, based on my findings on field encryption(see previous threads and
issue OFBIZ-5659), I decided that doing in-place encryption in
EntityExpr, against rhs, and in-place encryption on GenericEntity,
really wasn't the correct approach. The following code patterns break
when this is done:
==
condition = makeCondition("socialSecurityNumber", EntityOperator.EQUALS, "1234")
people = findByCondition("Person", condition)
// this second line fails, because the rhs above will get doubly encrypted.
people = findByCondition("Person", condition)
person = makeValue("Person", [partyId: "1234"])
person.firstName = "Adam"
person.socialSecurityNumber = "1234"
// this first store encrypts 1234 in-place
person.store()
person.lastName = "Heath"
// this second store encrypts the already encrypted value
person.store()
==
The first code pattern above is extremely troubling; the encryption
logic, as it stood, would *modify* the incoming condition. This is so
extremely bad. It could even pollute the entity caching system(!).
This fix will changes the encryptFields() and decryptFields() in
delegator to be no-ops(deprecates them as well), removes all
encryptConditionFields() from all conditions, and makes SqlJdbcUtil do
the encrypt/decrypt phases as it's interfacing with PreparedStatement
and ResultSet.
And, as a bonus, the code size is reduced.
ps: Note, that the findByCondition pattern does not work with current
trunk, due to the problems outlined in OFBIZ-5659. I have it working
locally, and with test cases as well.
|
Locked
