[jira] [Commented] (OFBIZ-11007) REST: adding segmented URI support
[ https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004807#comment-17004807 ] Mathieu Lirzin commented on OFBIZ-11007: Hello [~nmalin], The approach we followed with [~artemiy] was to intentionally not provide any guarantee on the request-map resolution algorithm in the context of ambiguities, meaning when multiple request-maps are matching the same HTTP request URI. Our assumption was that ambiguous routes should not be used to simplify reasoning/debugging. A limitation of the current implementation is that we currently don't detect/report those ambiguities, we simply choose one. Our approach is debatable and for example the JAX-RS specification which serves as a standard for Java REST APIs [specifies a precedence order when matching URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2]. So I am not strongly opposed to specifying a resolution order in OFBiz as you proposed in [^OFBIZ-11007_refactor-entitymaint.patch], with the condition that it follows a standard and documented algorithm like for example the one from JAX-RS. Regarding the particular case of entities, a simple way to avoid ambiguities in your example would be to use different separators like for example: {code:java} entity-list -> entitymaint entity/{entityName} -> FindGeneric entity/{entityName}/{pkValues: .*} -> ViewGeneric entity-edit/{entityName} -> edit form entity-edit/{entityName}/{pkValues: .*} -> edit form entity-relations/{entityName} -> ViewRelation {code} If you really want to use {{/}} while removing ambiguities you can use regular expression in URI templates to prevent {{entity/{entityName}}} to match {{/entity/list}} you should be able to replace it with something like {{entity/{name:(?!list).*}}} to prevent the match (not tested). However I don't recommend that solution because it requires understanding an advanced feature of Java regexp. Thanks for working on that. > REST: adding segmented URI support > -- > > Key: OFBIZ-11007 > URL: https://issues.apache.org/jira/browse/OFBIZ-11007 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk > Environment: >Reporter: Artemiy Rozovyk >Assignee: Nicolas Malin >Priority: Minor > Labels: REST, URI > Fix For: Upcoming Branch > > Attachments: OFBIZ-11007_refactor-entitymaint.patch, > OFBIZ-11007_refactor-entitymaint.patch, entitymaint_example.patch, > restful_URIs.patch > > > Following the discussion on making OFBiz RESTful OFBIZ-4274 i implemented the > support of segmented URIs without interfering with current mechanisms of URI > resolution nor with _overrideView()_ feature. > Combined with work on associating URIs and HTTP methods done by [~mthl] in > OFBIZ-10438 , we are now able to provide RESTful APIs as follows: > {code:java} > > ... > > ... > > ... > {code} > After we matched a request-map having parametrized URI as in > {code:java} > uri="foo/bar/{baz}" > {code} > the value is available inside the request attributes with the corresponding > key (here _"baz"_) > The *restful_URIs.patch* allows segmented URI support. > The *entitymaint_example.patch* is a modified _entitymaint_ part that serves > as an example of possible application of new system. > Any questions or comments are welcomed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support
[ https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004807#comment-17004807 ] Mathieu Lirzin edited comment on OFBIZ-11007 at 12/29/19 2:58 PM: -- Hello [~nmalin], The approach we followed with [~artemiy] was to intentionally not provide any guarantee on the request-map resolution algorithm in the context of ambiguities, meaning when multiple request-maps are matching the same HTTP request URI. Our assumption was that ambiguous routes should not be used to simplify reasoning/debugging. A limitation of the current implementation is that we currently don't detect/report those ambiguities, we simply choose one. Our approach is debatable and for example the JAX-RS specification which serves as a standard for Java REST APIs [specifies a precedence order when matching URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2]. So I am not strongly opposed to specifying a resolution order in OFBiz as you proposed in [^OFBIZ-11007_refactor-entitymaint.patch], with the condition that it follows a standard and documented algorithm like for example the one from JAX-RS. Regarding the particular case of entities, a simple way to avoid ambiguities in your example would be to use different separators like for example: {code:java} entity-list -> entitymaint entity/{entityName} -> FindGeneric entity/{entityName}/{pkValues: .*} -> ViewGeneric entity-edit/{entityName} -> edit form entity-edit/{entityName}/{pkValues: .*} -> edit form entity-relations/{entityName} -> ViewRelation {code} If you really want to use {{/}} while removing ambiguities you can use regular expression in URI templates to prevent {{entity/\{entityName\}}} to match {{/entity/list}} you should be able to replace it with something like {{entity/\{name:(?!list).*\}}} to prevent the match (not tested). However I don't recommend that solution because it requires understanding an advanced feature of Java regexp. Thanks for working on that. was (Author: mthl): Hello [~nmalin], The approach we followed with [~artemiy] was to intentionally not provide any guarantee on the request-map resolution algorithm in the context of ambiguities, meaning when multiple request-maps are matching the same HTTP request URI. Our assumption was that ambiguous routes should not be used to simplify reasoning/debugging. A limitation of the current implementation is that we currently don't detect/report those ambiguities, we simply choose one. Our approach is debatable and for example the JAX-RS specification which serves as a standard for Java REST APIs [specifies a precedence order when matching URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2]. So I am not strongly opposed to specifying a resolution order in OFBiz as you proposed in [^OFBIZ-11007_refactor-entitymaint.patch], with the condition that it follows a standard and documented algorithm like for example the one from JAX-RS. Regarding the particular case of entities, a simple way to avoid ambiguities in your example would be to use different separators like for example: {code:java} entity-list -> entitymaint entity/{entityName} -> FindGeneric entity/{entityName}/{pkValues: .*} -> ViewGeneric entity-edit/{entityName} -> edit form entity-edit/{entityName}/{pkValues: .*} -> edit form entity-relations/{entityName} -> ViewRelation {code} If you really want to use {{/}} while removing ambiguities you can use regular expression in URI templates to prevent {{entity/{entityName}}} to match {{/entity/list}} you should be able to replace it with something like {{entity/{name:(?!list).*}}} to prevent the match (not tested). However I don't recommend that solution because it requires understanding an advanced feature of Java regexp. Thanks for working on that. > REST: adding segmented URI support > -- > > Key: OFBIZ-11007 > URL: https://issues.apache.org/jira/browse/OFBIZ-11007 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk > Environment: >Reporter: Artemiy Rozovyk >Assignee: Nicolas Malin >Priority: Minor > Labels: REST, URI > Fix For: Upcoming Branch > > Attachments: OFBIZ-11007_refactor-entitymaint.patch, > OFBIZ-11007_refactor-entitymaint.patch, entitymaint_example.patch, > restful_URIs.patch > > > Following the discussion on making OFBiz RESTful OFBIZ-4274 i implemented the > support of segmented URIs without interfering with current mechanisms of URI >
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004776#comment-17004776 ] James Yong commented on OFBIZ-11306: Updated the patch with bug fixes related to pagination and ecommerce. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: OFBIZ-11306-v2.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch > > > CRSF tokens are generated using CSRF Guard library and used in: > 1) In widget form where a hidden token field is auto-generated. > 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf > token field. > 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token > to X-CSRF-Token in request header. > CSRF tokens are stored in the user sessions, and verified during POST request. > A new attribute i.e. csrf-token is added to the security tag to exempt CSRF > token check. > Certain request path, like LookupPartyName, can be exempt from CSRF token > check during Ajax POST call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Yong updated OFBIZ-11306: --- Attachment: OFBIZ-11306.patch > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: OFBIZ-11306-v2.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch > > > CRSF tokens are generated using CSRF Guard library and used in: > 1) In widget form where a hidden token field is auto-generated. > 2) In FTL form where a <@csrfTokenField> macro is used to generate the csrf > token field. > 3) In Ajax call where a <@csrfTokenAjax> macro is used to assign csrf token > to X-CSRF-Token in request header. > CSRF tokens are stored in the user sessions, and verified during POST request. > A new attribute i.e. csrf-token is added to the security tag to exempt CSRF > token check. > Certain request path, like LookupPartyName, can be exempt from CSRF token > check during Ajax POST call. -- This message was sent by Atlassian Jira (v8.3.4#803005)