ofbiz-framework

Clone Tools
  • last updated 15 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates

Changeset {id} does not exist.

Fixed: correct path to ftpAddress services (OFBIZ-11359)

After the minilang ContactMarchServices.xml to groovy, I forgot to change

the path of existant ftpAddress services already present before.

Thanks to Olivier Heintz for this alert

Fixed: correct path to ftpAddress services (OFBIZ-11359)

After the minilang ContactMarchServices.xml to groovy, I forgot to change

the path of existant ftpAddress services already present before.

Thanks to Olivier Heintz for this alert

Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

Improved: Improve Web Content Caching

(OFBIZ-11477)

According to OWASP OFBiz Web Content Caching is weak:

Independently of the cache policy defined by the web application, if caching web

application contents is allowed, the session IDs must never be cached, so it is

highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2"

directive, to allow web clients to cache everything except the session ID

I though noticed that Set-Cookie2 is deprecated for a long time now. And we new

browsers policies it to often updated. So no need to use Set-Cookie2.

Improved: Improve Web Content Caching

(OFBIZ-11477)

According to OWASP OFBiz Web Content Caching is weak:

Independently of the cache policy defined by the web application, if caching web

application contents is allowed, the session IDs must never be cached, so it is

highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2"

directive, to allow web clients to cache everything except the session ID

I though noticed that Set-Cookie2 is deprecated for a long time now. And we new

browsers policies it to often updated. So no need to use Set-Cookie2.

Improved: Improve Web Content Caching

(OFBIZ-11477)

According to OWASP OFBiz Web Content Caching is weak:

Independently of the cache policy defined by the web application, if caching web

application contents is allowed, the session IDs must never be cached, so it is

highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2"

directive, to allow web clients to cache everything except the session ID

I though noticed that Set-Cookie2 is deprecated for a long time now. And we new

browsers policies it to often updated. So no need to use Set-Cookie2.

Improved: type="text/css" was missing on a call to <<link rel="stylesheet/less>>

This was reported by OWASP ZAP: "The Content-Type header is missing or empty."

Considered a low vulnerability

Improved: Implement the pretty print for keyword search

(OFBIZ-11476)

With OFBIZ-9164 and r1835891 I introduced

keywordConstraint::prettyPrintConstraint without implementation.

So the information is missing at top of page.

This implements it. It also amends 2 French labels

    • -2
    • +2
    /applications/product/config/ProductUiLabels.xml
Improved: no functional change

Adds /uploads/ in .runtime/.gitignore

Fixed: DataModel - correct foreign key (#51)

(OFBIZ-11474)

Renaming foreign key to PROD_PRCDE_OPCD

Fixed: Specified key was too long; max key length is 767 bytes for ProductPromoCodeEmail entity.(OFBIZ-5426) (#44)

* Fixed: Specified key was too long; max key length is 767 bytes for ProductPromoCodeEmail entity.

(OFBIZ-5426)

The problem is in the entity model. An email address should not be used in the primary key - mainly because an email address is case-insensitive. A better design would be to use the email address contact mechanism ID in the primary key.

Done Following:

1. Changed Entity Name from ProductPromoCodeEmail to ProductPromoCodeContMech

2. Related Changes for the entity name change

3. Migration service to migrate old data

Thanks, Leon for the report and Adrian Crum, Jacques Le Roux, Ingo Wolfmayr, Deepak Dixit, Pierre Smits and Gil Portenseigne for the discussion and review.

* Improved: Added new line in service definition file and lincence in MigrationServices file.

(OFBIZ-5426)

Thanks, Jacopo for the review.

    • -0
    • +1
    /applications/product/ofbiz-component.xml
    • -0
    • +32
    /applications/product/servicedef/services_migration.xml
Improved: Added unit testing, using JMockit, to ensure that form macros are rendered using ids from ModelFormField#getCurrentContainerId.

(OFBIZ-4035)

Fixes check style errors

Improved: Added unit testing, using JMockit, to ensure that form macros are rendered using ids from ModelFormField#getCurrentContainerId.

(OFBIZ-4035)

Fixes an issue due to Eclipse automated import organisation.

There are still check style errors

Improved: Added unit testing, using JMockit, to ensure that form macros are rendered using ids from ModelFormField#getCurrentContainerId.

(OFBIZ-4035)

Fixes a check issue (line too long)

Notice: on Windows I get 20 errors when compiling:

> Task :compileTestJava FAILED

C:\projectsASF\Git\ofbiz-framework\framework\widget\src\test\java\org\apache\

ofbiz\widget\renderer\macro\MacroFormRendererTest.java:134:

error: annotation type not applicable to this kind of declaration

@Mock

^

I guess the change in build.gradle are not enough for Windows, to be seen later...

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

Fixes a typo

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

It's better to allow users to change from strict to lax, at least for all

cookies. Some could want to change it by cookie type. I let the exercise for

them :)

See:https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

It's better to allow users to change from strict to lax, at least for all

cookies. Some could want to change it by cookie type. I let the exercise for

them :)

See:https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

It's better to allow users to change from strict to lax, at least for all

cookies. Some could want to change it by cookie type. I let the exercise for

them :)

See:https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60

Conflicts handled by hand

framework/security/config/security.properties

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

Forgot to add UtilHttp::SameSiteFilter

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

    • -0
    • +6
    /framework/resources/templates/web.xml
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

Forgot to add UtilHttp::SameSiteFilter

Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

    • -0
    • +6
    /framework/resources/templates/web.xml
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

    • -0
    • +6
    /framework/resources/templates/web.xml
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

Forgot to add UtilHttp::SameSiteFilter

Improved: no functional change

Adds "Content-Security-Policy" frame-ancestors="self" in ErrorPage.ftl

Because this page is used as a HTTP 500 error it's more susceptible to

clickjacking

Quoting OWASP ZAP:

This problem still applies to error-type pages (401, 403, 500, etc.), as these

pages are still often affected by injection problems, in which case it is still

possible that browsers may interpret pages differently from their actual content

type.

I tried to work on other file types that were also reported but it's complicated

adn I believe it's not worth it

Improved: no functional change

Adds "Content-Security-Policy" frame-ancestors="self" in ErrorPage.ftl

Because this page is used as a HTTP 500 error it's more susceptible to

clickjacking

Quoting OWASP ZAP:

This problem still applies to error-type pages (401, 403, 500, etc.), as these

pages are still often affected by injection problems, in which case it is still

possible that browsers may interpret pages differently from their actual content

type.

I tried to work on other file types that were also reported but it's complicated

adn I believe it's not worth it

Improved: no functional change

Adds "Content-Security-Policy" frame-ancestors="self" in ErrorPage.ftl

Because this page is used as a HTTP 500 error it's more susceptible to

clickjacking

Quoting OWASP ZAP:

This problem still applies to error-type pages (401, 403, 500, etc.), as these

pages are still often affected by injection problems, in which case it is still

possible that browsers may interpret pages differently from their actual content

type.

I tried to work on other file types that were also reported but it's complicated

adn I believe it's not worth it

Fixed: Propagate the theme in DataResourceWorker.renderDataResourceAsText() Improved: no functional change

(OFBIZ-9923)

Seems that this has been fixed with OFBIZ-11466 "CommonTheme has a dependency on

Flatgrey application.js"

Thanks: Pierre Smits for the fix in OFBIZ-11466