FinAccountHelper.getFinAccountFromCode() no longer returns financial account

Hello Everyone,

FinAccountHelper.getFinAccountFromCode() in trunk as well as in some of the
released version is no longer able to fetch the Financial Account ID. So
all features dependent on this method would no longer work (an example
being paying by gift card during order entry process).

Per my research, this stopped working method post some changes related to
how data is encrypted (two strings will not have similar encrypted string).

While I have figured out a workaround, which is not the ideal solution as
it takes away the advantage introduced by the new implementation and
switches back to 'old way' of storing encrypted data. I was wondering if
someone else has encountered this and has a better fix.

--
Vyom

[Jacques Le Roux]

This is quite unpleasant indeed, could you please open a Jira? I copy to Adam (doogie) because you mentioned it's related to data encryption change.
Since Adam did it, he might find an easy solution for that.

Thanks!

Jacques


Le 05/03/2014 19:05, Vyom Jain a écrit :

> Hello Everyone,
>
> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some of the
> released version is no longer able to fetch the Financial Account ID. So
> all features dependent on this method would no longer work (an example
> being paying by gift card during order entry process).
>
> Per my research, this stopped working method post some changes related to
> how data is encrypted (two strings will not have similar encrypted string).
>
> While I have figured out a workaround, which is not the ideal solution as
> it takes away the advantage introduced by the new implementation and
> switches back to 'old way' of storing encrypted data. I was wondering if
> someone else has encountered this and has a better fix.
>
> --
> Vyom
>

[Adam Heath-2]

I'm surprised there was no test case on this.

Do you have key-encrypting-key enabled in your new deployment?  It's not
possible to enable that on an existing install.  You'd have to do a
code-based copy, loading data from the old delegator, without kek, and
copying to a new delegator, with kek.

But yes, file a jira, give as much detail as possible.

I can definitely spend time this weekend looking at this.

On 03/06/2014 08:51 PM, Jacques Le Roux wrote:

> This is quite unpleasant indeed, could you please open a Jira? I copy to
> Adam (doogie) because you mentioned it's related to data encryption
> change. Since Adam did it, he might find an easy solution for that.
>
> Thanks!
>
> Jacques
>
>
> Le 05/03/2014 19:05, Vyom Jain a écrit :
>> Hello Everyone,
>>
>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some
>> of the
>> released version is no longer able to fetch the Financial Account ID. So
>> all features dependent on this method would no longer work (an example
>> being paying by gift card during order entry process).
>>
>> Per my research, this stopped working method post some changes related to
>> how data is encrypted (two strings will not have similar encrypted
>> string).
>>
>> While I have figured out a workaround, which is not the ideal solution as
>> it takes away the advantage introduced by the new implementation and
>> switches back to 'old way' of storing encrypted data. I was wondering if
>> someone else has encountered this and has a better fix.
>>
>> --
>> Vyom
>>

I had tried this on a fresh deployment with absolutely no changes anywhere
(had been using Derby database).

Furthermore, the ant target gen-kek references old jars and need fixing as
well.

--
Vyom


On 7 March 2014 08:52, Adam Heath <[hidden email]> wrote:

> I'm surprised there was no test case on this.
>
> Do you have key-encrypting-key enabled in your new deployment?  It's not
> possible to enable that on an existing install.  You'd have to do a
> code-based copy, loading data from the old delegator, without kek, and
> copying to a new delegator, with kek.
>
> But yes, file a jira, give as much detail as possible.
>
> I can definitely spend time this weekend looking at this.
>
>
> On 03/06/2014 08:51 PM, Jacques Le Roux wrote:
>
>> This is quite unpleasant indeed, could you please open a Jira? I copy to
>> Adam (doogie) because you mentioned it's related to data encryption
>> change. Since Adam did it, he might find an easy solution for that.
>>
>> Thanks!
>>
>> Jacques
>>
>>
>> Le 05/03/2014 19:05, Vyom Jain a écrit :
>>
>>> Hello Everyone,
>>>
>>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some
>>> of the
>>> released version is no longer able to fetch the Financial Account ID. So
>>> all features dependent on this method would no longer work (an example
>>> being paying by gift card during order entry process).
>>>
>>> Per my research, this stopped working method post some changes related to
>>> how data is encrypted (two strings will not have similar encrypted
>>> string).
>>>
>>> While I have figured out a workaround, which is not the ideal solution as
>>> it takes away the advantage introduced by the new implementation and
>>> switches back to 'old way' of storing encrypted data. I was wondering if
>>> someone else has encountered this and has a better fix.
>>>
>>> --
>>> Vyom
>>>
>>>
>

The related JIRA issue - https://issues.apache.org/jira/browse/OFBIZ-5565

--
Vyom


On 7 March 2014 12:00, Vyom Jain <[hidden email]> wrote:

> I had tried this on a fresh deployment with absolutely no changes anywhere
> (had been using Derby database).
>
> Furthermore, the ant target gen-kek references old jars and need fixing as
> well.
>
> --
> Vyom
>
>
> On 7 March 2014 08:52, Adam Heath <[hidden email]> wrote:
>
>> I'm surprised there was no test case on this.
>>
>> Do you have key-encrypting-key enabled in your new deployment?  It's not
>> possible to enable that on an existing install.  You'd have to do a
>> code-based copy, loading data from the old delegator, without kek, and
>> copying to a new delegator, with kek.
>>
>> But yes, file a jira, give as much detail as possible.
>>
>> I can definitely spend time this weekend looking at this.
>>
>>
>> On 03/06/2014 08:51 PM, Jacques Le Roux wrote:
>>
>>> This is quite unpleasant indeed, could you please open a Jira? I copy to
>>> Adam (doogie) because you mentioned it's related to data encryption
>>> change. Since Adam did it, he might find an easy solution for that.
>>>
>>> Thanks!
>>>
>>> Jacques
>>>
>>>
>>> Le 05/03/2014 19:05, Vyom Jain a écrit :
>>>
>>>> Hello Everyone,
>>>>
>>>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some
>>>> of the
>>>> released version is no longer able to fetch the Financial Account ID. So
>>>> all features dependent on this method would no longer work (an example
>>>> being paying by gift card during order entry process).
>>>>
>>>> Per my research, this stopped working method post some changes related
>>>> to
>>>> how data is encrypted (two strings will not have similar encrypted
>>>> string).
>>>>
>>>> While I have figured out a workaround, which is not the ideal solution
>>>> as
>>>> it takes away the advantage introduced by the new implementation and
>>>> switches back to 'old way' of storing encrypted data. I was wondering if
>>>> someone else has encountered this and has a better fix.
>>>>
>>>> --
>>>> Vyom
>>>>
>>>>
>>
>

[Adam Heath-2]

I don't see a JIRA issue filed on this yet.

On 03/06/2014 09:22 PM, Adam Heath wrote:

> I'm surprised there was no test case on this.
>
> Do you have key-encrypting-key enabled in your new deployment?  It's not
> possible to enable that on an existing install.  You'd have to do a
> code-based copy, loading data from the old delegator, without kek, and
> copying to a new delegator, with kek.
>
> But yes, file a jira, give as much detail as possible.
>
> I can definitely spend time this weekend looking at this.
>
> On 03/06/2014 08:51 PM, Jacques Le Roux wrote:
>> This is quite unpleasant indeed, could you please open a Jira? I copy to
>> Adam (doogie) because you mentioned it's related to data encryption
>> change. Since Adam did it, he might find an easy solution for that.
>>
>> Thanks!
>>
>> Jacques
>>
>>
>> Le 05/03/2014 19:05, Vyom Jain a écrit :
>>> Hello Everyone,
>>>
>>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some
>>> of the
>>> released version is no longer able to fetch the Financial Account ID. So
>>> all features dependent on this method would no longer work (an example
>>> being paying by gift card during order entry process).
>>>
>>> Per my research, this stopped working method post some changes
>>> related to
>>> how data is encrypted (two strings will not have similar encrypted
>>> string).
>>>
>>> While I have figured out a workaround, which is not the ideal
>>> solution as
>>> it takes away the advantage introduced by the new implementation and
>>> switches back to 'old way' of storing encrypted data. I was wondering if
>>> someone else has encountered this and has a better fix.
>>>
>>> --
>>> Vyom
>>>
>

[Jacopo Cappellato-4]

here it is:

https://issues.apache.org/jira/browse/OFBIZ-5565

Jacopo

On Mar 11, 2014, at 10:40 PM, Adam Heath <[hidden email]> wrote:

> I don't see a JIRA issue filed on this yet.
>
> On 03/06/2014 09:22 PM, Adam Heath wrote:
>> I'm surprised there was no test case on this.
>>
>> Do you have key-encrypting-key enabled in your new deployment?  It's not
>> possible to enable that on an existing install.  You'd have to do a
>> code-based copy, loading data from the old delegator, without kek, and
>> copying to a new delegator, with kek.
>>
>> But yes, file a jira, give as much detail as possible.
>>
>> I can definitely spend time this weekend looking at this.
>>
>> On 03/06/2014 08:51 PM, Jacques Le Roux wrote:
>>> This is quite unpleasant indeed, could you please open a Jira? I copy to
>>> Adam (doogie) because you mentioned it's related to data encryption
>>> change. Since Adam did it, he might find an easy solution for that.
>>>
>>> Thanks!
>>>
>>> Jacques
>>>
>>>
>>> Le 05/03/2014 19:05, Vyom Jain a écrit :
>>>> Hello Everyone,
>>>>
>>>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some
>>>> of the
>>>> released version is no longer able to fetch the Financial Account ID. So
>>>> all features dependent on this method would no longer work (an example
>>>> being paying by gift card during order entry process).
>>>>
>>>> Per my research, this stopped working method post some changes
>>>> related to
>>>> how data is encrypted (two strings will not have similar encrypted
>>>> string).
>>>>
>>>> While I have figured out a workaround, which is not the ideal
>>>> solution as
>>>> it takes away the advantage introduced by the new implementation and
>>>> switches back to 'old way' of storing encrypted data. I was wondering if
>>>> someone else has encountered this and has a better fix.
>>>>
>>>> --
>>>> Vyom
>>>>
>>
>