Re: svn commit: r1536324
Hi, If you want to test it's ready. I should commit in a week... All feedback is appreciated Jacques Le 15/05/2019 à 18:43, Jacques Le Roux a écrit : Hi Scott, Jacopo, All, I have finally reopened OFBIZ-5254 as I propose a solution for this issue in a new patch. checkStringForHtmlSafeOnly() is still a WIP and can be improved, fortunately by using extendible policies Jacques Le 03/09/2016 à 11:27, Jacopo Cappellato a écrit : I am resurrecting this old thread, because I think that Scott's remarks and concerns to Jacques' commit were valid and the response of Jacques was not satisfactory: in fact the two tickets Jacques mentioned have been resolved but the issues that Scott identified in Jacques' commit are still there. We should consider reverting the commit but my post for now is as a reminder and to restart the conversation. Jacopo On Sat, Dec 28, 2013 at 12:54 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: That's why https://issues.apache.org/jira/browse/OFBIZ-5254 is not closed, just resolved as incomplete. In other word it's a temporary unsatisfying solution. The idea is to continue https://issues.apache.org/jira/browse/OFBIZ-5343 All good wills are welcome Jacques On Friday, December 27, 2013 11:20 PM scott.g...@hotwaxmedia.com wrote "safe" should not have been deprecated. The input should have just been cleansed as an interim measure until a better solution could be found. Regards Scott On 27/12/2013, at 9:37 PM, Jacques Le Roux wrote: I agree, it's in my long TODO list... Jacques On Friday, December 27, 2013 8:43 PM scott.g...@hotwaxmedia.com wrote This is not a fix, the problem was that "safe" wasn't filtering unsafe html or returning an error. Taking all "safe" input parameters and making them "any" because "safe" wasn't working as intended is a bit silly to say the least. Regards Scott On 28/10/2013, at 12:12 PM, jler...@apache.org wrote: Author: jleroux Date: Mon Oct 28 12:12:43 2013 New Revision: 1536324 URL: http://svn.apache.org/r1536324 Log: Fixes < set to "safe">> https://issues.apache.org/jira/browse/OFBIZ-5254 After r751990, <> and <> are the same: they do nothing! The only difference is the warning message from the OWASP Antisamy IntrusionDetector, which is both, as Christoph noted "giving you a false sense of security" or as I wrote "disturbing, wrong and useless". So there are no longer any reasons for differencing "safe" and "any". This * Deprecates "safe" (making it clear in the XSD documentation), keeping only "none" and "any". This is for backward compatibility, else we could completely remove the misleading "safe". Note that "none" is the default. * Replaces in services definition all allow-html="safe" by allow-html="any" * Remove from ModelService.java (near line 587) the code which throws the OWASP Antisamy IntrusionDetector message in log Modified: ofbiz/trunk/applications/accounting/servicedef/ services_agreement.xml ofbiz/trunk/applications/accounting/servicedef/services_invoice.xml ofbiz/trunk/applications/content/servicedef/services.xml ofbiz/trunk/applications/content/servicedef/services_content.xml ofbiz/trunk/applications/content/servicedef/services_data.xml ofbiz/trunk/applications/marketing/servicedef/services_ opportunity.xml ofbiz/trunk/applications/order/servicedef/services.xml ofbiz/trunk/applications/order/servicedef/services_quote.xml ofbiz/trunk/applications/order/servicedef/services_request.xml ofbiz/trunk/applications/party/servicedef/services.xml ofbiz/trunk/applications/product/servicedef/services.xml ofbiz/trunk/applications/product/servicedef/services_pricepromo.xml ofbiz/trunk/applications/workeffort/servicedef/services.xml ofbiz/trunk/framework/common/servicedef/services.xml ofbiz/trunk/framework/common/servicedef/services_email.xml ofbiz/trunk/framework/service/dtd/services.xsd ofbiz/trunk/framework/service/src/org/ofbiz/service/ ModelService.java ofbiz/trunk/specialpurpose/ebaystore/servicedef/services.xml Modified: ofbiz/trunk/applications/accounting/servicedef/ services_agreement.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/ accounting/servicedef/services_agreement.xml?rev= 1536324=1536323=1536324=diff == --- ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml Mon Oct 28 12:12:43 2013 @@ -30,7 +30,7 @@ under the License. main-action="CREATE"/> - + engine="simple" location="component://accounting/script/org/ofbiz/ accounting/agreement/AgreementServices.xml" invoke="updateAgreement" auth="true"> @@ -38,7 +38,7 @@ under the License. main-action="UPDATE"/> - + engine="simple" location="component://accounting/script/org/ofbiz/
Re: svn commit: r1536324
Hi Scott, Jacopo, All, I have finally reopened OFBIZ-5254 as I propose a solution for this issue in a new patch. checkStringForHtmlSafeOnly() is still a WIP and can be improved, fortunately by using extendible policies Jacques Le 03/09/2016 à 11:27, Jacopo Cappellato a écrit : I am resurrecting this old thread, because I think that Scott's remarks and concerns to Jacques' commit were valid and the response of Jacques was not satisfactory: in fact the two tickets Jacques mentioned have been resolved but the issues that Scott identified in Jacques' commit are still there. We should consider reverting the commit but my post for now is as a reminder and to restart the conversation. Jacopo On Sat, Dec 28, 2013 at 12:54 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: That's why https://issues.apache.org/jira/browse/OFBIZ-5254 is not closed, just resolved as incomplete. In other word it's a temporary unsatisfying solution. The idea is to continue https://issues.apache.org/jira/browse/OFBIZ-5343 All good wills are welcome Jacques On Friday, December 27, 2013 11:20 PM scott.g...@hotwaxmedia.com wrote "safe" should not have been deprecated. The input should have just been cleansed as an interim measure until a better solution could be found. Regards Scott On 27/12/2013, at 9:37 PM, Jacques Le Roux wrote: I agree, it's in my long TODO list... Jacques On Friday, December 27, 2013 8:43 PM scott.g...@hotwaxmedia.com wrote This is not a fix, the problem was that "safe" wasn't filtering unsafe html or returning an error. Taking all "safe" input parameters and making them "any" because "safe" wasn't working as intended is a bit silly to say the least. Regards Scott On 28/10/2013, at 12:12 PM, jler...@apache.org wrote: Author: jleroux Date: Mon Oct 28 12:12:43 2013 New Revision: 1536324 URL: http://svn.apache.org/r1536324 Log: Fixes < set to "safe">> https://issues.apache.org/jira/browse/OFBIZ-5254 After r751990, <> and <> are the same: they do nothing! The only difference is the warning message from the OWASP Antisamy IntrusionDetector, which is both, as Christoph noted "giving you a false sense of security" or as I wrote "disturbing, wrong and useless". So there are no longer any reasons for differencing "safe" and "any". This * Deprecates "safe" (making it clear in the XSD documentation), keeping only "none" and "any". This is for backward compatibility, else we could completely remove the misleading "safe". Note that "none" is the default. * Replaces in services definition all allow-html="safe" by allow-html="any" * Remove from ModelService.java (near line 587) the code which throws the OWASP Antisamy IntrusionDetector message in log Modified: ofbiz/trunk/applications/accounting/servicedef/ services_agreement.xml ofbiz/trunk/applications/accounting/servicedef/services_invoice.xml ofbiz/trunk/applications/content/servicedef/services.xml ofbiz/trunk/applications/content/servicedef/services_content.xml ofbiz/trunk/applications/content/servicedef/services_data.xml ofbiz/trunk/applications/marketing/servicedef/services_ opportunity.xml ofbiz/trunk/applications/order/servicedef/services.xml ofbiz/trunk/applications/order/servicedef/services_quote.xml ofbiz/trunk/applications/order/servicedef/services_request.xml ofbiz/trunk/applications/party/servicedef/services.xml ofbiz/trunk/applications/product/servicedef/services.xml ofbiz/trunk/applications/product/servicedef/services_pricepromo.xml ofbiz/trunk/applications/workeffort/servicedef/services.xml ofbiz/trunk/framework/common/servicedef/services.xml ofbiz/trunk/framework/common/servicedef/services_email.xml ofbiz/trunk/framework/service/dtd/services.xsd ofbiz/trunk/framework/service/src/org/ofbiz/service/ ModelService.java ofbiz/trunk/specialpurpose/ebaystore/servicedef/services.xml Modified: ofbiz/trunk/applications/accounting/servicedef/ services_agreement.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/ accounting/servicedef/services_agreement.xml?rev= 1536324=1536323=1536324=diff == --- ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml Mon Oct 28 12:12:43 2013 @@ -30,7 +30,7 @@ under the License. main-action="CREATE"/> - + engine="simple" location="component://accounting/script/org/ofbiz/ accounting/agreement/AgreementServices.xml" invoke="updateAgreement" auth="true"> @@ -38,7 +38,7 @@ under the License. main-action="UPDATE"/> - + engine="simple" location="component://accounting/script/org/ofbiz/ accounting/agreement/AgreementServices.xml" invoke="cancelAgreement" auth="true"> @@ -65,7 +65,7 @@ under
Re: svn commit: r1536324 - in /ofbiz/trunk: applications/accounting/servicedef/ applications/content/servicedef/ applications/marketing/servicedef/ applications/order/servicedef/ applications/party/se
I am resurrecting this old thread, because I think that Scott's remarks and concerns to Jacques' commit were valid and the response of Jacques was not satisfactory: in fact the two tickets Jacques mentioned have been resolved but the issues that Scott identified in Jacques' commit are still there. We should consider reverting the commit but my post for now is as a reminder and to restart the conversation. Jacopo On Sat, Dec 28, 2013 at 12:54 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > That's why https://issues.apache.org/jira/browse/OFBIZ-5254 is not > closed, just resolved as incomplete. In other word it's a temporary > unsatisfying solution. > The idea is to continue https://issues.apache.org/jira/browse/OFBIZ-5343 > All good wills are welcome > > Jacques > > On Friday, December 27, 2013 11:20 PM scott.g...@hotwaxmedia.com wrote > > "safe" should not have been deprecated. The input should have just been > cleansed as an interim measure until a better solution > > could be found. > > > > Regards > > Scott > > > > On 27/12/2013, at 9:37 PM, Jacques Le Roux wrote: > > > >> I agree, it's in my long TODO list... > >> > >> Jacques > >> > >> On Friday, December 27, 2013 8:43 PM scott.g...@hotwaxmedia.com wrote > >>> This is not a fix, the problem was that "safe" wasn't filtering unsafe > html or returning an error. Taking all "safe" input > >>> parameters and making them "any" because "safe" wasn't working as > intended is a bit silly to say the least. > >>> > >>> Regards > >>> Scott > >>> > >>> On 28/10/2013, at 12:12 PM, jler...@apache.org wrote: > >>> > Author: jleroux > Date: Mon Oct 28 12:12:43 2013 > New Revision: 1536324 > > URL: http://svn.apache.org/r1536324 > Log: > Fixes < set to "safe">> > https://issues.apache.org/jira/browse/OFBIZ-5254 > > After r751990,
