[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count

[Jacques Le Roux (Jira)]

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

Jacques Le Roux commented on OFBIZ-10577:
-

HI Pierre,

If you go this way, the assignee can also unassign him-herself ;)

> New Feature: Inventory Cycle Count
> --
>
> Key: OFBIZ-10577
> URL: https://issues.apache.org/jira/browse/OFBIZ-10577
> Project: OFBiz
>  Issue Type: New Feature
>  Components: hhfacility
>Affects Versions: Trunk
>Reporter: Yashwant Dhakad
>Assignee: Yashwant Dhakad
>Priority: Major
> Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, 
> screenshot-1-find-session.png, screenshot-2-pending-locations.png, 
> screenshot-3-add-location-to-session.png, 
> screenshot-4-list-of-review-session.png, 
> screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, 
> screenshot-7-complete-review.png, screenshot-8-report-screen.png
>
>
> *Here are the design notes for cycle count workflow:*
> *Find Session Screen:* In this screen, we will show all the sessions created 
> in the system with respect to the facility, locations, inventory count item, 
> current status, and created date. We have a search field to filter the 
> records on the basis of the facility, status.
> *Find Pending Locations:* In this screen, we have a table listing all the 
> pending locations whose countings are pending and we can create a session for 
> them. All details regarding the pending locations are listed here with the 
> location, next count date, last count date and days extended for the count, 
> total inventory item and product for this location. We have facets for 
> filtering the records on the basis of the facility, not scanned since and 
> scheduled for next scan. Also, we have a global search at the top of the 
> screen. In Pending Locations screen, we have a Create Session button. To 
> create a session we can either select one or more records from the below list 
> or create a new session by yourself.
> In Create Session screen, the basic overview is shown in the "Overview" 
> section and the items are listed in the "Items" section. We can create a new 
> line item by clicking on the 'Add' button and we can also update the item 
> quantity. After completing this, we can proceed with this session and mark it 
> with 'Pending for Review' status from the 'Status' button at the top of the 
> screen or we can simply 'Reject'. 'Reject' status button is available at the 
> top of the screen.
> *Find Review Screen:* In this screen, we have a table listing all the 
> locations pending for the review. All the details regarding the review 
> sessions are listed with the facility, locations and counted inventory item. 
> We have facets for filtering records on the basis of the facility. By 
> clicking any session we can go to its detail screen, where basic details 
> regarding this session are listed in the 'Overview' section and items are 
> listed in the 'Items' section. We can select any number of rows and mark them 
> as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the 
> variance is created and these are added in the Count Progress report. Only 
> authorized persons can accept or reject the sessions and once the session is 
> accepted it is marked as 'Completed'.
> *Count Progress Report:* In this screen, User can view the advanced counting 
> related analytics with respect to all the 'Completed' status session from 
> Reports Screen. We can filter the records on the basis of the facility and 
> within the date range. We can also see the percentage of the total locations, 
> inventory items counted and errors occurred during the process. Item variance 
> details are listed in the below section in tabular form.
> Following changes to the existing data model to support end to end counting 
> process flow:
> *New entities:*
> *InventoryCount*
>    inventoryCountId
>    uploadedByUserLogin
>    facilityId
>    statusId
>    createdDatetime
>  *InventoryCountItem*
>    inventoryCountId
>    inventoryCountItemSeqId
>    inventoryItemId
>    itemStatusId
>    locationSeqId
>    productId
>    productIdentifier
>    quantity
>  *InventoryCountVariance* 
>    inventoryCountId
>    inventoryCountItemSeqId
>    inventoryItemId
>    productId
>    productIdentifier
>    locationSeqId
>    systemQuantityOnHand
>    actualQuantityOnHand
>    varianceQuantityOnHand
>    totalCost
>    actualCost
>    costVariance
>    actualValue
>    totalValue
>    valueVariance
>    unitCost
>  ***Extended entity:*
>  *FacilityLocation*
>    locked
>    lastCountDate
>    nextCountDate
> **We will prevent the following inbound and outbound transactions within the 
> application if the location is locked for counting:
>  Inventory Transfer 
>  Issuance 

[jira] [Closed] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Paul Foxworthy (Jira)]

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

Paul Foxworthy closed OFBIZ-3847.
-
Resolution: Fixed

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Paul Foxworthy (Jira)]

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

Paul Foxworthy reopened OFBIZ-3847:
---

I set resolution to "Cannot Reproduce", but that's misleading because the 
original issue was fixed

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Paul Foxworthy (Jira)]

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

Paul Foxworthy closed OFBIZ-3847.
-
Resolution: Cannot Reproduce

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Paul Foxworthy (Jira)]

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

Paul Foxworthy updated OFBIZ-3847:
--
Fix Version/s: (was: 17.12.01)

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count

[Pierre Smits (Jira)]

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

Pierre Smits commented on OFBIZ-10577:
--

Bonjour [~jleroux],

You are only partially correct. The contribution of the initial contributor of 
this ticket (the author, in Jira parlance the reporter) may end after he/she 
saved the ticket. It is more the obligation/responsibility/task of the assignee 
to take it to the next level.

Luckily in this ticket, both reporter and assignee are the same. I applaud him 
and his willingness to see this through.

 

> New Feature: Inventory Cycle Count
> --
>
> Key: OFBIZ-10577
> URL: https://issues.apache.org/jira/browse/OFBIZ-10577
> Project: OFBiz
>  Issue Type: New Feature
>  Components: hhfacility
>Affects Versions: Trunk
>Reporter: Yashwant Dhakad
>Assignee: Yashwant Dhakad
>Priority: Major
> Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, 
> screenshot-1-find-session.png, screenshot-2-pending-locations.png, 
> screenshot-3-add-location-to-session.png, 
> screenshot-4-list-of-review-session.png, 
> screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, 
> screenshot-7-complete-review.png, screenshot-8-report-screen.png
>
>
> *Here are the design notes for cycle count workflow:*
> *Find Session Screen:* In this screen, we will show all the sessions created 
> in the system with respect to the facility, locations, inventory count item, 
> current status, and created date. We have a search field to filter the 
> records on the basis of the facility, status.
> *Find Pending Locations:* In this screen, we have a table listing all the 
> pending locations whose countings are pending and we can create a session for 
> them. All details regarding the pending locations are listed here with the 
> location, next count date, last count date and days extended for the count, 
> total inventory item and product for this location. We have facets for 
> filtering the records on the basis of the facility, not scanned since and 
> scheduled for next scan. Also, we have a global search at the top of the 
> screen. In Pending Locations screen, we have a Create Session button. To 
> create a session we can either select one or more records from the below list 
> or create a new session by yourself.
> In Create Session screen, the basic overview is shown in the "Overview" 
> section and the items are listed in the "Items" section. We can create a new 
> line item by clicking on the 'Add' button and we can also update the item 
> quantity. After completing this, we can proceed with this session and mark it 
> with 'Pending for Review' status from the 'Status' button at the top of the 
> screen or we can simply 'Reject'. 'Reject' status button is available at the 
> top of the screen.
> *Find Review Screen:* In this screen, we have a table listing all the 
> locations pending for the review. All the details regarding the review 
> sessions are listed with the facility, locations and counted inventory item. 
> We have facets for filtering records on the basis of the facility. By 
> clicking any session we can go to its detail screen, where basic details 
> regarding this session are listed in the 'Overview' section and items are 
> listed in the 'Items' section. We can select any number of rows and mark them 
> as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the 
> variance is created and these are added in the Count Progress report. Only 
> authorized persons can accept or reject the sessions and once the session is 
> accepted it is marked as 'Completed'.
> *Count Progress Report:* In this screen, User can view the advanced counting 
> related analytics with respect to all the 'Completed' status session from 
> Reports Screen. We can filter the records on the basis of the facility and 
> within the date range. We can also see the percentage of the total locations, 
> inventory items counted and errors occurred during the process. Item variance 
> details are listed in the below section in tabular form.
> Following changes to the existing data model to support end to end counting 
> process flow:
> *New entities:*
> *InventoryCount*
>    inventoryCountId
>    uploadedByUserLogin
>    facilityId
>    statusId
>    createdDatetime
>  *InventoryCountItem*
>    inventoryCountId
>    inventoryCountItemSeqId
>    inventoryItemId
>    itemStatusId
>    locationSeqId
>    productId
>    productIdentifier
>    quantity
>  *InventoryCountVariance* 
>    inventoryCountId
>    inventoryCountItemSeqId
>    inventoryItemId
>    productId
>    productIdentifier
>    locationSeqId
>    systemQuantityOnHand
>    actualQuantityOnHand
>    varianceQuantityOnHand
>    totalCost
>    actualCost
>    costVariance
>  

[jira] [Closed] (OFBIZ-11341) Possible NullPointerException in FinAccountServices

[Michael Brohl (Jira)]

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

Michael Brohl closed OFBIZ-11341.
-
Resolution: Fixed

Thanks Jacques, I think we can close it now.

> Possible NullPointerException in FinAccountServices
> ---
>
> Key: OFBIZ-11341
> URL: https://issues.apache.org/jira/browse/OFBIZ-11341
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: 17.12.01, Release Branch 16.11
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: 17.12.01, Release Branch 16.11
>
>
> In r1828233 I fixed a bug which was not tracked by Jira and needs backporting 
> to 17.12.
> I also noticed that this is also present in the 16.11 release branch. Should 
> it be backported there also?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OFBIZ-11341) Possible NullPointerException in FinAccountServices

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11341:

Fix Version/s: Release Branch 16.11

> Possible NullPointerException in FinAccountServices
> ---
>
> Key: OFBIZ-11341
> URL: https://issues.apache.org/jira/browse/OFBIZ-11341
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: 17.12.01, Release Branch 16.11
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: 17.12.01, Release Branch 16.11
>
>
> In r1828233 I fixed a bug which was not tracked by Jira and needs backporting 
> to 17.12.
> I also noticed that this is also present in the 16.11 release branch. Should 
> it be backported there also?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-11341) Possible NullPointerException in FinAccountServices

[Jacques Le Roux (Jira)]

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

Jacques Le Roux commented on OFBIZ-11341:
-

This has been backported in R16: r1873777

> Possible NullPointerException in FinAccountServices
> ---
>
> Key: OFBIZ-11341
> URL: https://issues.apache.org/jira/browse/OFBIZ-11341
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: 17.12.01, Release Branch 16.11
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: 17.12.01
>
>
> In r1828233 I fixed a bug which was not tracked by Jira and needs backporting 
> to 17.12.
> I also noticed that this is also present in the 16.11 release branch. Should 
> it be backported there also?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Attachment: OFBIZ-11306.patch

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux commented on OFBIZ-11306:
-

Indeed, I wondered after picking request, better in security agreed. Here is 
the last patch [^OFBIZ-11306.patch] 

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-11306) POC for CSRF Token

[James Yong (Jira)]

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

James Yong commented on OFBIZ-11306:


Hi Jacques,

Thanks for the work so far.

I think "csrf-defense-enabled" should be configured in security.properties, 
same as "csrf.cache.size".

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Michael Brohl (Jira)]

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

Michael Brohl commented on OFBIZ-3847:
--

+1 [~paulfoxworthy]

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OFBIZ-10953) have CurrencyDimension have a dimensionId that is based on the natural key

[Jacopo Cappellato (Jira)]

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

Jacopo Cappellato updated OFBIZ-10953:
--
Attachment: 20200208_094840.jpg

> have CurrencyDimension have a dimensionId that is based on the natural key
> --
>
> Key: OFBIZ-10953
> URL: https://issues.apache.org/jira/browse/OFBIZ-10953
> Project: OFBiz
>  Issue Type: Improvement
>  Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>  Labels: CurrencyDimension, birt, currency, dimension, dwh
> Attachments: 20200208_094840.jpg, OFBIZ-10953-BI.patch
>
>
> Currently the record sequencer (delegator.getNextSeqId) is used to determine 
> the dimensionId for the CurrencyDimension. This is unnecessary as the uomId 
> from the UOM table can be used for currency.
> It also makes it easier to set the foreign-key in fact tables by generating 
> it based on the date provided, than by retrieving the dimensionId based on a 
> retrieval through the getDimensionIdFromNaturalKey service.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-10953) have CurrencyDimension have a dimensionId that is based on the natural key

[Jacopo Cappellato (Jira)]

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

Jacopo Cappellato commented on OFBIZ-10953:
---

I know that in the third edition of the book the author introduced the 
possibility of an exception for the Date dimension:
{quote}A dimension table is designed with one column serving as a unique 
primary key. The primary key cannot be the operational system's natural key 
[...] These dimension surrogate keys are simple integers, assigned in sequence, 
starting with the value 1, every time a new key is needed. The date dimension 
is exempt from the surrogate key rule; this highly predictable and stable 
dimension can use a more meaningful primary key [...]. 
{quote}
However it is made clear that this exception should not be a shortcut to 
provide meaning to date fields in fact tables and instead can be introduced:
{quote}*To facilitate partitioning*, the primary key of a date dimension can be 
more meaningful, such as an integer representing MMDD, instead of 
sequentially-assigned surrogate key.
{quote}
With that said, the golden rule is always the same:
{quote}Every join between dimension and fact tables in the data warehouse 
should be based on meaningless integer surrogate keys. You should avoid using 
the natural operational production codes. None of the data warehouse keys 
should be smart, where you can tell something about the row just by looking at 
the key.
{quote}
Pierre wrote:
{quote}The latter means that in a production infrastructure the using company 
is penalised (performance and cost-wise) with an additional query (for the 
*origCurrencyDimId*) to the currency dimension to retrieve the underlying 
explanation/meaning (EUR). And similarly for the *quantityUomDimId* and other 
generically defined measurements (e.g. in the examples the  *invoiceDateDimId*).
{quote}
No additional query is required to fetch, for example, date information; 
instead the star schema should include an additional join to link the fact 
table to the Date dimension table. This would not increase the number of 
records produces (which is upper limited by the rows and in fact table): star 
schemas are designed like this to perform best with single queries with several 
joins (from one fact to many dimensions).

In my opinion, rather than relaxing the "surrogate key" rule for dimension 
tables by introducing exceptions to it, it would be better to improve the 
implementation of surrogate keys in our BI component: in fact they are not 
currently implemented as integer sequential numbers and are instead strings. 
Switching to sequential integers would greatly improve performance and shrink 
the size of many tables in the OLAP database. When the BI component was 
created, it was decided to use strings simply because it was a prototype (not 
intended for production), and since there is no support for a db independent 
way to generate integer sequences in OFBiz, we ended up using the available 
sequence generator utility for strings.

 

 

 

> have CurrencyDimension have a dimensionId that is based on the natural key
> --
>
> Key: OFBIZ-10953
> URL: https://issues.apache.org/jira/browse/OFBIZ-10953
> Project: OFBiz
>  Issue Type: Improvement
>  Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>  Labels: CurrencyDimension, birt, currency, dimension, dwh
> Attachments: OFBIZ-10953-BI.patch
>
>
> Currently the record sequencer (delegator.getNextSeqId) is used to determine 
> the dimensionId for the CurrencyDimension. This is unnecessary as the uomId 
> from the UOM table can be used for currency.
> It also makes it easier to set the foreign-key in fact tables by generating 
> it based on the date provided, than by retrieving the dimensionId based on a 
> retrieval through the getDimensionIdFromNaturalKey service.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token

[Michael Brohl (Jira)]

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

Michael Brohl edited comment on OFBIZ-11306 at 2/8/20 9:15 AM:
---

I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?

My main point is that we should avoid committing (portions) of a new feature 
into trunk directly until the feature is finished, reviewed, testet and 
accepted.

Regarding the store of the tokens inside the OFBiz cache: this seems to be an 
invalid approach to me. The tokens should be hold in the session or a cookie.


was (Author: mbrohl):
I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?

My main point is that we should avoid committing (portions) of a new feature 
into trunk directly until the feature is finished, reviewed, testet and 
accepted.

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-11301) Clarify usage of Github PR

[Jacques Le Roux (Jira)]

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

Jacques Le Roux commented on OFBIZ-11301:
-

I have moved the comments related to Git and GitHub usage from OFBIZ-11306 to 
the [wiki 
page|https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP]

> Clarify usage of Github PR
> --
>
> Key: OFBIZ-11301
> URL: https://issues.apache.org/jira/browse/OFBIZ-11301
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: git
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Pierre Smits
>Priority: Major
>  Labels: documentation
>
> The PullRequest reflex is now an acquired behaviour.
> I started a discussion at [https://markmail.org/message/jx426hxxwvllynx3], 
> summary:
> Our workflow is to contribute patches through Jira. We need to clearly 
> document how the project is going to work with Pull Requests. as part of 
> [https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices]
> Remark Jacques: _But I know that it will not be enough. So I'll also add a 
> notice in the top of our main README.adoc to make it clear on our main Github 
> page_.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (OFBIZ-11301) Clarify usage of Github PR

[Jacques Le Roux (Jira)]

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

Jacques Le Roux edited comment on OFBIZ-11301 at 2/8/20 8:48 AM:
-

Effort to address this has been started. Currently work is done on a WIP page 
in Confluence, see 
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP


was (Author: pfm.smits):
Effort to address this has been started. Currently work is done on a WIP page 
in Confluence, see 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=145724011]

> Clarify usage of Github PR
> --
>
> Key: OFBIZ-11301
> URL: https://issues.apache.org/jira/browse/OFBIZ-11301
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: git
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Pierre Smits
>Priority: Major
>  Labels: documentation
>
> The PullRequest reflex is now an acquired behaviour.
> I started a discussion at [https://markmail.org/message/jx426hxxwvllynx3], 
> summary:
> Our workflow is to contribute patches through Jira. We need to clearly 
> document how the project is going to work with Pull Requests. as part of 
> [https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices]
> Remark Jacques: _But I know that it will not be enough. So I'll also add a 
> notice in the top of our main README.adoc to make it clear on our main Github 
> page_.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux edited comment on OFBIZ-11306 at 2/8/20 8:46 AM:
-

I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?

My main point is that we should avoid committing (portions) of a new feature 
into trunk directly until the feature is finished, reviewed, testet and 
accepted.


was (Author: mbrohl):
I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: Hi Jacques,

we should stop hijacking the issue for these discussions (I did it too 
here and stop it now because it is the wrong place).

Maybe we should remove the comments there and discuss further in the dev 
mailing list.

Regards,

Michael


)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: Sorry to make this issue more confusing, but since we are on it and 
before we write that in stone using the related wiki page. I wrote:
bq. The reasons I'd privilege cloned user repositories is about responsability 
and proliferation of branches in official repos. That would uselessly clutter 
the repo and scramble things. Anyway, again that's not mine to decide but the 
community...
Actually if you think about it these options are not contradictory. We could 
use both. When we agree that sufficient work has been done in a cloned repo 
then we can create an OFBiz repo branch before possibly committing it. What I 
wonder about is if we need to keep it later?)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: bq. Yes, my main point is that we should avoid committing (portions) of a 
new feature into trunk directly until the feature is finished, reviewed, testet 
and accepted. It avoids cluttering the history, having to revert commits and 
also having unfinished work in trunk if the work got stuck etc.
+1
bq. With git we have several ways to achieve that. Personally I have no 
problems with feature branches in the main repository (that's how we organize 
our work here at ecomify), but having it in cloned user repositories is also 
fine.
The reasons I'd privilege cloned user repositories is about responsability and 
proliferation of branches in official repos. That would uselessly clutter the 
repo and scramble things. Anyway, again that's not mine to decide but the 
community...
)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: A community member's fork from the Github repository is - in essence - 
not different to an organisation's fork in a private environment. Both are 
expected to have development/feature branches and both can have release 
branches and tags based on different criteria than those of the project.

That is one of the key benefits of the git's approach to version control and 
collaboration.)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: Yes, my main point is that we should avoid committing (portions) of a new 
feature into trunk directly until the feature is finished, reviewed, testet and 
accepted. It avoids cluttering the history, having to revert commits and also 
having unfinished work in trunk if the work got stuck etc.

With git we have several ways to achieve that. Personally I have no problems 
with feature branches in the main repository (that's how we organize our work 
here at ecomify), but having it in cloned user repositories is also fine.)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: I think that before possibly discussing Git workflow we need to complete 
OFBIZ-11301, could be part of it also.)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux updated OFBIZ-11306:

Comment: was deleted

(was: Michael,

BTW maybe we don't need to discuss all that about feature branch under OFBiz 
repo. See's Pierre proposition in OFBIZ-10577 I seconded at 
https://s.apache.org/jmls7)

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux edited comment on OFBIZ-11306 at 2/8/20 8:35 AM:
-

Hi Michael,

Nothing directly related to this issue is commited. There is a reference to 
this issue when I committed OFBIZ-11329 which was a blocking subtask but not 
directly related to this work, hence it's committed. It was discovered wrong 
while working on this issue and had been fixed. Then the Jira-Git relation 
makes these commits appears here.

The last patch is always the reference. 

bq. Regarding the store of the tokens inside the OFBiz cache: this seems to be 
an invalid approach to me. The tokens should be hold in the session or a cookie.
As I (actually James) already explained in my last answer to you, the session 
can't be used because of inter webapps requests. Could you please explain how 
you envision to use cookies for that? 

You might be interested to read 
https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies.
 

I also recommend you to read the exchanges we already had with James. For 
instance we don't want a sole token value (in a cookie for instance) but have a 
strategy where the tokens are generated for each request. Though allowing the 
back and forth buttons which is normally an issue with tokens by requests.

Still, this is a WIP. At the moment our main remaining issue is related with 
the introduction of REST requests with OFBIZ-11007 (James began before this was 
committed). 

Of course all ideas are welcome, but please backed up with reviews and strong 
support.


was (Author: jacques.le.roux):
Hi Michael,

Nothing directly related to this issue is commited. There is a reference to 
this issue when I committed OFBIZ-11329 which was a blocking subtask but not 
directly related to this work, hence it's committed. It was discovered wrong 
while working on this issue and had been fixed. Then the Jira-Git relation 
makes these commits appears here.

[As I already explained|https://s.apache.org/72j22] I'm not a fan of feature 
branches. If we want to adopt a specific Git workflow we need a consensus and I 
guess a vote. If we do a such thing I urge all participants to seriouyly read 
the articles I cited. Anyway there is not need here, the last patch is the 
reference. 

bq. Regarding the store of the tokens inside the OFBiz cache: this seems to be 
an invalid approach to me. The tokens should be hold in the session or a cookie.
As I (actually James) already explained in my last answer to you, the session 
can't be used because of inter webapps requests. Could you please explain how 
you envision to use cookies for that? 

You might be interested to read 
https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies.
 

I also recommend you to read the exchanges we already had with James. For 
instance we don't want a sole token value (in a cookie for instance) but have a 
strategy where the tokens are generated for each request. Though allowing the 
back and forth buttons which is normally an issue with tokens by requests.

Still, this is a WIP. At the moment our main remaining issue is related with 
the introduction of REST requests with OFBIZ-11007 (James began before this was 
committed). 

Of course all ideas are welcome, but please backed up with reviews and strong 
support.



> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In 

[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token

[Jacques Le Roux (Jira)]

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

Jacques Le Roux edited comment on OFBIZ-11306 at 2/8/20 8:33 AM:
-

I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?


was (Author: mbrohl):
I'm currently not sure about the state of this POC: there were a few commits 
already.

Is it already committed to trunk?

If yes, wouldn't it be better to work it out in a feature branch so that we 
have a clear view what has changes with the POC? It seems not a trivial change 
to me and from the brief overview of the comments it was not an easy task and I 
think it needs review from others too.

Regarding the store of the tokens inside the OFBiz cache: this seems to be an 
invalid approach to me. The tokens should be hold in the session or a cookie.

Maybe I am missing something so I recommend to provide the solution in a 
feature branch for others to review before it gets committed to trunk.

> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, 
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, 
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, 
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a 
> "time out"). 
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP 
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during 
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to 
> exempt or force CSRF token check. 
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the 
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no 
> need to manually add the CSRF token field to each form in the ftl files. It 
> will save time for users doing custom implementation and maintenance.  While 
> there is CSRF token in the form URL, the token is invalidated during form 
> submission. So it's uniqueand harmless even though the CSRF token of the form 
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added 
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token 
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs 
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token 
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF 
> token check. (Note there are discussions that RequestMap with ‘all’ method 
> should also not be subjected to CSRF token check. This will be done after 
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the 
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done 
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside 
> the constructor of RequestMap class) when determining the final 
> securityCsrfToken value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OFBIZ-11301) Clarify usage of Github PR

[Jacques Le Roux (Jira)]

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

Jacques Le Roux commented on OFBIZ-11301:
-

I have made some modifications, notably about drawback of pullAllPluginsSource 
which is still Svn based

> Clarify usage of Github PR
> --
>
> Key: OFBIZ-11301
> URL: https://issues.apache.org/jira/browse/OFBIZ-11301
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: git
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Pierre Smits
>Priority: Major
>  Labels: documentation
>
> The PullRequest reflex is now an acquired behaviour.
> I started a discussion at [https://markmail.org/message/jx426hxxwvllynx3], 
> summary:
> Our workflow is to contribute patches through Jira. We need to clearly 
> document how the project is going to work with Pull Requests. as part of 
> [https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices]
> Remark Jacques: _But I know that it will not be enough. So I'll also add a 
> notice in the top of our main README.adoc to make it clear on our main Github 
> page_.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)