[jira] [Commented] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008456#comment-17008456
]
Paul Foxworthy commented on OFBIZ-11315:
Hi all,
Should this be a separate utility or plugin rather than a part of OFBiz itself?
I don't see a production use for it, but it will add additional code and
increase build times. We have done several "slim down" things, is this going in
the other direction?
Thanks
Paul Foxworthy
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch,
> OFBIZ-11315-complete.patch,
> OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch,
> ofbiz.dot
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008340#comment-17008340 ] James Yong commented on OFBIZ-11306: Hi Jacques, Updated the patches to cover the missing "X-CSRF-Token" request header setting. This should address some of the issues mentioned earlier. I think it is a good practice for CRSF Token check during login. Not sure if it will be easy to set the security csrf token check to false when deploying to demo.. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: OFBIZ-11306-v2.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using CSRF Guard library and used in: > 1) In widget form where a hidden token field is auto-generated. > 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf > token field. > 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token > to X-CSRF-Token in request header. > CSRF tokens are stored in the user sessions, and verified during POST request. > A new attribute i.e. csrf-token is added to the security tag to exempt CSRF > token check. > Certain request path, like LookupPartyName, can be exempt from CSRF token > check during Ajax POST call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Yong updated OFBIZ-11306: --- Attachment: OFBIZ-11306.patch OFBIZ-11306_Plugins.patch > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: OFBIZ-11306-v2.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using CSRF Guard library and used in: > 1) In widget form where a hidden token field is auto-generated. > 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf > token field. > 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token > to X-CSRF-Token in request header. > CSRF tokens are stored in the user sessions, and verified during POST request. > A new attribute i.e. csrf-token is added to the security tag to exempt CSRF > token check. > Certain request path, like LookupPartyName, can be exempt from CSRF token > check during Ajax POST call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[
https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008303#comment-17008303
]
Jacques Le Roux commented on OFBIZ-11306:
-
Hi James,
bq. For the error when accessing /EditProdCatalogAjax, the jquery ajax call is
missing the following code. Will add in the next patch.
The same kind of error exists also in ecommerce main page tree:
{noformat}
ERROR in error page, (infinite loop or error page not found with name
[/error/error.jsp]
Original error detected, maybe it would be helps you :
org.apache.ofbiz.webapp.control.RequestHandlerException: Invalid or missing
CSRF token for AJAX call to path '/productCategoryListSecure'
{noformat}
There is also a random issue when accessing some tree leafs in humanres main
page
I guess better to check all trees in OFBiz
> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
> Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-11306-v2.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using CSRF Guard library and used in:
> 1) In widget form where a hidden token field is auto-generated.
> 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf
> token field.
> 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token
> to X-CSRF-Token in request header.
> CSRF tokens are stored in the user sessions, and verified during POST request.
> A new attribute i.e. csrf-token is added to the security tag to exempt CSRF
> token check.
> Certain request path, like LookupPartyName, can be exempt from CSRF token
> check during Ajax POST call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008275#comment-17008275 ] Michael Brohl commented on OFBIZ-11296: --- Well, actually no. A good half of my last comment is about this specific issue here, giving reasons why to keep the component-load.xml mechanism as requested. Am I really writing so unclear? > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch, > OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008054#comment-17008054 ] Michael Brohl edited comment on OFBIZ-11296 at 1/5/20 9:17 AM: --- [~mthl], please consider that people have limited time and that they have to put priorities on how they spent it. Putting pressure on (non bugfixing) issues does not help good collaborations. Please also refrain to put judgements in your statements like "why they consider to mess with..." or else. Simply trust people who are around for a long time and have deep, real life project experience with OFBiz for a long time (for me it's coming to about 18 years now). This project is not only about tech, it has a user base with serious business running on base of OFBiz. This has always to be considered as serious as good technical solutions should be considered. So we cannot simply change things because single contributors like other technical solutions better. We have to remain downwards compatible and manage deprecation of features carefully. Until now, there was not a single thumbs up from experienced contributors for this change, but objections from others. This alone should make you think about your approach. Me fighting for the right approach also does not necessarily mean that I have (current) personal or customer interests in mind. The user base is much bigger than "my" user base. If you read carefully what I previously wrote, there are several uses for the applications component-load.xml: * deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) * ordering these components in the right load order While you can argument that these might be "wrong" approaches, they are technically valid and used in customer projects. Therefore we cannot simply switch the mechanisms without a proper deprecation period. For the plugins, all the above use cases are common in our projects. We also use a multi-level configuration mechanism (standard default - custom standard default - project default and targeted systems) where we are able to do fine-grained configurations and generate the resulting component-load.xml at build time. My proposal would be to actively ask other contributors with significant project experience for their input before re-commiting anything. If there is a demand for your solution, I would also propose to make the solution compatible with the component-load mechanism and leave the old component-load.xml in place, together with a deprecation announcement and proper documentation on how to migrate. This would introduce the new depends-on in the next release but does not change anything for existing users if they want to stick with the component-load mechanism. For the plugins, I object to introduce the mechanism at all for the above stated reasons. I hope this explains my point of view clear enough, please ask if it does not. was (Author: mbrohl): [~mthl], please consider that people have limited time and that they have to put priorities on how they spent it. Putting pressure on (non bugfixing) issues does not help good collaborations. Please also refrain to put judgements in your statements like "why they consider to mess with..." or else. Simply trust people who are around for a long time and have deep, real life project experience with OFBiz for a long time (for me it's coming to about 18 years now). This project is not only about tech, it has a user base with serious business running on base of OFBiz. This has always to be considered as serious as good technical solutions should be considered. So we cannot simply change things because single contributors like other technical solutions better. We have to remain downwards compatible and manage deprecation of features carefully. Until now, there was not a single thumbs up from experienced contributors for this change, but objections from others. This alone should make you think about your approach. Me fighting for the right approach also does not necessarily mean that I have (current) personal or customer interests in mind. The user base is much bigger than "my" user base. If you read carefully what I previously wrote, there are several uses for the applications component-load.xml: * deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) * ordering these components in the right load order While you can argument that these might be "wrong" approaches, they are technically valid and
