Re: Shipping data duplicated

2018-10-08 Thread Rishi Solanki 
Thanks Jacques for your reply and Jira ticket. I'll take care of it asap.

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Mon, Oct 8, 2018 at 2:49 PM jler...@apache.org 
wrote:

> Hi Rishi,
>
> Inline...
>
>
> Le 22/09/2018 à 12:34, Rishi Solanki a écrit :
> > Jacques,
> > Thanks for more insights.
> > IMO, we should rename the files as you suggested and also add some
> > description in the file so that we won't confuse by this in future. And
> > also we should keep the duplicate data as well, because when ofbizsetup
> app
> > set the data for store I assume we don't load the demo data.
> > About the ofbizsetup app uses, right now I could not think of it. But
> will
> > get back on it soon with details and get the inputs from community. For
> now
> > my understanding is to rename the setup files and let duplicate data
> exists
> > in the setup files.
> > Let me know if we can proceed with the above plan then will rename the
> > files and do the needful changes in the setup code.
> Agreed, I created OFBIZ-10598 for that
>
> > On ofbizsetup app we
> > will discuss once I come with more details.
> Yes no hurry, I think it needs a bit more review, love and
> documentation/information
> Maybe starting by completing
> https://cwiki.apache.org/confluence/display/OFBENDUSER/How+to+Install+OFBiz+without+the+Demo+Data
> ?
>
> Jacques
>
> >
> > Thanks!
> >
> > --
> > Rishi Solanki
> > Sr Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: +91-9893287847
> > http://www.hotwaxsystems.com
> > www.hotwax.co
> >
> >
> > On Sat, Sep 22, 2018 at 2:10 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Hi Rishi,
> >>
> >> Thanks for your feedback.
> >>
> >> Looking closely at history, ShippingData.xml was put in 9 years ago with
> >> http://svn.apache.org/viewvc?view=revision&revision=816083, so for the
> >> ofbizsetup app, which is a bit weirdo in OFBiz.
> >>
> >> Then was modified with OFBIZ-5890 and OFBIZ-7673
> >>
> >> Rest inline...
> >>
> >>
> >> Le 22/09/2018 à 09:27, Rishi Solanki a écrit :
> >>> Hi Jacques,
> >>> I dig into it today and found that the data exists in the
> >>> "applications/datamodel/data/demo/OrderDemoData.xml" was moved from
> >>> "applications/order/data/DemoShipping.xml"
> >>> Also the data claimed as duplicate in
> >>> "applications/commonext/data/ShippingData.xml" is similar but not exact
> >>> matches with OrderDemoData.xml.
> >> Yes, I was only speaking about "Shipping data", ie:
> >> ShipmentMethodType
> >> CarrierShipmentMethod
> >> QuantityBreak
> >> ShipmentBoxType
> >>
> >> Those are real duplicate
> >>> The ShippingData.xml  file has no entry in
> >>> any ofbiz-component.xml.
> >> Indeed, they are only used by the setup app. In SetupEvents.xml there is
> >>
> >>  
> >>   >>
> value="${sys:getProperty('ofbiz.home')}/applications/commonext/data/ShippingData.xml"/>
> >>
> >> Reading that, now I think we should not only keep the "Shipping data" in
> >> ShippingData.xml but also the file. I would rather rename this file and
> >> other ofbizsetup related files (at least data files) with a Setup prefix
> >> to clearly signal they are  part of this app.
> >> But I also wonder if the ofbizsetup app is still alive, maintained and
> >> used by users. Last time I tried I crossed issues (not biggie IIRW). I
> >> found
> >> this https://issues.apache.org/jira/issues/?filter=12344840
> >>
> >> What do you think?
> >>
> >> Jacques
> >>> So here we can decide weather we should keep that data in
> >> ShippingData.xml
> >>> (if someone introduce the file intentionally) or we can remove it from
> >>> trunk. In case no objection I would like to remove it as most data is
> >>> duplicate.
> >>>
> >>> --
> >>> Rishi Solanki
> >>> Sr Manager, Enterprise Software Development
> >>> HotWax Systems Pvt. Ltd.
> >>> Direct: +91-9893287847
> >>> http://www.hotwaxsystems.com
> >>> www.hotwax.co
> >>>
> >>>
> >>> On Sat, Aug 18, 2018 at 1:17 AM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
>  Thanks Rishi!
> 
>  Jacques
> 
> 
>  Le 17/08/2018 à 15:19, Rishi Solanki a écrit :
> > This should be part of effort when we were moving all the seed, ext,
> >> demo
> > data to datamodel component. I see there is no entry to load the
> > ShippingData.xml.
> > I will check this in next week and fix the duplicate data exists in
> the
> > system, or share the the reason of having this.
> >
> > Probably, data moved but not removed from commonext. But I'll confirm
> >> and
> > get back.
> >
> > Thanks!
> >
> >
> >
> > Rishi Solanki
> > Sr Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: +91-9893287847
> > http://www.hotwaxsystems.com
> > www.hotwax.co
> >
> > On Wed, Aug 15, 2018 at 10:10 PM, Jacques Le Roux <
>

Re: Missing Security Headers in CMS Events

2018-10-08 Thread Jacques Le Roux 

+1

Jacques


Le 08/10/2018 à 10:23, Deepak Dixit a écrit :

In RequestHandler they are added to the renderView method,
I think these should move to another place as if the controller uses
any other type instead view these headers will not be added to the response.

Also we can add a separate method in UtiHttp similar to
setResponseBrowserProxyNoCache that will add these security headers.

Thanks & Regards
--
Deepak Dixit


On Mon, Oct 8, 2018 at 1:43 PM, jler...@apache.org 
wrote:


They are put in in RequesHandler. There is a "Security header" block

Jacques



Le 08/10/2018 à 09:17, Taher Alkhateeb a écrit :


Hi Deepak,

Sounds good. Are these headers applied everywhere except CMS? If no then
why not apply them everywhere?


On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
wrote:

Hello All,

While rendering the view through the controller request we set the
important security headers like x-frame-options,
strict-transport-security,
x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
response object. (Please see the 'rendervView' method of RequestHandler
class.) But these security headers are missing in the pages rendered
through CMS. (Please visit the CmsEvents class).

These headers are very crucial for the security of the application as
they
help to prevent various security threats like cross-site scripting,
cross-site request forgery, clickjacking etc.

IMO, we should add these security headers in the response object prepared
through the CMS also. WDYT?

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: Shipping data duplicated

2018-10-08 Thread jler...@apache.org 

Hi Rishi,

Inline...


Le 22/09/2018 à 12:34, Rishi Solanki a écrit :

Jacques,
Thanks for more insights.
IMO, we should rename the files as you suggested and also add some
description in the file so that we won't confuse by this in future. And
also we should keep the duplicate data as well, because when ofbizsetup app
set the data for store I assume we don't load the demo data.
About the ofbizsetup app uses, right now I could not think of it. But will
get back on it soon with details and get the inputs from community. For now
my understanding is to rename the setup files and let duplicate data exists
in the setup files.
Let me know if we can proceed with the above plan then will rename the
files and do the needful changes in the setup code.

Agreed, I created OFBIZ-10598 for that


On ofbizsetup app we
will discuss once I come with more details.

Yes no hurry, I think it needs a bit more review, love and 
documentation/information
Maybe starting by completing 
https://cwiki.apache.org/confluence/display/OFBENDUSER/How+to+Install+OFBiz+without+the+Demo+Data
 ?

Jacques



Thanks!

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Sat, Sep 22, 2018 at 2:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Rishi,

Thanks for your feedback.

Looking closely at history, ShippingData.xml was put in 9 years ago with
http://svn.apache.org/viewvc?view=revision&revision=816083, so for the
ofbizsetup app, which is a bit weirdo in OFBiz.

Then was modified with OFBIZ-5890 and OFBIZ-7673

Rest inline...


Le 22/09/2018 à 09:27, Rishi Solanki a écrit :

Hi Jacques,
I dig into it today and found that the data exists in the
"applications/datamodel/data/demo/OrderDemoData.xml" was moved from
"applications/order/data/DemoShipping.xml"
Also the data claimed as duplicate in
"applications/commonext/data/ShippingData.xml" is similar but not exact
matches with OrderDemoData.xml.

Yes, I was only speaking about "Shipping data", ie:
ShipmentMethodType
CarrierShipmentMethod
QuantityBreak
ShipmentBoxType

Those are real duplicate

The ShippingData.xml  file has no entry in
any ofbiz-component.xml.

Indeed, they are only used by the setup app. In SetupEvents.xml there is

 
 

Reading that, now I think we should not only keep the "Shipping data" in
ShippingData.xml but also the file. I would rather rename this file and
other ofbizsetup related files (at least data files) with a Setup prefix
to clearly signal they are  part of this app.
But I also wonder if the ofbizsetup app is still alive, maintained and
used by users. Last time I tried I crossed issues (not biggie IIRW). I
found
this https://issues.apache.org/jira/issues/?filter=12344840

What do you think?

Jacques

So here we can decide weather we should keep that data in

ShippingData.xml

(if someone introduce the file intentionally) or we can remove it from
trunk. In case no objection I would like to remove it as most data is
duplicate.

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Sat, Aug 18, 2018 at 1:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Rishi!

Jacques


Le 17/08/2018 à 15:19, Rishi Solanki a écrit :

This should be part of effort when we were moving all the seed, ext,

demo

data to datamodel component. I see there is no entry to load the
ShippingData.xml.
I will check this in next week and fix the duplicate data exists in the
system, or share the the reason of having this.

Probably, data moved but not removed from commonext. But I'll confirm

and

get back.

Thanks!



Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, Aug 15, 2018 at 10:10 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

Is there a reason why Shipping data are now duplicated in trunk at

   applications/commonext/data/ShippingData.xml

and

   /applications/datamodel/data/demo/OrderDemoData.xml

This is not the case with current stable

Jacques

[DISCUSSION] How can we make OFBiz more appealing to adopters and (new) contributors?

2018-10-08 Thread Pierre Smits 
Over the past two years we started on several paths to make OFBiz
better. We started with several refactoring endeavours, we initiated a new
way of documenting, etc.

But what strategic choices would benefit the project too?
- would opening up our repos more to git (GitHub) help us attract more
contributors?
Over the years we have had several discussions whether or not we would the
git way-of-working, but it always was internally oriented, not considering
the potential for furthering the project (adoption/contribution wise).
- would splitting up the combined web-apps (like marketing and sfa) into
separate components offer more choice to our potential adopters and
contributors (to work on)?
- would disentanglement of 3rd party integrations (fintech and logistic)
and the several themes into separate components offer more choice to our
potential adopters and contributors?
Several integrations are outdated or even haven't delivered on the promise
at all (consider the iDEAL fintech integration), nor did they gather
outside traction, leading to more contributors/improvements
- would the project not benefit from an approach followed by the Apache
Commons project (each component a separate repo)?

What are your thoughts?


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

Re: Missing Security Headers in CMS Events

2018-10-08 Thread Deepak Nigam 
Thank you, all.

Here is the Jira ticket 
for the same. FYI, I have included cache related properties also in the
Jira ticket.

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

On Mon, Oct 8, 2018 at 1:53 PM Deepak Dixit  wrote:

> In RequestHandler they are added to the renderView method,
> I think these should move to another place as if the controller uses
> any other type instead view these headers will not be added to the
> response.
>
> Also we can add a separate method in UtiHttp similar to
> setResponseBrowserProxyNoCache that will add these security headers.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
> On Mon, Oct 8, 2018 at 1:43 PM, jler...@apache.org 
> wrote:
>
> > They are put in in RequesHandler. There is a "Security header" block
> >
> > Jacques
> >
> >
> >
> > Le 08/10/2018 à 09:17, Taher Alkhateeb a écrit :
> >
> >> Hi Deepak,
> >>
> >> Sounds good. Are these headers applied everywhere except CMS? If no then
> >> why not apply them everywhere?
> >>
> >>
> >> On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
> >> wrote:
> >>
> >> Hello All,
> >>>
> >>> While rendering the view through the controller request we set the
> >>> important security headers like x-frame-options,
> >>> strict-transport-security,
> >>> x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in
> the
> >>> response object. (Please see the 'rendervView' method of RequestHandler
> >>> class.) But these security headers are missing in the pages rendered
> >>> through CMS. (Please visit the CmsEvents class).
> >>>
> >>> These headers are very crucial for the security of the application as
> >>> they
> >>> help to prevent various security threats like cross-site scripting,
> >>> cross-site request forgery, clickjacking etc.
> >>>
> >>> IMO, we should add these security headers in the response object
> prepared
> >>> through the CMS also. WDYT?
> >>>
> >>> Thanks & Regards
> >>> --
> >>> Deepak Nigam
> >>> HotWax Systems Pvt. Ltd.
> >>>
> >>>
>

Re: Missing Security Headers in CMS Events

2018-10-08 Thread Deepak Dixit 
In RequestHandler they are added to the renderView method,
I think these should move to another place as if the controller uses
any other type instead view these headers will not be added to the response.

Also we can add a separate method in UtiHttp similar to
setResponseBrowserProxyNoCache that will add these security headers.

Thanks & Regards
--
Deepak Dixit


On Mon, Oct 8, 2018 at 1:43 PM, jler...@apache.org 
wrote:

> They are put in in RequesHandler. There is a "Security header" block
>
> Jacques
>
>
>
> Le 08/10/2018 à 09:17, Taher Alkhateeb a écrit :
>
>> Hi Deepak,
>>
>> Sounds good. Are these headers applied everywhere except CMS? If no then
>> why not apply them everywhere?
>>
>>
>> On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
>> wrote:
>>
>> Hello All,
>>>
>>> While rendering the view through the controller request we set the
>>> important security headers like x-frame-options,
>>> strict-transport-security,
>>> x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
>>> response object. (Please see the 'rendervView' method of RequestHandler
>>> class.) But these security headers are missing in the pages rendered
>>> through CMS. (Please visit the CmsEvents class).
>>>
>>> These headers are very crucial for the security of the application as
>>> they
>>> help to prevent various security threats like cross-site scripting,
>>> cross-site request forgery, clickjacking etc.
>>>
>>> IMO, we should add these security headers in the response object prepared
>>> through the CMS also. WDYT?
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Nigam
>>> HotWax Systems Pvt. Ltd.
>>>
>>>

Re: Missing Security Headers in CMS Events

2018-10-08 Thread jler...@apache.org 

Good catch Deepak,

A Jira fits

Jacques


Le 08/10/2018 à 07:02, Deepak Nigam a écrit :

Hello All,

While rendering the view through the controller request we set the
important security headers like x-frame-options, strict-transport-security,
x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
response object. (Please see the 'rendervView' method of RequestHandler
class.) But these security headers are missing in the pages rendered
through CMS. (Please visit the CmsEvents class).

These headers are very crucial for the security of the application as they
help to prevent various security threats like cross-site scripting,
cross-site request forgery, clickjacking etc.

IMO, we should add these security headers in the response object prepared
through the CMS also. WDYT?

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: Missing Security Headers in CMS Events

2018-10-08 Thread jler...@apache.org 

They are put in in RequesHandler. There is a "Security header" block

Jacques


Le 08/10/2018 à 09:17, Taher Alkhateeb a écrit :

Hi Deepak,

Sounds good. Are these headers applied everywhere except CMS? If no then
why not apply them everywhere?


On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
wrote:


Hello All,

While rendering the view through the controller request we set the
important security headers like x-frame-options, strict-transport-security,
x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
response object. (Please see the 'rendervView' method of RequestHandler
class.) But these security headers are missing in the pages rendered
through CMS. (Please visit the CmsEvents class).

These headers are very crucial for the security of the application as they
help to prevent various security threats like cross-site scripting,
cross-site request forgery, clickjacking etc.

IMO, we should add these security headers in the response object prepared
through the CMS also. WDYT?

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: Missing Security Headers in CMS Events

2018-10-08 Thread Taher Alkhateeb 
Hi Deepak,

Sounds good. Are these headers applied everywhere except CMS? If no then
why not apply them everywhere?


On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
wrote:

> Hello All,
>
> While rendering the view through the controller request we set the
> important security headers like x-frame-options, strict-transport-security,
> x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
> response object. (Please see the 'rendervView' method of RequestHandler
> class.) But these security headers are missing in the pages rendered
> through CMS. (Please visit the CmsEvents class).
>
> These headers are very crucial for the security of the application as they
> help to prevent various security threats like cross-site scripting,
> cross-site request forgery, clickjacking etc.
>
> IMO, we should add these security headers in the response object prepared
> through the CMS also. WDYT?
>
> Thanks & Regards
> --
> Deepak Nigam
> HotWax Systems Pvt. Ltd.
>