[jira] [Commented] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16991144#comment-16991144
]
Jayansh Shinde commented on OFBIZ-10966:
Hi Mathieu,
I will check it by this week-end and will try to update it.
Meanwhile I find I am not able to reply from email, I replied earlier as well
but it was bounced. Well from next time will comment directly here.
Thanks,
Jayansh
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Jayansh Shinde
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch, OFBiz-10966.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
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=16990978#comment-16990978 ] Jacques Le Roux commented on OFBIZ-11306: - James, Not sure what way you use. It works on HEAD in Eclipse here w/o Fuzz Factor. I must day it does not work using TortoiseGit (default) 3 ways. Being on WIndows at the moment I tried, I did not try w/ 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.patch, OFBIZ-11306.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=16990922#comment-16990922 ] James Yong commented on OFBIZ-11306: Hi Jacques, I have updated my version to the latest but unable to apply the new patch to the build.gradle file. Hi Samuel, For Q1: The CSRFGuard to generate the token is referred by OWASP. The settings used are taken from this page https://www.owasp.org/index.php?title=CSRF_Guard=no For Q2: I think accessing map is faster than a list. You are right about the every growing token map. Will do the following: 1) add an option to allow a shared CSRF token for the forms. 2) Put a size limit, e.g. 50, to the token map. When this size limit is reached, the eldest entry will be deleted each time a new entry is added. > 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.patch, OFBIZ-11306.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=16990855#comment-16990855 ] Samuel Trégouët commented on OFBIZ-11306: - for the second point just thinking of an issue with only one csrf token per session if user has multiple tabs opened > 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.patch, OFBIZ-11306.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=16990853#comment-16990853 ] Samuel Trégouët commented on OFBIZ-11306: - Hi James, thanks for your POC, csrf is an important security topic when authentification is based on cookie! Here are few questions/observations: * why did you choose csrfguard ? and how did you choose configuration (token length of 32 and algorithm SHA1PRNG)? * why do you add a map into session? tokenMap is a mapping to empty string, maybe it is better to use a Set in this case ? But actually multiple tokens in session at one time seems to me a mistake. I think that if we have multiple forms on one page it's enough to reuse the same token. Because if a user asks a page with a form but never submits this form, then asks another page with another form and again never submits this second form, we will end up with an ever growing tokenMap > 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.patch, OFBIZ-11306.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=16990841#comment-16990841 ] James Yong commented on OFBIZ-11306: Thanks Jacques. Do note the same csrf token is shared between all AJAX calls for each web application user session. New Employee Form can be used to test widget form and ajax calls together. Login CSRF Token is implemented. The csrfTokenField macro is only added to following FTL forms: 1) Login Form for Rainbow Stone Theme 2) Find Employee form > 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.patch, OFBIZ-11306.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=16990833#comment-16990833
]
Mathieu Lirzin commented on OFBIZ-11296:
Hello [~mbrohl]
To my knowledge
[^OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch]
has not much impact because the {{component-load.xml}} feature is still
available for productive installations in case they want to activate/reorder
components using this feature (they simply need to create a file in the
directory of their choice). Did you notice a bug?
>From my point of view the change did not require a prior discussion, but I
>might be overlooking some important aspect that make it necessary to have such
>discussion. Maybe you have something specific in mind ?
> 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
>
>
> 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] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990824#comment-16990824
]
Mathieu Lirzin commented on OFBIZ-6993:
---
{quote}
So you finally prefer to put the Jira issue number on the title line?
{quote}
Sorry that was simply a mistake (For the record my personnal preference remains
to include the ticket reference in the body).
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
>
[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990819#comment-16990819 ] Jacques Le Roux edited comment on OFBIZ-11306 at 12/8/19 11:05 AM: --- I just attached an updated patch, only fixing conflicts issues after recent changes. I'll continue to review and test... was (Author: jacques.le.roux): I just attachec an updated patch, only fixing conflicts issues after recent changes. I'll continue to review and test... > 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.patch, OFBIZ-11306.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 ] Jacques Le Roux updated OFBIZ-11306: Attachment: (was: OFBIZ-11306.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.patch, OFBIZ-11306.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 ] Jacques Le Roux updated OFBIZ-11306: Attachment: OFBIZ-11306.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.patch, OFBIZ-11306.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=16990819#comment-16990819 ] Jacques Le Roux commented on OFBIZ-11306: - I just attachec an updated patch, only fixing conflicts issues after recent changes. I'll continue to review and test... > 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.patch, OFBIZ-11306.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 ] Jacques Le Roux updated OFBIZ-11306: Attachment: OFBIZ-11306.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.patch, OFBIZ-11306.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] [Comment Edited] (OFBIZ-11304) Install a Checkstyle pre-push on every committer machine
[ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990785#comment-16990785 ] Jacques Le Roux edited comment on OFBIZ-11304 at 12/8/19 10:15 AM: --- Hi Samuel, I agree about running check also on releases branches. It's just that the Gradle check task is a new feature so it has not been backported on them. I don't see any issue doing so. We should discuss it on dev ML. Could you please start the discussion? was (Author: jacques.le.roux): Hi Samuel, I agree about running check also on releases branches. It's just that the Gradle check task a new feature so it has not been backported on them. I don't see any issue about doing so. We should discuss it on dev ML. > Install a Checkstyle pre-push on every committer machine > > > Key: OFBIZ-11304 > URL: https://issues.apache.org/jira/browse/OFBIZ-11304 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by > the check gradle task. It's "hard" to exactly know from where lint errors > come among all still present. > I think we should rely on a Checkstyle pre-commit hook like > https://gist.github.com/davetron5000/37350 to complement > tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when > a lint error is present in the commit. > Every committer would have it installed locally and the problem would be gone > with some committers good will. I started a discussion about it at > https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same > proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3 -- 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=16990803#comment-16990803 ] Jacques Le Roux commented on OFBIZ-11306: - Thanks James! Looking at it... > 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.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] [Assigned] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-11306: --- Assignee: Jacques Le Roux (was: James Yong) > 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.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] [Reopened] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reopened OFBIZ-11296: --- This is an important change which affects the configuration options of the system and therefore has an impact on existing productive installations. Such a change needs a thorough discussion before it is introduced. it should also be provided as a patch for review of others before it gets committed to the codebase. [~mthl] I did not find a discussion or review process. In cased I've missed something, , can you please point me to them? > 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 > > > 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] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990796#comment-16990796
]
Jacques Le Roux commented on OFBIZ-6993:
After INFRA-19524 we should see here a "Development" section with a link
showing all commits in a popup window. We have nothing here, despites that we
have the Jira issue ref number in all commit. At OFBIZ-11161 we have only old
commits. I'll wait before asking Infra again about that, hopefully only a hicup
of the relation between Jira and Fisheye.
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
>
[jira] [Updated] (OFBIZ-11304) Install a Checkstyle pre-push on every committer machine
[ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11304: Summary: Install a Checkstyle pre-push on every committer machine (was: Install a Checkstyle pre-commit on every committer machine) > Install a Checkstyle pre-push on every committer machine > > > Key: OFBIZ-11304 > URL: https://issues.apache.org/jira/browse/OFBIZ-11304 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by > the check gradle task. It's "hard" to exactly know from where lint errors > come among all still present. > I think we should rely on a Checkstyle pre-commit hook like > https://gist.github.com/davetron5000/37350 to complement > tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when > a lint error is present in the commit. > Every committer would have it installed locally and the problem would be gone > with some committers good will. I started a discussion about it at > https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same > proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990787#comment-16990787
]
Jacques Le Roux commented on OFBIZ-6993:
For me, the issue seems fixed locally and in trunk demo. Good catch Samuel on
WebAppUtil::parseWebXmlFile :)
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at
[jira] [Commented] (OFBIZ-11304) Install a Checkstyle pre-commit on every committer machine
[ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990785#comment-16990785 ] Jacques Le Roux commented on OFBIZ-11304: - Hi Samuel, I agree about running check also on releases branches. It's just that the Gradle check task a new feature so it has not been backported on them. I don't see any issue about doing so. We should discuss it on dev ML. > Install a Checkstyle pre-commit on every committer machine > -- > > Key: OFBIZ-11304 > URL: https://issues.apache.org/jira/browse/OFBIZ-11304 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by > the check gradle task. It's "hard" to exactly know from where lint errors > come among all still present. > I think we should rely on a Checkstyle pre-commit hook like > https://gist.github.com/davetron5000/37350 to complement > tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when > a lint error is present in the commit. > Every committer would have it installed locally and the problem would be gone > with some committers good will. I started a discussion about it at > https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same > proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11304) Install a Checkstyle pre-commit on every committer machine
[ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990783#comment-16990783 ] Jacques Le Roux edited comment on OFBIZ-11304 at 12/8/19 9:09 AM: -- Hi Mathieu, Though I use it sometimes, I'm not a big fan of commits bursts. So I did not think about that. I agree it would be better in pre push indeed. was (Author: jacques.le.roux): Hi Mathieu, Though I use it sometimes, I'm not a big fan of commits burst. So I did not think about that. I agree it would be better in pre push indeed. > Install a Checkstyle pre-commit on every committer machine > -- > > Key: OFBIZ-11304 > URL: https://issues.apache.org/jira/browse/OFBIZ-11304 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by > the check gradle task. It's "hard" to exactly know from where lint errors > come among all still present. > I think we should rely on a Checkstyle pre-commit hook like > https://gist.github.com/davetron5000/37350 to complement > tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when > a lint error is present in the commit. > Every committer would have it installed locally and the problem would be gone > with some committers good will. I started a discussion about it at > https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same > proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11304) Install a Checkstyle pre-commit on every committer machine
[ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990783#comment-16990783 ] Jacques Le Roux commented on OFBIZ-11304: - Hi Mathieu, Though I use it sometimes, I'm not a big fan of commits burst. So I did not think about that. I agree it would be better in pre push indeed. > Install a Checkstyle pre-commit on every committer machine > -- > > Key: OFBIZ-11304 > URL: https://issues.apache.org/jira/browse/OFBIZ-11304 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > > The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by > the check gradle task. It's "hard" to exactly know from where lint errors > come among all still present. > I think we should rely on a Checkstyle pre-commit hook like > https://gist.github.com/davetron5000/37350 to complement > tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when > a lint error is present in the commit. > Every committer would have it installed locally and the problem would be gone > with some committers good will. I started a discussion about it at > https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same > proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990781#comment-16990781
]
Jacques Le Roux edited comment on OFBIZ-6993 at 12/8/19 9:04 AM:
-
Hi Mathieu,
So you finally prefer to put the Jira issue number on the title line?
It seems to me that we got to a consensus with OFBIZ-11298 to put it on a line
below the title with a new line between. Actually the initial reason we decided
to use this template was asked by Michael to be able to fill the blog monthly
post with information from Jira.
was (Author: jacques.le.roux):
Hi Mathieu,
So you finally prefer to put the Jira issue number on the title line?
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990781#comment-16990781
]
Jacques Le Roux commented on OFBIZ-6993:
Hi Mathieu,
So you finally prefer to put the Jira issue number on the title line?
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67)
>
[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=16990774#comment-16990774 ] James Yong commented on OFBIZ-11306: Prior discussion at https://lists.apache.org/x/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@ > 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: James Yong >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: OFBIZ-11306.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)
