date:20140623

Thank you Jacques,

Jacopo

On Jun 22, 2014, at 4:59 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 Hi,
 
 I'm happy to announce that eventually all the demos are back. The main page 
 is updated to reflect that: http://ofbiz.apache.org/
 
 You can also get to the trunk demo using
 http://demo-trunk-ofbiz.apache.org/ecommerce/control/main
 http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y
 
 Two things which are worth to be noted have changed.
 1) The sub domains are no longer demo-*.ofbiz.apache.org but 
 demo-*-ofbiz.apache.org
 2) Internally OFBiz no longer uses HTTPS in these demos. The security is done 
 by the infra team which is proxying all calls. The official ASF certificate 
 is used for all demos.
 
 Enjoy
 
 Jacques

Re: The official demos are back


Please report any unexpected error.

Because we are using *ONLY HTTP on the VM*, we might encounter surprising errors since this mode is not often used and might not have been tested for 
a while


Thanks

Jacques


Le 22/06/2014 16:59, Jacques Le Roux a écrit :

Hi,

I'm happy to announce that eventually all the demos are back. The main page is 
updated to reflect that: http://ofbiz.apache.org/

You can also get to the trunk demo using
http://demo-trunk-ofbiz.apache.org/ecommerce/control/main
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y

Two things which are worth to be noted have changed.
1) The sub domains are no longer demo-*.ofbiz.apache.org but 
demo-*-ofbiz.apache.org
2) Internally OFBiz no longer uses HTTPS in these demos. The security is done by the infra team which is proxying all calls. The official ASF 
certificate is used for all demos.


Enjoy

Jacques



--

[jira] [Created] (OFBIZ-5664) When using port.https.enabled=N some URLs are wrongly rendered

2014-06-23 Thread Jacques Le Roux (JIRA)

Jacques Le Roux created OFBIZ-5664:
--

 Summary: When using port.https.enabled=N some URLs are wrongly 
rendered
 Key: OFBIZ-5664
 URL: https://issues.apache.org/jira/browse/OFBIZ-5664
 Project: OFBiz
  Issue Type: Bug
Reporter: Jacques Le Roux


When setting 
  port.https.enabled=Y
in url.properties, as it's currently done on the OFBiz demo, some URLs are 
wrongly generated. 

For instance if you create an order in ecommerce and just after its creation 
try to get to the PDF you will have a link like

http://ofbiz-vm.apache.org:18080/ecommerce/control/order.pdf?orderId=WSCO10001

This will not work. It should be 
http://demo-stable-ofbiz.apache.org/ecommerce/control/order.pdf?orderId=WSCO10001

This is, I guess, because when creating an order in ecommerce we switch from 
HTTP to HTTPS...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-5664) When using port.https.enabled=N some URLs are wrongly rendered

2014-06-23 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040555#comment-14040555
 ] 

Jacques Le Roux commented on OFBIZ-5664:


Note though that 
https://ofbiz-vm.apache.org:18443/ecommerce/control/order.pdf?orderId=WSCO10001 
would work...

 When using port.https.enabled=N some URLs are wrongly rendered
 --

 Key: OFBIZ-5664
 URL: https://issues.apache.org/jira/browse/OFBIZ-5664
 Project: OFBiz
  Issue Type: Bug
Reporter: Jacques Le Roux

 When setting 
   port.https.enabled=Y
 in url.properties, as it's currently done on the OFBiz demo, some URLs are 
 wrongly generated. 
 For instance if you create an order in ecommerce and just after its creation 
 try to get to the PDF you will have a link like
 http://ofbiz-vm.apache.org:18080/ecommerce/control/order.pdf?orderId=WSCO10001
 This will not work. It should be 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/order.pdf?orderId=WSCO10001
 This is, I guess, because when creating an order in ecommerce we switch from 
 HTTP to HTTPS...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Freemarker

FYI:

I have been working with Daniel on this and he has helped a lot and I have now 
a working environment; as soon as the new version will be published I will 
update the OFBiz code accordingly.

Jacopo

On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 I did the tests but unfortunately they were still not successful.
 I have posted a comment to the ticket: let's see what Daniel has to say.
 
 Jacopo
 
 On Jun 17, 2014, at 10:13 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 Hi,
 
 We need to address this https://sourceforge.net/p/freemarker/bugs/363/?page=2
 
 Jacques
 PS: @Adam, I put you to be sure you will get a chance to read ;)

Re: Freemarker


Good news, thanks Jacopo!

Jacques

Le 23/06/2014 12:43, Jacopo Cappellato a écrit :

FYI:

I have been working with Daniel on this and he has helped a lot and I have now 
a working environment; as soon as the new version will be published I will 
update the OFBiz code accordingly.

Jacopo

On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


I did the tests but unfortunately they were still not successful.
I have posted a comment to the ticket: let's see what Daniel has to say.

Jacopo

On Jun 17, 2014, at 10:13 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


Hi,

We need to address this https://sourceforge.net/p/freemarker/bugs/363/?page=2

Jacques
PS: @Adam, I put you to be sure you will get a chance to read ;)





--

Re: Freemarker

2014-06-23 Thread Dékány Dániel

It would be good if testing the new version goes beyond that single test case, 
however. Alhough the reworked method overloading support has good test 
coverage, this was a quite complex change (it doesn#39;t just fix the null 
issue, but many others, like rounding issues). Not to mention that turing on 
the new overloaded method handling is inherently not 100% backward compatible 
(that#39;s why it#39;s by default off). Although its much less prone to fail 
with errors, there#39;s still a little chance that you need to addjust some 
OfBiz code. Thanks,  Daniel Dekany 
Jacques Le Roux jacques.le.r...@les7arts.com írta:
Good news, thanks Jacopo!

Jacques

Le 23/06/2014 12:43, Jacopo Cappellato a écrit :
 FYI:

 I have been working with Daniel on this and he has helped a lot and I have 
 now a working environment; as soon as the new version will be published I 
 will update the OFBiz code accordingly.

 Jacopo

 On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

 I did the tests but unfortunately they were still not successful.
 I have posted a comment to the ticket: let#39;s see what Daniel has to say.

 Jacopo

 On Jun 17, 2014, at 10:13 AM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:

 Hi,

 We need to address this 
 https://sourceforge.net/p/freemarker/bugs/363/?page=2

 Jacques
 PS: @Adam, I put you to be sure you will get a chance to read ;)



--

Re: Freemarker

I can actually commit the new jar and the updated code to run it in the trunk 
in order to simplify the tests from the community. WDYT?

Jacopo

On Jun 23, 2014, at 2:18 PM, Dékány Dániel ddek...@freemail.hu wrote:

 It would be good if testing the new version goes beyond that single test 
 case, however. Alhough the reworked method overloading support has good test 
 coverage, this was a quite complex change (it doesn#39;t just fix the null 
 issue, but many others, like rounding issues). Not to mention that turing on 
 the new overloaded method handling is inherently not 100% backward compatible 
 (that#39;s why it#39;s by default off). Although its much less prone to 
 fail with errors, there#39;s still a little chance that you need to addjust 
 some OfBiz code. Thanks,  Daniel Dekany 
 Jacques Le Roux jacques.le.r...@les7arts.com írta:
 Good news, thanks Jacopo!
 
 Jacques
 
 Le 23/06/2014 12:43, Jacopo Cappellato a écrit :
 FYI:
 
 I have been working with Daniel on this and he has helped a lot and I have 
 now a working environment; as soon as the new version will be published I 
 will update the OFBiz code accordingly.
 
 Jacopo
 
 On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 I did the tests but unfortunately they were still not successful.
 I have posted a comment to the ticket: let#39;s see what Daniel has to 
 say.
 
 Jacopo
 
 On Jun 17, 2014, at 10:13 AM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 Hi,
 
 We need to address this 
 https://sourceforge.net/p/freemarker/bugs/363/?page=2
 
 Jacques
 PS: @Adam, I put you to be sure you will get a chance to read ;)
 
 
 
 --

Re: Freemarker

2014-06-23 Thread Dékány Dániel

That#39;s fine as far as I#39;m concerned. (Update from GitHub and rebuild if 
that#39;s not a problem.) Thanks,  Daniel Dekany
Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com írta:
I can actually commit the new jar and the updated code to run it in the trunk 
in order to simplify the tests from the community. WDYT?

Jacopo

On Jun 23, 2014, at 2:18 PM, Dékány Dániel ddek...@freemail.hu wrote:

 It would be good if testing the new version goes beyond that single test 
 case, however. Alhough the reworked method overloading support has good test 
 coverage, this was a quite complex change (it doesn#39;t just fix the null 
 issue, but many others, like rounding issues). Not to mention that turing on 
 the new overloaded method handling is inherently not 100% backward 
 compatible (that#39;s why it#39;s by default off). Although its much less 
 prone to fail with errors, there#39;s still a little chance that you need 
 to addjust some OfBiz code. Thanks,  Daniel Dekany 
 Jacques Le Roux jacques.le.r...@les7arts.com írta:
 Good news, thanks Jacopo!
 
 Jacques
 
 Le 23/06/2014 12:43, Jacopo Cappellato a écrit :
 FYI:
 
 I have been working with Daniel on this and he has helped a lot and I have 
 now a working environment; as soon as the new version will be published I 
 will update the OFBiz code accordingly.
 
 Jacopo
 
 On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 I did the tests but unfortunately they were still not successful.
 I have posted a comment to the ticket: let#39;s see what Daniel has to 
 say.
 
 Jacopo
 
 On Jun 17, 2014, at 10:13 AM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 Hi,
 
 We need to address this 
 https://sourceforge.net/p/freemarker/bugs/363/?page=2
 
 Jacques
 PS: @Adam, I put you to be sure you will get a chance to read ;)
 
 
 
 --

[jira] [Created] (OFBIZ-5665) REL-12.4.3 ecommerce: 'add to cart' action clears cookies, disrupts session, shop unusable

2014-06-23 Thread ofbiz user (JIRA)

ofbiz user created OFBIZ-5665:
-

 Summary: REL-12.4.3 ecommerce: 'add to cart' action clears 
cookies, disrupts session, shop unusable
 Key: OFBIZ-5665
 URL: https://issues.apache.org/jira/browse/OFBIZ-5665
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Release Branch 12.04
Reporter: ofbiz user
 Fix For: Release Branch 12.04


In REL-12.4.3 

I add a product to the cart, which works fine; item and prices show 
up in minicart.

But ofbiz cookies are cleared in that very moment, so the session 
is effectively killed.

This happens similarily when I am an anonymous user or logged in as 
a DemoCustomer.

standard configuration with demo data and derby; client firefox

general.properties: currency = EUR GEO is in EU, VAT calculation works 

Does not occur when item cannot be added to cart because of error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Freemarker

sure, I will.

Thanks,

Jacopo

On Jun 23, 2014, at 4:42 PM, Dékány Dániel ddek...@freemail.hu wrote:

 That#39;s fine as far as I#39;m concerned. (Update from GitHub and rebuild 
 if that#39;s not a problem.) Thanks,  Daniel Dekany
 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com írta:
 I can actually commit the new jar and the updated code to run it in the 
 trunk in order to simplify the tests from the community. WDYT?
 
 Jacopo
 
 On Jun 23, 2014, at 2:18 PM, Dékány Dániel ddek...@freemail.hu wrote:
 
 It would be good if testing the new version goes beyond that single test 
 case, however. Alhough the reworked method overloading support has good 
 test coverage, this was a quite complex change (it doesn#39;t just fix the 
 null issue, but many others, like rounding issues). Not to mention that 
 turing on the new overloaded method handling is inherently not 100% 
 backward compatible (that#39;s why it#39;s by default off). Although its 
 much less prone to fail with errors, there#39;s still a little chance that 
 you need to addjust some OfBiz code. Thanks,  Daniel Dekany 
 Jacques Le Roux jacques.le.r...@les7arts.com írta:
 Good news, thanks Jacopo!
 
 Jacques
 
 Le 23/06/2014 12:43, Jacopo Cappellato a écrit :
 FYI:
 
 I have been working with Daniel on this and he has helped a lot and I 
 have now a working environment; as soon as the new version will be 
 published I will update the OFBiz code accordingly.
 
 Jacopo
 
 On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 I did the tests but unfortunately they were still not successful.
 I have posted a comment to the ticket: let#39;s see what Daniel has to 
 say.
 
 Jacopo
 
 On Jun 17, 2014, at 10:13 AM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 Hi,
 
 We need to address this 
 https://sourceforge.net/p/freemarker/bugs/363/?page=2
 
 Jacques
 PS: @Adam, I put you to be sure you will get a chance to read ;)
 
 
 
 --

Re: Freemarker

Thanks Jacopo for looking into this. I haven't had time to jump back in
to this old bug, I've been distracted on that other issue(keep finding
more problems).

On 06/23/2014 10:20 AM, Jacopo Cappellato wrote:

sure, I will.

Thanks,

Jacopo

On Jun 23, 2014, at 4:42 PM, Dékány Dániel ddek...@freemail.hu wrote:

That#39;s fine as far as I#39;m concerned. (Update from GitHub and rebuild if
that#39;s not a problem.) Thanks, Daniel Dekany
Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com írta:

I can actually commit the new jar and the updated code to run it in the trunk
in order to simplify the tests from the community. WDYT?

Jacopo

On Jun 23, 2014, at 2:18 PM, Dékány Dániel ddek...@freemail.hu wrote:

It would be good if testing the new version goes beyond that single test case, however. Alhough
the reworked method overloading support has good test coverage, this was a quite complex change
(it doesn#39;t just fix the null issue, but many others, like rounding issues). Not to
mention that turing on the new overloaded method handling is inherently not 100% backward
compatible (that#39;s why it#39;s by default off). Although its much less prone to
fail with errors, there#39;s still a little chance that you need to addjust some OfBiz
code. Thanks, Daniel Dekany
Jacques Le Roux jacques.le.r...@les7arts.com írta:

Good news, thanks Jacopo!

Jacques

Le 23/06/2014 12:43, Jacopo Cappellato a écrit :

FYI:

I have been working with Daniel on this and he has helped a lot and I have now
a working environment; as soon as the new version will be published I will
update the OFBiz code accordingly.

Jacopo

On Jun 18, 2014, at 11:11 AM, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com wrote:

I did the tests but unfortunately they were still not successful.
I have posted a comment to the ticket: let#39;s see what Daniel has to say.

Jacopo

On Jun 17, 2014, at 10:13 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

Hi,

We need to address this https://sourceforge.net/p/freemarker/bugs/363/?page=2

Jacques
PS: @Adam, I put you to be sure you will get a chance to read ;)

Re: The official demos are back

Do you mean 2 connections, one on 8080(as before), and one on 8444, in 
http mode, but with secure=true?


On 06/23/2014 04:06 AM, Jacques Le Roux wrote:

Please report any unexpected error.

Because we are using *ONLY HTTP on the VM*, we might encounter 
surprising errors since this mode is not often used and might not have 
been tested for a while


Thanks

Jacques


Le 22/06/2014 16:59, Jacques Le Roux a écrit :

Hi,

I'm happy to announce that eventually all the demos are back. The 
main page is updated to reflect that: http://ofbiz.apache.org/


You can also get to the trunk demo using
http://demo-trunk-ofbiz.apache.org/ecommerce/control/main
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y 



Two things which are worth to be noted have changed.
1) The sub domains are no longer demo-*.ofbiz.apache.org but 
demo-*-ofbiz.apache.org
2) Internally OFBiz no longer uses HTTPS in these demos. The security 
is done by the infra team which is proxying all calls. The official 
ASF certificate is used for all demos.


Enjoy

Jacques

Re: The official demos are back


I think it's explained at bottom of 
https://issues.apache.org/jira/browse/INFRA-7436

Jacques


Le 23/06/2014 18:11, Adam Heath a écrit :

Do you mean 2 connections, one on 8080(as before), and one on 8444, in http 
mode, but with secure=true?

On 06/23/2014 04:06 AM, Jacques Le Roux wrote:

Please report any unexpected error.

Because we are using *ONLY HTTP on the VM*, we might encounter surprising errors since this mode is not often used and might not have been tested 
for a while


Thanks

Jacques


Le 22/06/2014 16:59, Jacques Le Roux a écrit :

Hi,

I'm happy to announce that eventually all the demos are back. The main page is 
updated to reflect that: http://ofbiz.apache.org/

You can also get to the trunk demo using
http://demo-trunk-ofbiz.apache.org/ecommerce/control/main
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y

Two things which are worth to be noted have changed.
1) The sub domains are no longer demo-*.ofbiz.apache.org but 
demo-*-ofbiz.apache.org
2) Internally OFBiz no longer uses HTTPS in these demos. The security is done by the infra team which is proxying all calls. The official ASF 
certificate is used for all demos.


Enjoy

Jacques








--

Re: The official demos are back


BTW I already found https://issues.apache.org/jira/browse/OFBIZ-5664

Jacques

Le 23/06/2014 18:54, Jacques Le Roux a écrit :

I think it's explained at bottom of 
https://issues.apache.org/jira/browse/INFRA-7436

Jacques


Le 23/06/2014 18:11, Adam Heath a écrit :

Do you mean 2 connections, one on 8080(as before), and one on 8444, in http 
mode, but with secure=true?

On 06/23/2014 04:06 AM, Jacques Le Roux wrote:

Please report any unexpected error.

Because we are using *ONLY HTTP on the VM*, we might encounter surprising errors since this mode is not often used and might not have been tested 
for a while


Thanks

Jacques


Le 22/06/2014 16:59, Jacques Le Roux a écrit :

Hi,

I'm happy to announce that eventually all the demos are back. The main page is 
updated to reflect that: http://ofbiz.apache.org/

You can also get to the trunk demo using
http://demo-trunk-ofbiz.apache.org/ecommerce/control/main
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y

Two things which are worth to be noted have changed.
1) The sub domains are no longer demo-*.ofbiz.apache.org but 
demo-*-ofbiz.apache.org
2) Internally OFBiz no longer uses HTTPS in these demos. The security is done by the infra team which is proxying all calls. The official ASF 
certificate is used for all demos.


Enjoy

Jacques

Re: Freemarker

2014-06-23 Thread Prabhakar Balakrishna

Am feeling good to use the release.

Is there any chance(s) to hack the OfBiz based site/atleast OfBiz demo
site of the new release.

-- 


A Question for God every morning.
What is the main event today? What do you want me to focus on today?
God Speed...
Thanks  Regards
Prabhakar Balakrishna
+91-88977-49482

Re: Freemarker

2014-06-23 Thread Prabhakar Balakrishna

I would like to know David E Jones is still working for OFBiz project.

-- 


A Question for God every morning.
What is the main event today? What do you want me to focus on today?
God Speed...
Thanks  Regards
Prabhakar Balakrishna
+91-88977-49482

[jira] [Commented] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd

[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041518#comment-14041518
]

Adam Heath commented on OFBIZ-5659:
---

This should all be fixed now, in svn revisions: 1604967, 1604968, 1604971, and
1604972,

During the investigation, it was discovered that support for encrypted fields
in the EntityCondition classes was completely non-fuinctional. Much work had
to be done to get it into a functional state. However, now there are test
cases, so this kind of breakage should not happen going forward.

The other issues have not yet been resolved against this series of changes.

Person.socialSecurityNumber can't be used for findByAnd
---

Key: OFBIZ-5659
URL: https://issues.apache.org/jira/browse/OFBIZ-5659
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 12.04, Release Branch 13.07
Reporter: Adam Heath
Assignee: Adam Heath
Fix For: SVN trunk

In EntityCrypto, a random salt of bytes, with a random length between 5 and
16 characters, is added to each to-be-encrypted list of bytes. This entire
array is then encrypted, and stored.
Because the salt prefix is random each time, including when subsequent
findByAnd calls are used, the database has no chance to do an equality test,
so never finds the record.
This was done, so that the same exact value stored for different rows would
encrypt to a different value; this was thought to be better for security.
It's based on how one-way password hashes work.
My planned fix, is simple enough. Just change the salt length to 0. This
will allow newly stored values to be looked up(with = or !=, but not with
LIKE). Existing values already stored will be fixed by iterating over all of
them, then restoring in place.
However, what I would really like to see, is this encrypted+salt feature
configurable *per field*. That will take a bit more time.
ps: There is *no* test on lookups for Person.socialSecurityNumber; not even a
test for a lookup on an encrypted field. I'll obviously be adding that.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd

[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Heath updated OFBIZ-5659:
--

Fix Version/s: SVN trunk

Person.socialSecurityNumber can't be used for findByAnd
---

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [jira] [Updated] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd

The series of changes required to get this seemingly simple feature to
work were rather complex. I'm not certain if this should be targetted
to the previous branches; this feature has *not* worked since at least
2005, so it's not like there was a breakage of a working feature.

On 06/23/2014 07:30 PM, Adam Heath (JIRA) wrote:

[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Heath updated OFBIZ-5659:
--

Fix Version/s: SVN trunk

Person.socialSecurityNumber can't be used for findByAnd
---

In EntityCrypto, a random salt of bytes, with a random length between 5 and 16
characters, is added to each to-be-encrypted list of bytes. This entire array
is then encrypted, and stored.
Because the salt prefix is random each time, including when subsequent
findByAnd calls are used, the database has no chance to do an equality test, so
never finds the record.
This was done, so that the same exact value stored for different rows would
encrypt to a different value; this was thought to be better for security. It's
based on how one-way password hashes work.
My planned fix, is simple enough. Just change the salt length to 0. This will
allow newly stored values to be looked up(with = or !=, but not with LIKE).
Existing values already stored will be fixed by iterating over all of them,
then restoring in place.
However, what I would really like to see, is this encrypted+salt feature
configurable *per field*. That will take a bit more time.
ps: There is *no* test on lookups for Person.socialSecurityNumber; not even a
test for a lookup on an encrypted field. I'll obviously be adding that.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-5565) FinAccountHelper.getFinAccountFromCode() no longer returns financial account

[
https://issues.apache.org/jira/browse/OFBIZ-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041567#comment-14041567
]

Adam Heath commented on OFBIZ-5565:
---

Ok, yes, I see how this broke. My salted crypt feature *did* break this.
However, the code itself is doing things quite wrong.

It was encrypting the value *itself*, then passing it in as a map thru
findByAnd. Due to the entity conditions *not* encrypting their field values,
this worked before my key-encrypting-key change.

Now that the conditions properly support encrypted field value lookups, the
code in this function becomes radically simpler. Just pass the incoming code
directly into the entity engine.

FinAccountHelper.getFinAccountFromCode() no longer returns financial account

Key: OFBIZ-5565
URL: https://issues.apache.org/jira/browse/OFBIZ-5565
Project: OFBiz
Issue Type: Bug
Components: accounting, order
Affects Versions: SVN trunk, Release Branch 13.07
Environment: Primarily tested on Ubuntu, but affects all OS.
Reporter: Vyom Jain
Assignee: Adam Heath
Fix For: SVN trunk, Release Branch 13.07

Attachments: OFBIZ-5565.patch

FinAccountHelper.getFinAccountFromCode() in trunk as well as in some of the
released versions 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).
I had tried this on a fresh SVN trunk checkout with absolutely no changes
(had been using Derby database).
Furthermore, the ant target gen-kek references old jars and that needs fixing
as well.
Steps to test -
1. Create a new Financial account (gift certificate) for DemoCustomer -
https://demo-trunk.ofbiz.apache.org/accounting/control/FindFinAccount?ownerPartyId=DemoCustomer
and deposit some funds into it.
2. Create an order for DemoCustomer from the Order Manager application.
3. Use Quick Finalize Order, try paying by the gift card created in step #1.
Observations -
1. Returns an error This gift card does not exist
Related User ML post -
http://mail-archives.apache.org/mod_mbox/ofbiz-user/201403.mbox/%3CCAKuEJqZChmJaWF=rzn1z-vudnzbnsdulj4j6pxjtd5ijynu...@mail.gmail.com%3E
Thanks.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (OFBIZ-5565) FinAccountHelper.getFinAccountFromCode() no longer returns financial account

[
https://issues.apache.org/jira/browse/OFBIZ-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Heath updated OFBIZ-5565:
--

Fix Version/s: (was: Release Branch 13.07)

This fix for this is difficult to backport to 13.07; there are some complex
requirements on other commits.

I have asked the list of backporting is something that is desired.

FinAccountHelper.getFinAccountFromCode() no longer returns financial account

Attachments: OFBIZ-5565.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (OFBIZ-5565) FinAccountHelper.getFinAccountFromCode() no longer returns financial account

[
https://issues.apache.org/jira/browse/OFBIZ-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Heath resolved OFBIZ-5565.
---

Resolution: Fixed

FinAccountHelper.getFinAccountFromCode() no longer returns financial account

Attachments: OFBIZ-5565.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-3006) entity encrypt columns not using encryption salt value?

[
https://issues.apache.org/jira/browse/OFBIZ-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041578#comment-14041578
]

Adam Heath commented on OFBIZ-3006:
---

Jacques, SHA1 and MD5 are the same kind of technology; they are both one-way
hashes. Either could be used for password-type fields. Originally, it was
MD5. I added an ability to have different hashes(I stored the hash type in the
database), then added salt ability(as a prefix).

The examples given are for password-type fields. As that support has been
around for quite a while now, this issue can be closed.

Additionally, if you really are concerned about *encrypted* fields not having a
salt, then svn trunk now supports such a feature. In the entitymodel
definition, you can set encrypt=salt, and the value saved to the database
will have a salt pre-pended. Note, that if you do this, then you will not be
able to do direct lookups against that value.

entity encrypt columns not using encryption salt value?
---

Key: OFBIZ-3006
URL: https://issues.apache.org/jira/browse/OFBIZ-3006
Project: OFBiz
Issue Type: Sub-task
Components: framework
Affects Versions: SVN trunk
Reporter: chris snow
Assignee: Adam Heath

It looks as though no salt data is used when saving encrypted entity data
making the stored data susceptible to dictionary attacks.
If you look through the stored demo data, you can see all the demo accounts
passwords are the same:
{code}
UserLogin:
admin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
flexadmin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
...
{code}
As a comparison, if you create a two unix accounts, ofbiz1 and ofbiz2 and
set both passwords to ofbiz
{code}
ofbiz1:$6$3.mYZg9u$0E...:14524:0:9:7:::
ofbiz2:$6$MJhYeMqO$Jf...:14524:0:9:7:::
{code}
You can see that on unix, even though the passwords are the same, the
encrypted values are completely different.
For more information see:
[http://en.wikipedia.org/wiki/Salt_(cryptography)]

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (OFBIZ-3006) entity encrypt columns not using encryption salt value?


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Heath closed OFBIZ-3006.
-

   Resolution: Fixed
Fix Version/s: SVN trunk

 entity encrypt columns not using encryption salt value?
 ---

 Key: OFBIZ-3006
 URL: https://issues.apache.org/jira/browse/OFBIZ-3006
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: chris snow
Assignee: Adam Heath
 Fix For: SVN trunk


 It looks as though no salt data is used when saving encrypted entity data 
 making the stored data susceptible to dictionary attacks.
 If you look through the stored demo data, you can see all the demo accounts 
 passwords are the same:
 {code}
 UserLogin:
 admin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
 flexadmin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
 ...
 {code}
 As a comparison, if you create a two unix accounts, ofbiz1 and ofbiz2 and 
 set both passwords to ofbiz
 {code}
 ofbiz1:$6$3.mYZg9u$0E...:14524:0:9:7:::
 ofbiz2:$6$MJhYeMqO$Jf...:14524:0:9:7:::
 {code}
 You can see that on unix, even though the passwords are the same, the 
 encrypted values are completely different.
 For more information see:
 [http://en.wikipedia.org/wiki/Salt_(cryptography)]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-1232) Data filtering in entity views

[
https://issues.apache.org/jira/browse/OFBIZ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041585#comment-14041585
]

Adam Heath commented on OFBIZ-1232:
---

This set of changes might be much simpler now. I committed code a while back
to allow completely nestable views, to infinite depth. The bug was that the
nested view-link on each nested view was added to the outer WHERE clause,
instead of to the inner ON.

My long-running thoughts on this feature, is that you would not ever need to
have a separate syntax for date-filtering. No filter tag at all. Instead,
when you specify the condition in the model, you'd use a
data-filter-condition, at any place. Then, at runtime, the built up condition
would be resolved, and such data-filters would be extracted, and not sent to
the database. The delegator would then store the full, raw list to the cache,
but before returning, auto-run the extract set of filters.

This feature would interact with the freeze() method that already exists in the
condition objects. However, instead of running just a single EntityCondition,
a new class would be created, that contained the frozen condition as before,
and an optional filter.

As each nested level of condition objects return, it would need to check for
the optional filter, and if found, it might need to rewrite it, based on
various circumstances.

Then, the entity cache system would have to store both the raw list and the
filter, so yet another wrapping class would need to be created.

This is a little complex, because the view sql creation logic is underneath the
delegator; it wouldn't have access to the split condition/filter results.

Hopefully, others can understand what I've written here.

Data filtering in entity views
--

Key: OFBIZ-1232
URL: https://issues.apache.org/jira/browse/OFBIZ-1232
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Oscar Pablo
Assignee: Adam Heath
Priority: Minor
Fix For: SVN trunk

Attachments: filter_views.diff, filter_views.patch, filter_views.patch

OfBiz allows the creation of views based on the database model. But the data
selection is done only by join. It would be great to select the data also by
value. And, in some cases, it avoids workarounds and a cleaner code.
The proposal is to create a new tag inside view-entity tag from
entitymodel.xml with the following syntax:
filter entity-alias=table_alias field-name=field_name
operator=operator:equals, not-equals, like... value=value_to_select/
these tag could appear from 0 to N times. When N times, all filter criteria
must match with the data to select it.
I am attaching the xsd and the code I made...

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-5565) FinAccountHelper.getFinAccountFromCode() no longer returns financial account

2014-06-23 Thread Vyom Jain (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041593#comment-14041593
]

Vyom Jain commented on OFBIZ-5565:
--

Thanks Adam, you might as well want to commit the test case included in the
patch (in an existing class FinAccountTests.java). Also, as noted above, ant
target gen-kek needs fixing as well.

FinAccountHelper.getFinAccountFromCode() no longer returns financial account

Attachments: OFBIZ-5565.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Freemarker

2014-06-23 Thread Anil K Patel

Prabhakar
This is odd question. 

Is there some thing very specific that you need?

Thanks and Regards
Anil Patel
COO
Hotwax Media Inc
http://www.hotwaxmedia.com/
ApacheCon US 2014 Silver Sponsor
http://na.apachecon.com/sponsor/our-sponsors
Sent from my iPad

 On Jun 23, 2014, at 2:40 PM, Prabhakar Balakrishna 
 prabhakar.balakris...@gmail.com wrote:
 
 I would like to know David E Jones is still working for OFBiz project.
 
 -- 
 
 
 A Question for God every morning.
 What is the main event today? What do you want me to focus on today?
 God Speed...
 Thanks  Regards
 Prabhakar Balakrishna
 +91-88977-49482

Re: [jira] [Updated] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd

2014-06-23 Thread Adrian Crum

In the past, the dev community has supported backporting changes like
this to the most recent release branch. It could be backported further,
but the farther you go back, the less compatible the code is - so merges
are more difficult.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/23/2014 5:32 PM, Adam Heath wrote:

On 06/23/2014 07:30 PM, Adam Heath (JIRA) wrote:

[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Heath updated OFBIZ-5659:
--

Fix Version/s: SVN trunk

Person.socialSecurityNumber can't be used for findByAnd
---

Key: OFBIZ-5659
URL: https://issues.apache.org/jira/browse/OFBIZ-5659
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 12.04, Release Branch
13.07
Reporter: Adam Heath
Assignee: Adam Heath
Fix For: SVN trunk

In EntityCrypto, a random salt of bytes, with a random length between
5 and 16 characters, is added to each to-be-encrypted list of bytes.
This entire array is then encrypted, and stored.
Because the salt prefix is random each time, including when
subsequent findByAnd calls are used, the database has no chance to do
an equality test, so never finds the record.
This was done, so that the same exact value stored for different rows
would encrypt to a different value; this was thought to be better for
security. It's based on how one-way password hashes work.
My planned fix, is simple enough. Just change the salt length to 0.
This will allow newly stored values to be looked up(with = or !=, but
not with LIKE). Existing values already stored will be fixed by
iterating over all of them, then restoring in place.
However, what I would really like to see, is this encrypted+salt
feature configurable *per field*. That will take a bit more time.
ps: There is *no* test on lookups for Person.socialSecurityNumber;
not even a test for a lookup on an encrypted field. I'll obviously
be adding that.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: svn commit: r1604975 - in /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition: EntityConditionList.java EntityConditionListBase.java EntityExpr.java

2014-06-23 Thread Adrian Crum


Adam,

These changes look good. Thank you for working on this!

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/23/2014 5:24 PM, doo...@apache.org wrote:

Author: doogie
Date: Tue Jun 24 00:24:08 2014
New Revision: 1604975

URL: http://svn.apache.org/r1604975
Log:
Condition objects are now immutable.  This removed more uses of
javolution classes, namely, all the factory support code is now gone.

Modified:
 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionList.java
 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionListBase.java
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityExpr.java

Modified: 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionList.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionList.java?rev=1604975r1=1604974r2=1604975view=diff
==
--- 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionList.java
 (original)
+++ 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionList.java
 Tue Jun 24 00:24:08 2014
@@ -31,11 +31,6 @@ public class EntityConditionListT exten
  super(conditionList, operator);
  }

-public void init(ListT conditionList, EntityJoinOperator operator) {
-this.conditionList = conditionList;
-this.operator = operator;
-}
-
  @Override
  public int getConditionListSize() {
  return super.getConditionListSize();

Modified: 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionListBase.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionListBase.java?rev=1604975r1=1604974r2=1604975view=diff
==
--- 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionListBase.java
 (original)
+++ 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityConditionListBase.java
 Tue Jun 24 00:24:08 2014
@@ -38,8 +38,8 @@ import org.ofbiz.entity.model.ModelEntit
  public abstract class EntityConditionListBaseT extends EntityCondition 
extends EntityCondition {
  public static final String module = 
EntityConditionListBase.class.getName();

-protected ListT conditionList = null;
-protected EntityJoinOperator operator = null;
+protected final ListT conditionList;
+protected final EntityJoinOperator operator;

  protected EntityConditionListBase(ListT conditionList, 
EntityJoinOperator operator) {
  this.conditionList = conditionList;

Modified: 
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityExpr.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityExpr.java?rev=1604975r1=1604974r2=1604975view=diff
==
--- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityExpr.java 
(original)
+++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/condition/EntityExpr.java 
Tue Jun 24 00:24:08 2014
@@ -41,12 +41,12 @@ import org.ofbiz.entity.model.ModelField
   *
   */
  @SuppressWarnings(serial)
-public class EntityExpr extends EntityCondition {
+public final class EntityExpr extends EntityCondition {
  public static final String module = EntityExpr.class.getName();

-private Object lhs = null;
-private EntityOperatorObject, Object, ? operator = null;
-private Object rhs = null;
+private final Object lhs;
+private final EntityOperatorObject, Object, ? operator;
+private final Object rhs;

  public L,R,LL,RR EntityExpr(L lhs, EntityComparisonOperatorLL,RR 
operator, R rhs) {
  if (lhs == null) {

Re: Freemarker

2014-06-23 Thread Prabhakar Balakrishna

Dear Anil,
Am eagerly waiting to answer for the technical question Posted by me.

Every one please ignore my last question about David.I sent it to wrong address.

-- 


A Question for God every morning.
What is the main event today? What do you want me to focus on today?
God Speed...
Thanks  Regards
Prabhakar Balakrishna
+91-88977-49482

Re: [jira] [Updated] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd