from:"Forrest Rae"


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

Forrest Rae updated OFBIZ-7072:
---
Attachment: OFBIZ-7072.patch

> DataResource.dataResourceName field should be at least 255 Chars
> 
>
> Key: OFBIZ-7072
> URL: https://issues.apache.org/jira/browse/OFBIZ-7072
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Release 
> Branch 15.12
>Reporter: Forrest Rae
> Attachments: OFBIZ-7072.patch
>
>
> Most major operating systems limit the length of a file name to 255 chars.  
> When sending an email with file attachments, the attachments get saved as 
> DataResources associated with a CommunicationEvent, with the filename being 
> saved in the DataResource.dataResourceName field.  Currently, this field is 
> set to name, which is limited to 100 chars.  These two limitations don't add 
> up, and the field should be increased to 255 chars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars


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

Forrest Rae updated OFBIZ-7072:
---
Attachment: (was: OFBIZ-7072.patch)

> DataResource.dataResourceName field should be at least 255 Chars
> 
>
> Key: OFBIZ-7072
> URL: https://issues.apache.org/jira/browse/OFBIZ-7072
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Release 
> Branch 15.12
>Reporter: Forrest Rae
>
> Most major operating systems limit the length of a file name to 255 chars.  
> When sending an email with file attachments, the attachments get saved as 
> DataResources associated with a CommunicationEvent, with the filename being 
> saved in the DataResource.dataResourceName field.  Currently, this field is 
> set to name, which is limited to 100 chars.  These two limitations don't add 
> up, and the field should be increased to 255 chars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars


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

Forrest Rae updated OFBIZ-7072:
---
Attachment: OFBIZ-7072.patch

> DataResource.dataResourceName field should be at least 255 Chars
> 
>
> Key: OFBIZ-7072
> URL: https://issues.apache.org/jira/browse/OFBIZ-7072
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Release 
> Branch 15.12
>Reporter: Forrest Rae
> Attachments: OFBIZ-7072.patch
>
>
> Most major operating systems limit the length of a file name to 255 chars.  
> When sending an email with file attachments, the attachments get saved as 
> DataResources associated with a CommunicationEvent, with the filename being 
> saved in the DataResource.dataResourceName field.  Currently, this field is 
> set to name, which is limited to 100 chars.  These two limitations don't add 
> up, and the field should be increased to 255 chars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars

Forrest Rae created OFBIZ-7072:
--

 Summary: DataResource.dataResourceName field should be at least 
255 Chars
 Key: OFBIZ-7072
 URL: https://issues.apache.org/jira/browse/OFBIZ-7072
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release Branch 15.12, Release Branch 14.12, Release 
Branch 13.07
Reporter: Forrest Rae
 Attachments: OFBIZ-7072.patch

Most major operating systems limit the length of a file name to 255 chars.  
When sending an email with file attachments, the attachments get saved as 
DataResources associated with a CommunicationEvent, with the filename being 
saved in the DataResource.dataResourceName field.  Currently, this field is set 
to name, which is limited to 100 chars.  These two limitations don't add up, 
and the field should be increased to 255 chars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.

2016-04-08 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232323#comment-15232323
 ] 

Forrest Rae commented on OFBIZ-6993:


I'll do a little bit of digging and report back.  Perhaps reopen this bug and 
assign to me?

> 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.visitB

[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=15231671#comment-15231671
 ] 

Forrest Rae commented on OFBIZ-6993:


Deekpak, I read that in the other thread and it really doesn't have anything to 
do with this bug.

If you review the error I pasted above, the issue is that the SAXParser is 
having trouble parsing these web.xml files because it can't validate them, so 
complains that it doesn't know what  is.  It's likely that the fix is 
simply to download http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd and put it 
in the right spot in the framework so that the parser picks it up.

> 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.jav

[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=15231644#comment-15231644
 ] 

Forrest Rae commented on OFBIZ-6993:


Okay, no, this doesn't doesn't duplicate OFBIZ-6807, it's actually introduced 
by OFBIZ-6807.

Repo:

ant start-debug (watch console)
Visit webtools in browser: /webtools/control/main
See error message.

> 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(Environm

[jira] [Updated] (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:all-tabpanel
 ]

Forrest Rae updated OFBIZ-6993:
---
Attachment: web-app.patch

> 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.Iterator

[jira] [Created] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.

Forrest Rae created OFBIZ-6993:
--

 Summary: 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: Release Branch 15.12, Trunk
 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}
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)
 [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.ConditionalBlock.accept(ConditionalBlock.java:48)
 [java] at freemarker.core.Environment.visit(Environment.java:31

[jira] [Commented] (OFBIZ-6218) Unit tests throw exception in DBCP

2016-03-07 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15183234#comment-15183234
 ] 

Forrest Rae commented on OFBIZ-6218:


It's very likely that these strange errors are related to groovy scripts 
throwing exceptions that don't have error messages.  One strong possibility is 
java.util.ConcurrentModificationException.  I ran into this issue and ended up 
tracking it down to the lack of exception reporting in the GroovyScriptEngine: 
OFBIZ-6888.

> Unit tests throw exception in DBCP
> --
>
> Key: OFBIZ-6218
> URL: https://issues.apache.org/jira/browse/OFBIZ-6218
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Adrian Crum
> Attachments: OFBIZ-6218.patch
>
>
> Details in comments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6918) ApplicationDecorator Entity-One Screen Action Incomplete Primary Key

2016-02-27 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6918:
---
Attachment: OFBIZ-6918.patch

> ApplicationDecorator Entity-One Screen Action Incomplete Primary Key
> 
>
> Key: OFBIZ-6918
> URL: https://issues.apache.org/jira/browse/OFBIZ-6918
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk, Release Branch 15.12
>    Reporter: Forrest Rae
> Attachments: OFBIZ-6918.patch
>
>
> ApplicationDecorator entity-one screen action supplies an incomplete primary 
> key.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6918) ApplicationDecorator Entity-One Screen Action Incomplete Primary Key

2016-02-27 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6918:
--

 Summary: ApplicationDecorator Entity-One Screen Action Incomplete 
Primary Key
 Key: OFBIZ-6918
 URL: https://issues.apache.org/jira/browse/OFBIZ-6918
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS
Affects Versions: Release Branch 15.12, Trunk
Reporter: Forrest Rae


ApplicationDecorator entity-one screen action supplies an incomplete primary 
key.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6888) GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases

2016-02-09 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6888:
---
Attachment: OFBIZ-6888.patch

Patch to fix issue.

> GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases
> 
>
> Key: OFBIZ-6888
> URL: https://issues.apache.org/jira/browse/OFBIZ-6888
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
> Release Branch 15.12
>Reporter: Forrest Rae
>  Labels: errorhandling
> Attachments: OFBIZ-6888.patch
>
>
> If GroovyEngine.serviceInvoker catches an exception in a Groovy script, it 
> would mask the exception in some cases.  An exception's detailMessage can be 
> null.  If it is null, the exception won't be properly returned and logged, 
> and that will make spotting problems very difficult.  This was the case for 
> me while trying to track down a problem with a 
> java.util.ConcurrentModificationException error in a Groovy script.  I 
> suspect that this choice to mask exceptions and only return the message has 
> cause bugs to not be spotted.
> Disabling this for now in favor of returning a proper exception.  
> GroovyEngine.serviceInvoker() should throw GenericServiceException if error, 
> rather than returning ServiceUtil.returnError(e.getMessage())



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6888) GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases

2016-02-09 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6888:
--

 Summary: GroovyEngine.serviceInvoker masks Groovy script 
exceptions in some cases
 Key: OFBIZ-6888
 URL: https://issues.apache.org/jira/browse/OFBIZ-6888
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 15.12, Trunk, Release Branch 14.12, 
Release Branch 13.07
Reporter: Forrest Rae


If GroovyEngine.serviceInvoker catches an exception in a Groovy script, it 
would mask the exception in some cases.  An exception's detailMessage can be 
null.  If it is null, the exception won't be properly returned and logged, and 
that will make spotting problems very difficult.  This was the case for me 
while trying to track down a problem with a 
java.util.ConcurrentModificationException error in a Groovy script.  I suspect 
that this choice to mask exceptions and only return the message has cause bugs 
to not be spotted.

Disabling this for now in favor of returning a proper exception.  
GroovyEngine.serviceInvoker() should throw GenericServiceException if error, 
rather than returning ServiceUtil.returnError(e.getMessage())



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Performance over security, is that reasonable?

2016-01-16 Thread Forrest Rae

It needs to be HTTPS all the time, or HTTPS none of the time.

One of the properties of a TLS connection is data integrity. That is,
you know if data is changed in transit. This is the mechanism that
prevents a person on the network between you and the server to change
your traffic, man-in-the-middle as I'm sure everyone has heard or knows
about. If you're switching between HTTPS and HTTP based on some
criteria, an attacker can leverage that to trick the user into all kind
of things. Including changing all the embedded HTTPS URLs sent to the
user's browser during a switch from HTTP to HTTPS, back to HTTP. Chrome
would throw up all kinds of warnings about this fortunately.

Secondly, you're then putting the burden of security on the person
authoring the request-map to define that criteria for switching.

Frankly, if you're operating any web application that handles PII on the
Internet, and not using HTTPS, you're putting all your users at risk,
and you need to change that.

There is a great tool for quickly checking the basic security controls
that can be enabled for web servers, take a look at my site:
https://securityheaders.io/?q=https%3A%2F%2Fpartner.fidelissd.com%2F=on

-Forrest

On 1/2/16 3:59 PM, Scott Gray wrote:

I'm too lazy to read all the links but I think we can make some
straightforward changes to improve the situation:
1. Once a user is on https, all links generated should use https
2. If a user is on http, then that's fine and we just need to ensure that
when they switch to https (during login or any other sensitive activities)
that we're able to transfer any existing session information over to a
secure session with a new session id.

Is there any more to it?

Regards
Scott

On 3 January 2016 at 12:14, Jacques Le Roux
wrote:

Hi,

You maybe noticed that I began to work on securing and keeping OFBiz
secured better by proposing tools to use and share with the community
https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure

This started after I was confronted with the "The 2015 infamous Java
unserialize vulnerability". As explained in the wiki page, there were also
3 other points I wanted to address:

* Java<
https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check
* JavaScript<
https://cwiki.apache.org/confluence/display/OFBIZ/About+retire.js>
* HTTP headers

I already worked in end of 2013 on updating 3rd party Java lib OFBiz
depends on. It's a tedious work but mostly without surprises, it's only a
matter of rightly upgrading external libs (as much as we can).

I decided to postpone the work on JavaScript libs (it's tedious and mostly
straigthforward as well) because I thought that resolving the issues on
HTTP headers would be much simpler and it was new to me (more fun). So far
I also thought it was a minor point regarding security. I was wrong! OK, it
gets now a bit more complicated, I will try my best to explain in as less
as possible words.

I did not cross much issues, until I began to work on securing cookies. I
committed r1719762 when I decided I should have a look at OFBIZ-6655. I
then reverted r1719762 and tried to commit the proposed patches there, but
finally reverted them because of an issue in ecommerce and reapplied
r1719762. Then Pierre Smits noticed an issue on trunk demo in ecommerce. To
solve it I naively created
https://issues.apache.org/jira/browse/INFRA-10973 and dug the wrong way.
Then Deepak called me because he found an issue with r1719762 and we
decided we should revert, and he did at r1722379 (I did not get a chance
yet to check, but I trust Deepak).

I was writing this email (for few hours) when Scott just wrote
https://issues.apache.org/jira/browse/OFBIZ-6111?focusedCommentId=15076677,
and I agree with him.

But that's not the whole point of this email. While working on securing
cookies, I stumbled upon this blog post
http://resources.infosecinstitute.com/cookies-secure-flag-undesired-behavior-modern-browsers/.
Long story short, you can't have the cake and eat it too. Or rather you
can't use HTTP and be secure if you also use sessions (this is what OFBiz
ecommerce does). I wrote in the title about "Performance over security".
Because the only remaining reason nowadays people would want HTTP is for
performance caching adds.
There is some good articles about that:

http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/

https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything

https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol

To summarize with letsencrypt
https://community.letsencrypt.org/t/frequently-asked-questions-faq
and Server Name Indication
https://en.wikipedia.org/wiki/Server_Name_Indication

https://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/
most of the other concerns are off (we use TLS for a while

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out from 
[applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608],
 is a required parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.

Reproduce:
# Grab a sample PDF file from 
[here|http://www.indire.it/wp-content/uploads/2015/08/pdf-sample.pdf]
# Visit 
http://demo-stable-ofbiz.apache.org/ordermgr/control/createCustRequestContent?custRequestId=9000
# Select the PDF file to upload, leave all other fields default
# Click Create
# Notice the error message: Upload file type not match your selected.


  was:
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out from 
[applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608],
 is a required parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call t

[jira] [Commented] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


[ 
https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058335#comment-15058335
 ] 

Forrest Rae commented on OFBIZ-6770:


Pierre, While it seems that in trunk createContentFromUploadedFile has been 
replaced by a more modular design, createCustRequestContent event seems to 
still be available in trunk.

> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://issues.apache.org/jira/browse/OFBIZ-6770
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
> Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, 
> OFBIZ-6770-option3.patch
>
>
> This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] 
> disabled the mimeTypeId argument in 
> applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
> "various fixes".  I wonder how many people have been frustrated by this when 
> looking for example code on how to upload documents.  
> The issue is that mimeTypeId field that was commented out from 
> [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608],
>  is a required parameter by 
> [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
>   Lines 52-54 check it's value for the following:
> Line 
> [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
>  if-compare is "Does the web browser's choice of mimeTypeId equal what the 
> user thinks the mimeTypeId is?"
> Line 
> [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
>  if-compare is "Did the user select anything at all in the mimeTypeId 
> dropdown?" (Before the mimeTypeId field was commented out.)
> Line 
> [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
>  if-compare is "Did the user submit mimeTypeId form field, but remove the 
> value, submitting a blank form field?"  This is the weird case, as really 
> this should be a is-null check.
> My question is why are we even doing any of this when the event just goes on 
> to set the mimeType to what the web browser decided it was, and then to call 
> createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
> the call to createContentFromUploadedFile calls createDataResource, which at 
> applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
> org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
> just let tika handle the mimeType?
> Anyway, I dunno enough about the Content component to make the decision here. 
>  I've attached three different patches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6766) Secure HTTP headers


[ 
https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058472#comment-15058472
 ] 

Forrest Rae commented on OFBIZ-6766:


Jacques, apologies for the questions if they weren't applicable, I didn't have 
any background info.  I thought you were suggesting not enabling protections, 
but I see you're accomplishing it in another manner.

Can you link me to RequestHandler?  I've not seen any info on it.

> Secure HTTP headers
> ---
>
> Key: OFBIZ-6766
> URL: https://issues.apache.org/jira/browse/OFBIZ-6766
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> I have created a wiki page for this 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This commit disabled the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes"

https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661

I wonder how many people have been frustrated by this when looking for example 
code on how to upload documents.

The issue is that mimeTypeId is required by createCustRequestContent.  Lines 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54
 check it's value:




This patch isn't really a fix, but more of a work around.  The issue lies in 
the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.

First if-compare is "Does the web browser's choice of mimeTypeId equal what the 
user thinks the mimeTypeId is?"

Second if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?"

Third choice is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.

  was:
This commit disabled the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes"

https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661

I wonder how many people have been frustrated by this when looking for example 
code on how to upload documents.

This patch isn't really a fix, but more of a work around.  The issue lies in 
the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.

First if-compare is "Does the web browser's choice of mimeTypeId equal what the 
user thinks the mimeTypeId is?"

Second if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?"

Third choice is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.


> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://issues.apache.org/jira/browse/OFBIZ-6770
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
> Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, 
> OFBIZ-6770-option3.patch
>
>
> This commit disabled the mimeTypeId argument in 
> applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
> "various fixes"
> https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661
> I wonder how many people have been frustrated by this when looking for 
> example code on how to upload documents.
> The issue is that mimeTypeId is required by createCustRequestContent.  Lines 
> [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54
>  check it's value:
> This patch isn't really a fix, but more of a work around.  The issue lies in 
> the seemly arbitrary check of the mimeTypeId parameter in 
> applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.



  was:
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

The issue lies in the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.


My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.




> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://i

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

The issue lies in the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.


My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.



  was:
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a if-null

The issue lies in the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.


My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three differe

[jira] [Commented] (OFBIZ-6766) Secure HTTP headers


[ 
https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058376#comment-15058376
 ] 

Forrest Rae commented on OFBIZ-6766:


One more thing, are any of these going to be backported?

> Secure HTTP headers
> ---
>
> Key: OFBIZ-6766
> URL: https://issues.apache.org/jira/browse/OFBIZ-6766
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> I have created a wiki page for this 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a if-null

The issue lies in the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.


My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.



  was:
This commit disabled the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes"

https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661

I wonder how many people have been frustrated by this when looking for example 
code on how to upload documents.

The issue is that mimeTypeId is required by createCustRequestContent.  Lines 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54
 check it's value:




This patch isn't really a fix, but more of a work around.  The issue lies in 
the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.

First if-compare is "Does the web browser's choice of mimeTypeId equal what the 
user thinks the mimeTypeId is?"

Second if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?"

Third choice is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.


> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://issues.apache.org/jira/browse/OFBIZ-6770
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
> Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, 
> OFBIZ-6770-option3.patch
>
>
> Thi

[jira] [Commented] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


[ 
https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058319#comment-15058319
 ] 

Forrest Rae commented on OFBIZ-6770:


Sorry, I didn't mean to leave out important details, and sorry for all the 
emails to the Dev mailing list while trying to correct the description.  You 
click anywhere outside of the description and it saves.

> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://issues.apache.org/jira/browse/OFBIZ-6770
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
> Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, 
> OFBIZ-6770-option3.patch
>
>
> This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] 
> disabled the mimeTypeId argument in 
> applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
> "various fixes".  I wonder how many people have been frustrated by this when 
> looking for example code on how to upload documents.  
> The issue is that mimeTypeId field that was commented out from 
> [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608],
>  is a required parameter by 
> [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
>   Lines 52-54 check it's value for the following:
> Line 
> [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
>  if-compare is "Does the web browser's choice of mimeTypeId equal what the 
> user thinks the mimeTypeId is?"
> Line 
> [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
>  if-compare is "Did the user select anything at all in the mimeTypeId 
> dropdown?" (Before the mimeTypeId field was commented out.)
> Line 
> [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
>  if-compare is "Did the user submit mimeTypeId form field, but remove the 
> value, submitting a blank form field?"  This is the weird case, as really 
> this should be a is-null check.
> My question is why are we even doing any of this when the event just goes on 
> to set the mimeType to what the web browser decided it was, and then to call 
> createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
> the call to createContentFromUploadedFile calls createDataResource, which at 
> applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
> org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
> just let tika handle the mimeType?
> Anyway, I dunno enough about the Content component to make the decision here. 
>  I've attached three different patches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months


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

Forrest Rae updated OFBIZ-6770:
---
Description: 
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out from 
[applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608],
 is a required parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.



  was:
This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled 
the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes".  I wonder how many people have been frustrated by this when 
looking for example code on how to upload documents.  

The issue is that mimeTypeId field that was commented out, is a required 
parameter by 
[createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23].
  Lines 52-54 check it's value for the following:

Line 
[52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]:
 if-compare is "Does the web browser's choice of mimeTypeId equal what the user 
thinks the mimeTypeId is?"
Line 
[53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]:
 if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?" (Before the mimeTypeId field was commented out.)
Line 
[54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]:
 if-compare is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"  This is the weird case, as really this 
should be a is-null check.

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.




> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
&

[jira] [Commented] (OFBIZ-6766) Secure HTTP headers


[ 
https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058373#comment-15058373
 ] 

Forrest Rae commented on OFBIZ-6766:


Also, definitely enable support for CORS, there is a great write-up here: 
https://scotthelme.co.uk/content-security-policy-an-introduction/

> Secure HTTP headers
> ---
>
> Key: OFBIZ-6766
> URL: https://issues.apache.org/jira/browse/OFBIZ-6766
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> I have created a wiki page for this 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6766) Secure HTTP headers


[ 
https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058394#comment-15058394
 ] 

Forrest Rae commented on OFBIZ-6766:


Two useful sites besides CheckYourHeaders:

https://securityheaders.io/
https://report-uri.io/

> Secure HTTP headers
> ---
>
> Key: OFBIZ-6766
> URL: https://issues.apache.org/jira/browse/OFBIZ-6766
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> I have created a wiki page for this 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6766) Secure HTTP headers


[ 
https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058368#comment-15058368
 ] 

Forrest Rae commented on OFBIZ-6766:


Jacques,

In the spirit of secure by default I'd like to throw my vote in for 
HttpHeaderSecurityFilter being enabled by default moving forward.

hstsEnabled is an absolute must, do this over the other two.  A work around if 
you leverage the mod_ajpproxy setup of Apache server in front of Tomcat, there 
is a really awesome Apache config found in the Better Crypto Guide that enables 
HSTS here: https://bettercrypto.org

blockContentTypeSniffingEnabled would really help in situations where file 
uploads are replayed back to another user's web browser to prevent arbitrary 
HTML and JavaScript being executed in the SAMEORIGIN.  More info: 
http://security.stackexchange.com/questions/12896/does-x-content-type-options-really-prevent-content-sniffing-attacks

Clickjacking can be more severe than you think, and any counter measures you 
can provide would be great for users.

> Secure HTTP headers
> ---
>
> Key: OFBIZ-6766
> URL: https://issues.apache.org/jira/browse/OFBIZ-6766
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> I have created a wiki page for this 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months

2015-12-14 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6770:
--

 Summary: createCustRequestContent Hasn't worked in 6 years and 7 
months
 Key: OFBIZ-6770
 URL: https://issues.apache.org/jira/browse/OFBIZ-6770
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
Release Branch 12.04, Release Branch 11.04
Reporter: Forrest Rae


This commit disabled the mimeTypeId argument in 
applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
"various fixes"

https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661

I wonder how many people have been frustrated by this when looking for example 
code on how to upload documents.

This patch isn't really a fix, but more of a work around.  The issue lies in 
the seemly arbitrary check of the mimeTypeId parameter in 
applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 
52-54.

First if-compare is "Does the web browser's choice of mimeTypeId equal what the 
user thinks the mimeTypeId is?"

Second if-compare is "Did the user select anything at all in the mimeTypeId 
dropdown?"

Third choice is "Did the user submit mimeTypeId form field, but remove the 
value, submitting a blank form field?"

My question is why are we even doing any of this when the event just goes on to 
set the mimeType to what the web browser decided it was, and then to call 
createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
the call to createContentFromUploadedFile calls createDataResource, which at 
applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
just let tika handle the mimeType?

Anyway, I dunno enough about the Content component to make the decision here.  
I've attached three different patches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months

2015-12-14 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6770:
---
Attachment: OFBIZ-6770-option3.patch
OFBIZ-6770-option2.patch
OFBIZ-6770-option1.patch

> createCustRequestContent Hasn't worked in 6 years and 7 months
> --
>
> Key: OFBIZ-6770
> URL: https://issues.apache.org/jira/browse/OFBIZ-6770
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
> Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, 
> OFBIZ-6770-option3.patch
>
>
> This commit disabled the mimeTypeId argument in 
> applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide 
> "various fixes"
> https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661
> I wonder how many people have been frustrated by this when looking for 
> example code on how to upload documents.
> This patch isn't really a fix, but more of a work around.  The issue lies in 
> the seemly arbitrary check of the mimeTypeId parameter in 
> applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, 
> lines 52-54.
> First if-compare is "Does the web browser's choice of mimeTypeId equal what 
> the user thinks the mimeTypeId is?"
> Second if-compare is "Did the user select anything at all in the mimeTypeId 
> dropdown?"
> Third choice is "Did the user submit mimeTypeId form field, but remove the 
> value, submitting a blank form field?"
> My question is why are we even doing any of this when the event just goes on 
> to set the mimeType to what the web browser decided it was, and then to call 
> createContentFromUploadedFile service?  Also, if mimeTypeId is in fact empty, 
> the call to createContentFromUploadedFile calls createDataResource, which at 
> applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls 
> org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway.  Why not 
> just let tika handle the mimeType?
> Anyway, I dunno enough about the Content component to make the decision here. 
>  I've attached three different patches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-610) Remove all instances of 'required-permissions' usage in service definition files.

2015-12-10 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051460#comment-15051460
 ] 

Forrest Rae commented on OFBIZ-610:
---

I know this is quite old, but did you ever consider a case where you'd need to 
do:

{code|borderStyle=solid}




{code}

I just spent weeks implementing something like this, and then stumbled across 
this, showing that  is deprecated.

> Remove all instances of 'required-permissions' usage in service definition 
> files.
> -
>
> Key: OFBIZ-610
> URL: https://issues.apache.org/jira/browse/OFBIZ-610
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework, order, product
>Reporter: Andrew Zeneski
>Assignee: Andrew Zeneski
> Fix For: Trunk
>
>
> There are currently 61 instances of service definitions which use the now 
> deprecated  tag. These definitions should all be 
> updated and new permissions services implemented (as needed) to use the new 
>  tag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-610) Remove all instances of 'required-permissions' usage in service definition files.

2015-12-10 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051460#comment-15051460
 ] 

Forrest Rae edited comment on OFBIZ-610 at 12/10/15 6:56 PM:
-

I know this is quite old, but did you ever consider a case where you'd need to 
do:

{code:xml}




{code}

I just spent weeks implementing something like this, and then stumbled across 
this, showing that  is deprecated.


was (Author: f...@14x.net):
I know this is quite old, but did you ever consider a case where you'd need to 
do:

{code|borderStyle=solid}




{code}

I just spent weeks implementing something like this, and then stumbled across 
this, showing that  is deprecated.

> Remove all instances of 'required-permissions' usage in service definition 
> files.
> -
>
> Key: OFBIZ-610
> URL: https://issues.apache.org/jira/browse/OFBIZ-610
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework, order, product
>Reporter: Andrew Zeneski
>Assignee: Andrew Zeneski
> Fix For: Trunk
>
>
> There are currently 61 instances of service definitions which use the now 
> deprecated  tag. These definitions should all be 
> updated and new permissions services implemented (as needed) to use the new 
>  tag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect

2015-11-14 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005621#comment-15005621
 ] 

Forrest Rae commented on OFBIZ-6721:


Thanks Jacques, I'll take some time in the next month or so to improve the 
password checking code a bit in trunk, and put in support for PBKDF2 with 
rolling password hash upgrades for posix style password storage.

> org.ofbiz.common.login.LoginServices.userLogin causes stack track when 
> username or password is incorrect
> 
>
> Key: OFBIZ-6721
> URL: https://issues.apache.org/jira/browse/OFBIZ-6721
> Project: OFBiz
>  Issue Type: Improvement
>  Components: commonext/setup
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
>Assignee: Jacques Le Roux
>Priority: Trivial
>  Labels: log, test-failure
> Fix For: 14.12.01, 12.04.06, 13.07.03, Upcoming Branch
>
> Attachments: OFBIZ-6721.patch
>
>
> org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a 
> username or password is incorrect.  It should return FAILURE instead of 
> error.  The error causes stack track to be printed to the log.  The stack 
> trace makes watching the log for actual errors difficult.  This is especially 
> hard when running and analyzing the log after a full test run, of in my case, 
> a custom set of test cases.
> Stack trace:
> [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7  |LoginWorker 
>   |I| Setting default delegator
> [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7  |LoginServices   
>   |I| [LoginServices.userLogin] : Password Incorrect
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |ServiceDispatcher   
>   |E| Error in Service [userLogin]: Password incorrect.
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |TransactionUtil 
>   |E| [TransactionUtil.rollback]
> [java] java.lang.Exception: Stack Trace
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88)
>  [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) 
> [ofbiz-webapp.jar:?]
> [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_60]
> [java]at java.lang.reflect.Method.invoke(Method.java:497) 
> ~[?:1.8.0_60]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) 
> [ofbiz-webapp.jar:?]
> [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) 
> [servlet-api-3.0.jar:?]
> [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) 
> [servlet-api-3.0.jar:?]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  [tomcat-7.0.64-catalina.jar:7.0.64]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  [tomcat-7.0.64-catalina.jar:7.0.64]
> [ja

[jira] [Commented] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect

2015-11-13 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004547#comment-15004547
 ] 

Forrest Rae commented on OFBIZ-6721:


I believe it is a bug.  You have to consider how this is being used by people 
extending the framework.  The difference between ERROR and FAILURE when it 
comes to authentication, especially when you need to rely on 
ignore-failure="false" ignore-error="false", is a blocker for me.  I have a 
SECA on userLogin service, and I need to know if there was an ERROR, or there 
was a FAILURE.  This prevents my ability to augment the authentication process. 
 

In my use case, I need to make sure OOTB authentication passes, and then I need 
to check the status of a series of relationships, and then I save some data to 
some custom entities.  Here is my SECA:





I considered building an external 
org.ofbiz.common.authentication.api.Authenticator, but the main issue is the 
external auth runs first, before the password check.  This creates an 
opportunity to brute force usernames based on time inference, if the code has 
to do several operations before ever checking if the authentication details are 
correct, not to mention invalid data to custom entities.  A SECA is more 
advantageous here.

> org.ofbiz.common.login.LoginServices.userLogin causes stack track when 
> username or password is incorrect
> 
>
> Key: OFBIZ-6721
> URL: https://issues.apache.org/jira/browse/OFBIZ-6721
> Project: OFBiz
>  Issue Type: Improvement
>  Components: commonext/setup
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
>Assignee: Jacques Le Roux
>Priority: Trivial
>  Labels: log, test-failure
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6721.patch
>
>
> org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a 
> username or password is incorrect.  It should return FAILURE instead of 
> error.  The error causes stack track to be printed to the log.  The stack 
> trace makes watching the log for actual errors difficult.  This is especially 
> hard when running and analyzing the log after a full test run, of in my case, 
> a custom set of test cases.
> Stack trace:
> [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7  |LoginWorker 
>   |I| Setting default delegator
> [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7  |LoginServices   
>   |I| [LoginServices.userLogin] : Password Incorrect
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |ServiceDispatcher   
>   |E| Error in Service [userLogin]: Password incorrect.
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |TransactionUtil 
>   |E| [TransactionUtil.rollback]
> [java] java.lang.Exception: Stack Trace
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88)
>  [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) 
> [ofbiz-webapp.jar:?]
> [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_60]
> [java]at java.lang.reflect.Method.invoke(Method.java:497) 
> ~[?:1.8.0_60]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476

[jira] [Comment Edited] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect

2015-11-13 Thread Forrest Rae (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004547#comment-15004547
 ] 

Forrest Rae edited comment on OFBIZ-6721 at 11/13/15 7:23 PM:
--

I believe it is a bug.  You have to consider how this is being used by people 
extending the framework.  The difference between ERROR and FAILURE when it 
comes to authentication, especially when you need to rely on 
ignore-failure="false" ignore-error="false", is a blocker for me.  I have a 
SECA on userLogin service, and I need to know if there was an ERROR, or there 
was a FAILURE.  This prevents my ability to augment the authentication process. 
 

In my use case, I need to make sure OOTB authentication passes, and then I need 
to check the status of a series of relationships, and then I save some data to 
some custom entities.  Here is my SECA:





I considered building an external 
org.ofbiz.common.authentication.api.Authenticator, but the main issue is the 
external auth runs first, before the password check.  This creates an 
opportunity to brute force usernames based on time inference, if the code has 
to do several operations before ever checking if the authentication details are 
correct, not to mention invalid data to custom entities.  A SECA is more 
advantageous here.

Perhaps the bug title and original description probably should have contained 
this info, but I'm trying not to disclose too much information.


was (Author: f...@14x.net):
I believe it is a bug.  You have to consider how this is being used by people 
extending the framework.  The difference between ERROR and FAILURE when it 
comes to authentication, especially when you need to rely on 
ignore-failure="false" ignore-error="false", is a blocker for me.  I have a 
SECA on userLogin service, and I need to know if there was an ERROR, or there 
was a FAILURE.  This prevents my ability to augment the authentication process. 
 

In my use case, I need to make sure OOTB authentication passes, and then I need 
to check the status of a series of relationships, and then I save some data to 
some custom entities.  Here is my SECA:





I considered building an external 
org.ofbiz.common.authentication.api.Authenticator, but the main issue is the 
external auth runs first, before the password check.  This creates an 
opportunity to brute force usernames based on time inference, if the code has 
to do several operations before ever checking if the authentication details are 
correct, not to mention invalid data to custom entities.  A SECA is more 
advantageous here.

> org.ofbiz.common.login.LoginServices.userLogin causes stack track when 
> username or password is incorrect
> 
>
> Key: OFBIZ-6721
> URL: https://issues.apache.org/jira/browse/OFBIZ-6721
> Project: OFBiz
>  Issue Type: Improvement
>  Components: commonext/setup
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
>Assignee: Jacques Le Roux
>Priority: Trivial
>  Labels: log, test-failure
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6721.patch
>
>
> org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a 
> username or password is incorrect.  It should return FAILURE instead of 
> error.  The error causes stack track to be printed to the log.  The stack 
> trace makes watching the log for actual errors difficult.  This is especially 
> hard when running and analyzing the log after a full test run, of in my case, 
> a custom set of test cases.
> Stack trace:
> [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7  |LoginWorker 
>   |I| Setting default delegator
> [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7  |LoginServices   
>   |I| [LoginServices.userLogin] : Password Incorrect
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |ServiceDispatcher   
>   |E| Error in Service [userLogin]: Password incorrect.
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |TransactionUtil 
>   |E| [TransactionUtil.rollback]
> [java] java.lang.Exception: Stack Trace
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(Service

[jira] [Updated] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect

2015-11-12 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6721:
---
Attachment: OFBIZ-6721.patch

One line patch.

> org.ofbiz.common.login.LoginServices.userLogin causes stack track when 
> username or password is incorrect
> 
>
> Key: OFBIZ-6721
> URL: https://issues.apache.org/jira/browse/OFBIZ-6721
> Project: OFBiz
>  Issue Type: Bug
>  Components: commonext/setup
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
>  Labels: log, test-failure
> Attachments: OFBIZ-6721.patch
>
>
> org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a 
> username or password is incorrect.  It should return FAILURE instead of 
> error.  The error causes stack track to be printed to the log.  The stack 
> trace makes watching the log for actual errors difficult.  This is especially 
> hard when running and analyzing the log after a full test run, of in my case, 
> a custom set of test cases.
> Stack trace:
> [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7  |LoginWorker 
>   |I| Setting default delegator
> [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7  |LoginServices   
>   |I| [LoginServices.userLogin] : Password Incorrect
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |ServiceDispatcher   
>   |E| Error in Service [userLogin]: Password incorrect.
> [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |TransactionUtil 
>   |E| [TransactionUtil.rollback]
> [java] java.lang.Exception: Stack Trace
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299)
>  [ofbiz-entity.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) 
> [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88)
>  [ofbiz-service.jar:?]
> [java]at 
> org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) 
> [ofbiz-webapp.jar:?]
> [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_60]
> [java]at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_60]
> [java]at java.lang.reflect.Method.invoke(Method.java:497) 
> ~[?:1.8.0_60]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) 
> [ofbiz-webapp.jar:?]
> [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) 
> [servlet-api-3.0.jar:?]
> [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) 
> [servlet-api-3.0.jar:?]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  [tomcat-7.0.64-catalina.jar:7.0.64]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  [tomcat-7.0.64-catalina.jar:7.0.64]
> [java]at 
> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:323) 
> [ofbiz-webapp.jar:?]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  [tomcat-7.0.64-catalina.jar:7.0.64]
> [java]at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

[jira] [Created] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect

2015-11-12 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6721:
--

 Summary: org.ofbiz.common.login.LoginServices.userLogin causes 
stack track when username or password is incorrect
 Key: OFBIZ-6721
 URL: https://issues.apache.org/jira/browse/OFBIZ-6721
 Project: OFBiz
  Issue Type: Bug
  Components: commonext/setup
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
Release Branch 12.04, Release Branch 11.04
Reporter: Forrest Rae


org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a 
username or password is incorrect.  It should return FAILURE instead of error.  
The error causes stack track to be printed to the log.  The stack trace makes 
watching the log for actual errors difficult.  This is especially hard when 
running and analyzing the log after a full test run, of in my case, a custom 
set of test cases.

Stack trace:

[java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7  |LoginWorker   
|I| Setting default delegator
[java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7  |LoginServices 
|I| [LoginServices.userLogin] : Password Incorrect
[java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |ServiceDispatcher 
|E| Error in Service [userLogin]: Password incorrect.
[java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7  |TransactionUtil   
|E| [TransactionUtil.rollback]
[java] java.lang.Exception: Stack Trace
[java]  at 
org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) 
[ofbiz-entity.jar:?]
[java]  at 
org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) 
[ofbiz-entity.jar:?]
[java]  at 
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) 
[ofbiz-service.jar:?]
[java]  at 
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) 
[ofbiz-service.jar:?]
[java]  at 
org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88)
 [ofbiz-service.jar:?]
[java]  at org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) 
[ofbiz-webapp.jar:?]
[java]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[?:1.8.0_60]
[java]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:1.8.0_60]
[java]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.8.0_60]
[java]  at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_60]
[java]  at 
org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) 
[ofbiz-webapp.jar:?]
[java]  at 
org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) 
[ofbiz-webapp.jar:?]
[java]  at 
org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) 
[ofbiz-webapp.jar:?]
[java]  at 
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) 
[ofbiz-webapp.jar:?]
[java]  at 
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
[ofbiz-webapp.jar:?]
[java]  at 
org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) 
[ofbiz-webapp.jar:?]
[java]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) 
[servlet-api-3.0.jar:?]
[java]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) 
[servlet-api-3.0.jar:?]
[java]  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:323) 
[ofbiz-webapp.jar:?]
[java]  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) 
[tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) 
[tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
 [tomcat-7.0.64-catalina.jar:7.0.64]
[java]  at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) 
[tomcat-7.0.64-catalina.jar:7.0.64]
[java

[jira] [Created] (OFBIZ-6662) PartyRelationship.securityGroupId not added when adding a PartyRelationship

2015-10-01 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6662:
--

 Summary: PartyRelationship.securityGroupId not added when adding a 
PartyRelationship
 Key: OFBIZ-6662
 URL: https://issues.apache.org/jira/browse/OFBIZ-6662
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
Release Branch 12.04, Release Branch 11.04
Reporter: Forrest Rae


When adding a PartyRelationship the value selected for SecurityGroupId is 
ignored as createPartyRelationship service expects the parameter to be named 
securityGroupId.  The AddOtherPartyRelationship form incorrectly names the 
field groupId causing the value to be missed in the set-nonpk-fields call in 
applications/party/script/org/ofbiz/party/party/PartyServices.xml at line 821.

This bug can be traced back 7 years and 1 month to when the code was originally 
committed, showing that it never worked in the first place :(

https://fisheye6.atlassian.com/changelog/ofbiz?cs=688484

Repo:
1) While adding a relationship, select something in the Security Group ID 
select menu.
2) Submit
3) Webtools -> Entity Engine -> PartyRelationship -> Find
4) Search for the PartyRelationship
5) Not that the securityGroupId field is empty even though you selected one in 
step 1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6662) PartyRelationship.securityGroupId not added when adding a PartyRelationship

2015-10-01 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6662:
---
Attachment: OFBIZ-6662-partymgr.patch

> PartyRelationship.securityGroupId not added when adding a PartyRelationship
> ---
>
> Key: OFBIZ-6662
> URL: https://issues.apache.org/jira/browse/OFBIZ-6662
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Forrest Rae
>  Labels: patch
> Attachments: OFBIZ-6662-partymgr.patch
>
>
> When adding a PartyRelationship the value selected for SecurityGroupId is 
> ignored as createPartyRelationship service expects the parameter to be named 
> securityGroupId.  The AddOtherPartyRelationship form incorrectly names the 
> field groupId causing the value to be missed in the set-nonpk-fields call in 
> applications/party/script/org/ofbiz/party/party/PartyServices.xml at line 821.
> This bug can be traced back 7 years and 1 month to when the code was 
> originally committed, showing that it never worked in the first place :(
> https://fisheye6.atlassian.com/changelog/ofbiz?cs=688484
> Repo:
> 1) While adding a relationship, select something in the Security Group ID 
> select menu.
> 2) Submit
> 3) Webtools -> Entity Engine -> PartyRelationship -> Find
> 4) Search for the PartyRelationship
> 5) Not that the securityGroupId field is empty even though you selected one 
> in step 1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6605) createQuoteRole, createContentRole, and createRequirementRole allow for adding Roles to a Party without permissions

2015-09-04 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6605:
--

 Summary: createQuoteRole, createContentRole, and 
createRequirementRole allow for adding Roles to a Party without permissions
 Key: OFBIZ-6605
 URL: https://issues.apache.org/jira/browse/OFBIZ-6605
 Project: OFBiz
  Issue Type: Bug
  Components: content, order
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
Release Branch 11.04
Reporter: Forrest Rae


The following functions automatically add a PartyRole entry if the PartyRole 
does not exist.  This is possible even when the userLogin doesn't have 
PARTYMGR_UPDATE or PARTYMGR_CREATE.

createQuoteRole
createContentRole
createRequirementRole

Repo:
1) Remove PARTYMGR_UPDATE or PARTYMGR_CREATE permissions from the ORDERENTRY 
group.
2) Login as DemoRepStore
3) Create a Quote
4) Add a QuoteRole with partyId of DemoRepStore and Role of your choosing.
5) View DemoRepStore roles.

This is a security problem for anyone building component that leverages Role 
based security.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6493) extend-entity doesn't support foreign key creation with relation

2015-06-10 Thread Forrest Rae (JIRA)


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

Forrest Rae commented on OFBIZ-6493:


I think this also includes functionality like not-null not being enforced.

 extend-entity doesn't support foreign key creation with relation
 

 Key: OFBIZ-6493
 URL: https://issues.apache.org/jira/browse/OFBIZ-6493
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Release Branch 13.07, Trunk
Reporter: Christian Carlow
Priority: Minor

 http://ofbiz.135035.n4.nabble.com/Can-t-get-a-Relation-to-Create-a-FK-Constraint-td4669874.html
 This worked for neither trunk nor 13.07.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6444) Postal Address PDF Formatter Screen Problems

2015-06-03 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6444:
---
Attachment: OFBIZ-6444.patch

Patch should work against all versions as it's fairly simple.

 Postal Address PDF Formatter Screen Problems
 

 Key: OFBIZ-6444
 URL: https://issues.apache.org/jira/browse/OFBIZ-6444
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
 Branch 14.12, Trunk
Reporter: Forrest Rae
 Attachments: OFBIZ-6444.patch


 A couple updates are needed to the postalAddressPdfFormatter screen:
 First, the screen template is set to use the HTML renderer which results in 
 this error in the log:
 [java] 2015-06-03 13:44:53,400 |0.0.0.0-8009-exec-13 |ModelScreenWidget   
   |W| In platform-dependent could not find template for xsl-fo, using the 
 one for html.
 Second, the various PostalAddress.fo.ftl files do not escape XML 
 properly, and addresses with an  in them end up causing a FreeMarker 
 template error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6444) Postal Address PDF Formatter Screen Problems

2015-06-03 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6444:
--

 Summary: Postal Address PDF Formatter Screen Problems
 Key: OFBIZ-6444
 URL: https://issues.apache.org/jira/browse/OFBIZ-6444
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
Release Branch 12.04
Reporter: Forrest Rae
 Attachments: OFBIZ-6444.patch

A couple updates are needed to the postalAddressPdfFormatter screen:

First, the screen template is set to use the HTML renderer which results in 
this error in the log:

[java] 2015-06-03 13:44:53,400 |0.0.0.0-8009-exec-13 |ModelScreenWidget 
|W| In platform-dependent could not find template for xsl-fo, using the one 
for html.

Second, the various PostalAddress.fo.ftl files do not escape XML properly, 
and addresses with an  in them end up causing a FreeMarker template error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms

Forrest Rae created OFBIZ-6431:
--

 Summary: Error on Sending confirm email from newly created quote, 
Quote without Terms
 Key: OFBIZ-6431
 URL: https://issues.apache.org/jira/browse/OFBIZ-6431
 Project: OFBiz
  Issue Type: Bug
  Components: order
 Environment: 
http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail
Reporter: Forrest Rae


Error on Sending confirm email from newly created quote

http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail



The Following Errors Occurred:

Error rendering screen for email: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null)) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null))) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null)) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms


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

Forrest Rae updated OFBIZ-6431:
---
Description: 
I cloned this bug, since I couldn't reopen.  Create a quote with items and a 
QuoteTerm, and try sending the quote by email.  When you try to send the report 
via email, you'll get a NullPointerException.  I traced this done to the fact 
that ListQuoteInfo use a screenlet.  
org.ofbiz.widget.screen.ModelScreenWidget.Screenlet.renderWidgetString() calls 
org.ofbiz.widget.html.HtmlScreenRenderer.renderScreenletBegin() which calls 
org.ofbiz.base.util.UtilHttp.isJavaScriptEnabled().  The exception is thrown 
because there is no Request or Response context, as these screens are being 
generated via a service call.

===
Error on Sending confirm email from newly created quote

http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail



The Following Errors Occurred:

Error rendering screen for email: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null)) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null))) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null)) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null


  was:
Error on Sending confirm email from newly created quote

http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail



The Following Errors Occurred:

Error rendering screen for email: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null)) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null))) (Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
java.lang.NullPointerException (null) (Error

[jira] [Updated] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms


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

Forrest Rae updated OFBIZ-6431:
---
Affects Version/s: Release Branch 13.07
   Release Branch 14.12
   Trunk

 Error on Sending confirm email from newly created quote, Quote without Terms
 

 Key: OFBIZ-6431
 URL: https://issues.apache.org/jira/browse/OFBIZ-6431
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk
 Environment: 
 http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail
Reporter: Forrest Rae

 Error on Sending confirm email from newly created quote
 http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail
 The Following Errors Occurred:
 Error rendering screen for email: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null)) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null))) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null)) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms


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

Forrest Rae closed OFBIZ-6431.
--
Resolution: Fixed

 Error on Sending confirm email from newly created quote, Quote without Terms
 

 Key: OFBIZ-6431
 URL: https://issues.apache.org/jira/browse/OFBIZ-6431
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk
 Environment: 
 http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail
Reporter: Forrest Rae

 I cloned this bug, since I couldn't reopen.  Create a quote with items and a 
 QuoteTerm, and try sending the quote by email.  When you try to send the 
 report via email, you'll get a NullPointerException.  I traced this done to 
 the fact that ListQuoteInfo use a screenlet.  
 org.ofbiz.widget.screen.ModelScreenWidget.Screenlet.renderWidgetString() 
 calls org.ofbiz.widget.html.HtmlScreenRenderer.renderScreenletBegin() which 
 calls org.ofbiz.base.util.UtilHttp.isJavaScriptEnabled().  The exception is 
 thrown because there is no Request or Response context, as these screens are 
 being generated via a service call.
 ===
 Error on Sending confirm email from newly created quote
 http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail
 The Following Errors Occurred:
 Error rendering screen for email: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null)) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null))) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null)) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: 
 org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null) (Error rendering screen 
 [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: 
 java.lang.NullPointerException (null



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6360) Form widget rendering broken for EmailServices.java


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

Forrest Rae updated OFBIZ-6360:
---
Attachment: OFBIZ-6360-release13.07.patch

I attached a patch for release13.07.  Please updated the affected versions to 
also 14.12, and 13.07.

 Form widget rendering broken for EmailServices.java
 ---

 Key: OFBIZ-6360
 URL: https://issues.apache.org/jira/browse/OFBIZ-6360
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Christian Carlow
 Fix For: Trunk

 Attachments: OFBIZ-6360-release13.07.patch, OFBIZ-6360.patch


 Currently only FTL files are rendered by EmailServices.java because 
 formStringRenderer is null for 
 HtmlScreenRenderer.java#renderScreenletSubWidget which is supposed to be 
 extracted from the context parameter, previously from the request parameter, 
 which never exists for the emailing service.  This issue was encountered when 
 testing the sendQuoteReportMail service for the form widget that replaced the 
 FTL for OFBIZ-6349.  
 EmailServices.java is still using the deprecated HtmlScreenRenderer and 
 FoScreenRenderer which should both be replaced by MacroScreenRenderer.  This 
 made me realize I left out the new header rendering functionality for patch 
 OFBIZ-6354 for these two deprecated classes which probably need to be 
 provided along with the existing patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae commented on OFBIZ-6312:


I don't believe so.  TextArea is used when the input can be large.  No reason 
to apply defaults across everything.  In my case, when creating new product 
content, I just wanted the HTML TextArea to reflect the limitations by the 
database field size.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
Assignee: Michael Brohl
 Fix For: Trunk

 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae commented on OFBIZ-6312:


I don't believe so.  TextArea is used when the input can be large.  No reason 
to apply defaults across everything.  In my case, when creating new product 
content, I just wanted the HTML TextArea to reflect the limitations by the 
database field size.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
Assignee: Michael Brohl
 Fix For: Trunk

 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae updated OFBIZ-6312:
---
Comment: was deleted

(was: I don't believe so.  TextArea is used when the input can be large.  No 
reason to apply defaults across everything.  In my case, when creating new 
product content, I just wanted the HTML TextArea to reflect the limitations by 
the database field size.)

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
Assignee: Michael Brohl
 Fix For: Trunk

 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae commented on OFBIZ-6312:


1.  I think this was a copy/paste error.  I was following the format of the 
code in the TextField class to guide me in adding the necessary code to the 
TextareaField.  It should be:
{code:java}
Debug.logError(Could not parse the max-length value of the 
text element: [ + maxlengthStr
+ ], setting to null; default of no maxlength will 
be used, module);
{code}

2.  Not sure, that same code exists for TextArea class as well.  Perhaps both 
areas (and others) need improvement.

3.  Yea, probably a better Exception to catch.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
Assignee: Michael Brohl
 Fix For: Trunk

 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

2015-05-05 Thread Forrest Rae (JIRA)

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

Forrest Rae commented on OFBIZ-6207:

I looked around on the wiki for guidelines on creating bugs/patches but didn't
see anything. Is there guidelines on patch creation that I'm just not seeing?

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Assignee: Deepak Dixit
Priority: Critical
Labels: security
Fix For: 14.12.01, 13.07.02, Upcoming Branch

Attachments: OFBIZ-6207-fourth-attempt.patch

This is a security bug in the ecommerce application. Anyone can view any
quote or request in the system regardless of the associated partyId. They
can do this via URL parameter manipulation.
Reproduction:
1) Login to the ecommerce application as DemoCustomer.
2) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
to view your own request.
3) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
to view DemoCustAgent's request.
4) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
to view DemoCustomer2's request.
Same goes for Quotes, although there are no quotes in the Demo data. The
attach patch fixes this issue.
Would like this issue back ported to release 13.07 please.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

2015-05-05 Thread Forrest Rae (JIRA)

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

Forrest Rae commented on OFBIZ-6207:

I've read that and don't see anything about splitting patches into multiple
files, unless I'm blind (there is always that possibility :P ). If you'd like
me to do that, I will. I'll also update the wiki with instructions once I've
been through the process.

Anyone can view any Request or Quote

Attachments: OFBIZ-6207-fourth-attempt.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-04 Thread Forrest Rae (JIRA)


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

Forrest Rae commented on OFBIZ-6323:


Fair enough.  Thanks!

 LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than 
 all the price types
 -

 Key: OFBIZ-6323
 URL: https://issues.apache.org/jira/browse/OFBIZ-6323
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
 14.12.01
Reporter: Forrest Rae
Assignee: Jacques Le Roux
 Attachments: OFBIZ-6323.patch


 The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen 
 that is used for more advanced product queries.  The results of the request 
 display all the different price types configured for a product  This is 
 confusing for the user when adding an item to a quote.  The attached patch 
 adds additional conditionalFields to the search criteria.
 I've searched the code base for areas where this change might adversely 
 affect usability and didn't see any cases of that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-02 Thread Forrest Rae (JIRA)

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

Forrest Rae edited comment on OFBIZ-6323 at 5/2/15 4:59 PM:

This thing operates in two different modes. When you're adding an item to a
quote, if you type two characters in to the productId field of the search form,
a javascript event will fire that calls LookupProductPrice view with a URL
parameter ajaxLookup set to true (Watch it in the Webtools in Chrome, on the
Network tab). This condition gets checked in the LookupDecorator, and if true,
calls back to the fail-widget, which decorates the response as ajax. Now, if
you click the little box to the right of the productId field, you're presented
with a full search form where you can select from the different available
critera, including the different productPriceType(s). I hope that makes sense.

was (Author: f...@14x.net):
This thing operates in two different modes. When you're adding an item to a
quote, if you type two characters in to the productId field of the search form,
a javascript event will fire that calls LookupProductPrice view with an
ajaxLookup set to true. This condition gets checked in the LookupDecorator,
and if true, calls back to the fail-widget, which decorates the response as
ajax. Now, if you click the little box to the right of the productId field,
you're presented with a full search form where you can select from the
different available critera, including the different productPriceType(s). I
hope that makes sense.

LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than
all the price types
-

Key: OFBIZ-6323
URL: https://issues.apache.org/jira/browse/OFBIZ-6323
Project: OFBiz
Issue Type: Bug
Components: product
Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk,
14.12.01
Reporter: Forrest Rae
Attachments: OFBIZ-6323.patch

The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen
that is used for more advanced product queries. The results of the request
display all the different price types configured for a product This is
confusing for the user when adding an item to a quote. The attached patch
adds additional conditionalFields to the search criteria.
I've searched the code base for areas where this change might adversely
affect usability and didn't see any cases of that.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-02 Thread Forrest Rae (JIRA)

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

Forrest Rae commented on OFBIZ-6323:

This thing operates in two different modes. When you're adding an item to a
quote, if you type two characters in to the productId field of the search form,
a javascript event will fire that calls LookupProductPrice view with an
ajaxLookup set to true. This condition gets checked in the LookupDecorator,
and if true, calls back to the fail-widget, which decorates the response as
ajax. Now, if you click the little box to the right of the productId field,
you're presented with a full search form where you can select from the
different available critera, including the different productPriceType(s). I
hope that makes sense.

LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than
all the price types
-

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-02 Thread Forrest Rae (JIRA)

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

Forrest Rae edited comment on OFBIZ-6323 at 5/2/15 5:00 PM:

This thing operates in two different modes. When you're adding an item to a
quote, if you type two characters in to the productId field of the search form,
a javascript event will fire that calls LookupProductPrice view with a URL
parameter ajaxLookup set to true (Watch it in the Webtools in Chrome, on the
Network tab). This parameter gets checked in the condition portion of the
LookupDecorator, and if true, skips the widget and goes right to the
fail-widget, which decorates the response as ajax. Now, if you click the
little box to the right of the productId field, you're presented with a full
search form where you can select from the different available critera,
including the different productPriceType(s). I hope that makes sense.

was (Author: f...@14x.net):
This thing operates in two different modes. When you're adding an item to a
quote, if you type two characters in to the productId field of the search form,
a javascript event will fire that calls LookupProductPrice view with a URL
parameter ajaxLookup set to true (Watch it in the Webtools in Chrome, on the
Network tab). This condition gets checked in the LookupDecorator, and if true,
calls back to the fail-widget, which decorates the response as ajax. Now, if
you click the little box to the right of the productId field, you're presented
with a full search form where you can select from the different available
critera, including the different productPriceType(s). I hope that makes sense.

LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than
all the price types
-

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-01 Thread Forrest Rae (JIRA)

Forrest Rae created OFBIZ-6323:
--

 Summary: LookupProductAndPrice ajaxLookup should only return 
DEFAULT_PRICE rather than all the price types
 Key: OFBIZ-6323
 URL: https://issues.apache.org/jira/browse/OFBIZ-6323
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 
14.12.01
Reporter: Forrest Rae


The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen 
that is used for more advanced product queries.  The results of the request 
display all the different price types configured for a product  This is 
confusing for the user when adding an item to a quote.  The attached patch adds 
additional conditionalFields to the search criteria.

I've searched the code base for areas where this change might adversely affect 
usability and didn't see any cases of that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types

2015-05-01 Thread Forrest Rae (JIRA)


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

Forrest Rae updated OFBIZ-6323:
---
Attachment: OFBIZ-6323.patch

 LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than 
 all the price types
 -

 Key: OFBIZ-6323
 URL: https://issues.apache.org/jira/browse/OFBIZ-6323
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
 14.12.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6323.patch


 The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen 
 that is used for more advanced product queries.  The results of the request 
 display all the different price types configured for a product  This is 
 confusing for the user when adding an item to a quote.  The attached patch 
 adds additional conditionalFields to the search criteria.
 I've searched the code base for areas where this change might adversely 
 affect usability and didn't see any cases of that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager

Forrest Rae created OFBIZ-6311:
--

 Summary: Order Manager ViewQuote screen should display party name 
and link to party manager
 Key: OFBIZ-6311
 URL: https://issues.apache.org/jira/browse/OFBIZ-6311
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: 13.07.01, 12.04.05, Trunk
Reporter: Forrest Rae


As a convenience, and to match the other applications, Order Manager ViewQuote 
screen should display party name and link to party manager.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager


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

Forrest Rae updated OFBIZ-6311:
---
Attachment: OFBIZ-6311.patch

Patch to include the party name and link to Party Manager.  Might need some 
minor improvements to match the other applications.

 Order Manager ViewQuote screen should display party name and link to party 
 manager
 --

 Key: OFBIZ-6311
 URL: https://issues.apache.org/jira/browse/OFBIZ-6311
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
  Labels: patch
 Attachments: OFBIZ-6311.patch


 As a convenience, and to match the other applications, Order Manager 
 ViewQuote screen should display party name and link to party manager.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager


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

Forrest Rae updated OFBIZ-6311:
---
Affects Version/s: Release Branch 14.12

 Order Manager ViewQuote screen should display party name and link to party 
 manager
 --

 Key: OFBIZ-6311
 URL: https://issues.apache.org/jira/browse/OFBIZ-6311
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
  Labels: patch
 Attachments: OFBIZ-6311.patch


 As a convenience, and to match the other applications, Order Manager 
 ViewQuote screen should display party name and link to party manager.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae commented on OFBIZ-6312:


I will need to also supply a patch for the Product Duplication form at the 
bottom of the screen as well.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box.  When more than 255 
 characters are entered an error is displayed.  There is no easy way of 
 knowing when you've hit the 255 character max without the HTML limiting it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae updated OFBIZ-6312:
---
Attachment: OFBIZ-6312.patch

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box.  When more than 255 
 characters are entered an error is displayed.  There is no easy way of 
 knowing when you've hit the 255 character max without the HTML limiting it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box

Forrest Rae created OFBIZ-6312:
--

 Summary: Catalog Manager's EditProduct screen HTML should place a 
limit on the size of text that can be entered in the Product Description box
 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: 13.07.01, 12.04.05, Trunk, Release Branch 14.12
Reporter: Forrest Rae


Catalog Manager's EditProduct screen HTML should place a limit on the size of 
text that can be entered in the Product Description box.  When more than 255 
characters are entered an error is displayed.  There is no easy way of knowing 
when you've hit the 255 character max without the HTML limiting it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae updated OFBIZ-6312:
---
Attachment: OFBIZ-6312.patch

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box

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

Forrest Rae updated OFBIZ-6312:
---
Description:
Catalog Manager's EditProduct and EditProductDup screens HTML should place a
limit on the size of text that can be entered in the Product Description box.
When more than 255 characters are entered an error is displayed. There is no
easy way of knowing when you've hit the 255 character max without the HTML
limiting it.

The patch I'm including changes the TextArea to include the maxlength argument.

was:Catalog Manager's EditProduct screen HTML should place a limit on the
size of text that can be entered in the Product Description box. When more
than 255 characters are entered an error is displayed. There is no easy way of
knowing when you've hit the 255 character max without the HTML limiting it.

Catalog Manager's EditProduct screen HTML should place a limit on the size of
text that can be entered in the Product Description box
-

Key: OFBIZ-6312
URL: https://issues.apache.org/jira/browse/OFBIZ-6312
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
Attachments: OFBIZ-6312.patch

Catalog Manager's EditProduct and EditProductDup screens HTML should place a
limit on the size of text that can be entered in the Product Description box.
When more than 255 characters are entered an error is displayed. There is
no easy way of knowing when you've hit the 255 character max without the HTML
limiting it.
The patch I'm including changes the TextArea to include the maxlength
argument.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae updated OFBIZ-6312:
---
Comment: was deleted

(was: I will need to also supply a patch for the Product Duplication form at 
the bottom of the screen as well.)

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box

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

The patch I'm including changes the TextArea to include the maxlength argument.
This should be useful in other areas of the system.

was:
Catalog Manager's EditProduct and EditProductDup screens HTML should place a
limit on the size of text that can be entered in the Product Description box.
When more than 255 characters are entered an error is displayed. There is no
easy way of knowing when you've hit the 255 character max without the HTML
limiting it.

The patch I'm including changes the TextArea to include the maxlength argument.

Catalog Manager's EditProduct screen HTML should place a limit on the size of
text that can be entered in the Product Description box
-

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:51 AM:
-

OFBIZ-6312.patch won't work against any other releases except trunk.  
Backporting is proving to be a pain.  It's not to hard on 14.10, but does 
require manual effort.  I imagine 13.07 will be the same.


was (Author: f...@14x.net):
OFBIZ-6312.patch won't work against release13.07 branch.  It will need a 
different patch.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae updated OFBIZ-6312:
---
Attachment: (was: OFBIZ-6312.patch)

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box.  When more than 255 
 characters are entered an error is displayed.  There is no easy way of 
 knowing when you've hit the 255 character max without the HTML limiting it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box


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

Forrest Rae commented on OFBIZ-6312:


OFBIZ-6312.patch won't work against release13.07 branch.  It will need a 
different patch.

 Catalog Manager's EditProduct screen HTML should place a limit on the size of 
 text that can be entered in the Product Description box
 -

 Key: OFBIZ-6312
 URL: https://issues.apache.org/jira/browse/OFBIZ-6312
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
Reporter: Forrest Rae
 Attachments: OFBIZ-6312.patch


 Catalog Manager's EditProduct and EditProductDup screens HTML should place a 
 limit on the size of text that can be entered in the Product Description box. 
  When more than 255 characters are entered an error is displayed.  There is 
 no easy way of knowing when you've hit the 255 character max without the HTML 
 limiting it.
 The patch I'm including changes the TextArea to include the maxlength 
 argument.  This should be useful in other areas of the system.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box

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

Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:53 AM:
-

OFBIZ-6312.patch won't work against any other releases except trunk.
Backporting is proving to be a pain. It's not to hard on 14.10, but does
require manual effort. 13.07 will be harder as the same files don't exist, and
it looks like the Widget framework was revamped between 13.07 and 14.10.

was (Author: f...@14x.net):
OFBIZ-6312.patch won't work against any other releases except trunk.
Backporting is proving to be a pain. It's not to hard on 14.10, but does
require manual effort. I imagine 13.07 will be the same.

Catalog Manager's EditProduct screen HTML should place a limit on the size of
text that can be entered in the Product Description box
-

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

Adrian, Can you point me to an example and I'll take a look?

Anyone can view any Request or Quote

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae updated OFBIZ-6207:
---
Attachment: OFBIZ-6207-fourth-attempt.patch

Fourth patch uses condition tag as suggested by Deepak.

Anyone can view any Request or Quote

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae updated OFBIZ-6207:
---
Attachment: (was: OFBIZ-6207-third-attempt.patch)

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Assignee: Deepak Dixit
Priority: Critical
  Labels: security

 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.
 Would like this issue back ported to release 13.07 please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

If I wanted to leverage permission services in Request/Quote services such as
custRequestPermissionCheck, it seems I would need to pass in a fromPartyId
argument, but can't seem to figure out how to do that:

if-service-permission service-name=custRequestPermissionCheck
fromPartyId=CustRequest.fromPartyId/

errors:

Error message: cvc-complex-type.3.2.2: Attribute 'fromPartyId' is not allowed
to appear in element 'if-service-permission'.

Anyone can view any Request or Quote

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

I got it working using this suggestion, which I agree is much cleaner than
dropping down to groovy via the 'set tag.

Anyone can view any Request or Quote

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

Thanks Adrian. I explored this quite a bit. The whole framework looks geared
to Application level permissions rather than what I'm trying to address, which
is entity level access control.

Anyone can view any Request or Quote

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae updated OFBIZ-6207:
---
Attachment: OFBIZ-6207.patch

Fixes issue.

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk
Reporter: Forrest Rae
Priority: Critical
  Labels: security
 Attachments: OFBIZ-6207.patch


 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6207) Anyone can view any Request or Quote

Forrest Rae created OFBIZ-6207:
--

 Summary: Anyone can view any Request or Quote
 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk
Reporter: Forrest Rae
Priority: Critical
 Attachments: OFBIZ-6207.patch

This is a security bug in the ecommerce application.  Anyone can view any quote 
or request in the system regardless of the associated partyId.  They can do 
this via URL parameter manipulation.

Reproduction:
1) Login to the ecommerce application as DemoCustomer.
2) Navigate to 
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
 to view your own request.
3) Navigate to 
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
 to view DemoCustAgent's request.
4) Navigate to 
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
 to view DemoCustomer2's request.

Same goes for Quotes, although there are no quotes in the Demo data.  The 
attach patch fixes this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae updated OFBIZ-6207:
---
Description:
This is a security bug in the ecommerce application. Anyone can view any quote
or request in the system regardless of the associated partyId. They can do
this via URL parameter manipulation.

Reproduction:
1) Login to the ecommerce application as DemoCustomer.
2) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
to view your own request.
3) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
to view DemoCustAgent's request.
4) Navigate to
http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
to view DemoCustomer2's request.

Same goes for Quotes, although there are no quotes in the Demo data. The
attach patch fixes this issue.

Would like this issue back ported to release 13.07 please.

was:
This is a security bug in the ecommerce application. Anyone can view any quote
or request in the system regardless of the associated partyId. They can do
this via URL parameter manipulation.

Same goes for Quotes, although there are no quotes in the Demo data. The
attach patch fixes this issue.

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

Honestly, I am a bit lost as to why this isn't working against 13.07. I didn't
intend to have a patch for each.

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae updated OFBIZ-6207:
---
Attachment: OFBIZ-6207-third-attempt.patch

Third attempt at a patch that works in both Trunk and 13.07. I believe this
one is final.

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207-third-attempt.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae updated OFBIZ-6207:
---
Attachment: (was: OFBIZ-6207-second-attempt.patch)

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
  Labels: security
 Attachments: OFBIZ-6207-third-attempt.patch


 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.
 Would like this issue back ported to release 13.07 please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae updated OFBIZ-6207:
---
Attachment: (was: OFBIZ-6207.patch)

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
  Labels: security
 Attachments: OFBIZ-6207-third-attempt.patch


 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.
 Would like this issue back ported to release 13.07 please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae commented on OFBIZ-6207:


Although, when applied to the 13.07 branch, it seems to cause an error.  
Strange because it works great applied to Trunk.

 [java] 2015-03-24 18:06:22,012 |-0.0.0.0-8443-exec-3 |PrimaryKeyFinder 
 |E| Error finding entity value by primary key with entity-one: 
org.ofbiz.entity.GenericModelException: [GenericDelegator.findOne] Passed 
primary key is not a valid primary key: 
[GenericEntity:CustRequest][custRequestId,9000(java.lang.String)][fromPartyId,DemoCustomer(java.lang.String)]
 [java] org.ofbiz.entity.GenericModelException: [GenericDelegator.findOne] 
Passed primary key is not a valid primary key: 
[GenericEntity:CustRequest][custRequestId,9000(java.lang.String)][fromPartyId,DemoCustomer(java.lang.String)]
 [java] at 
org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1483) 
~[ofbiz-entity.jar:?]
 [java] at 
org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:154) 
[ofbiz-entity.jar:?]
 [java] at 
org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:86) 
[ofbiz-entity.jar:?]
 [java] at 
org.ofbiz.widget.ModelWidgetAction$EntityOne.runAction(ModelWidgetAction.java:511)
 [ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.ModelWidgetAction.runSubActions(ModelWidgetAction.java:114) 
[ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:186)
 [ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:396) 
[ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:135) 
[ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:97) 
[ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.widget.screen.MacroScreenViewHandler.render(MacroScreenViewHandler.java:104)
 [ofbiz-widget.jar:?]
 [java] at 
org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:916) 
[ofbiz-webapp.jar:?]
 [java] at 
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:614) 
[ofbiz-webapp.jar:?]
 [java] at 
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:218) 
[ofbiz-webapp.jar:?]

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
  Labels: security
 Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch


 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.
 Would like this issue back ported to release 13.07 please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

So, in 13.07, entity-one in the widget will call GenericDelegator.findOne().
This checks that you're only using primary keys for the search. My patch seems
to cause a problem as it was using partyId as part of the search criteria.
partyId is not a PK of Quote.

What is the recommended way of checking the Quote.partyId field to make sure it
matches userLogin.partyId in the actions section of the
specialpurpose/ecommerce/widget/QuoteScreens.xml#ViewQuote screen?

None of this matters in Trunk as the entity-one in the screen never results
in a call to GenericDelegator.findOne().

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote


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

Forrest Rae updated OFBIZ-6207:
---
Affects Version/s: 13.07.01

 Anyone can view any Request or Quote
 

 Key: OFBIZ-6207
 URL: https://issues.apache.org/jira/browse/OFBIZ-6207
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
  Labels: security
 Attachments: OFBIZ-6207.patch


 This is a security bug in the ecommerce application.  Anyone can view any 
 quote or request in the system regardless of the associated partyId.  They 
 can do this via URL parameter manipulation.
 Reproduction:
 1) Login to the ecommerce application as DemoCustomer.
 2) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000
  to view your own request.
 3) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001
  to view DemoCustAgent's request.
 4) Navigate to 
 http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002
  to view DemoCustomer2's request.
 Same goes for Quotes, although there are no quotes in the Demo data.  The 
 attach patch fixes this issue.
 Would like this issue back ported to release 13.07 please.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae commented on OFBIZ-6207:

Turns out my patch isn't correct. The location of the condition in the
ViewRequest screen is out of place. Please don't apply yet.

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote

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

Forrest Rae updated OFBIZ-6207:
---
Attachment: OFBIZ-6207-second-attempt.patch

I just attached OFBIZ-6207-second-attempt.patch. This patch should work
cleaner.

Anyone can view any Request or Quote

Key: OFBIZ-6207
URL: https://issues.apache.org/jira/browse/OFBIZ-6207
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: Trunk, 13.07.01
Reporter: Forrest Rae
Priority: Critical
Labels: security
Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote