Kevin Doran created NIFI-6227:
---------------------------------

             Summary: Get Access Policy for Action-Resource endpoint does not 
accept encoded '/' characters in the path param for resource
                 Key: NIFI-6227
                 URL: https://issues.apache.org/jira/browse/NIFI-6227
             Project: Apache NiFi
          Issue Type: Improvement
            Reporter: Kevin Doran


The REST API has the following endpoint:

{noformat}
GET /policies/{action}/{resource}
{noformat}

The resource path parameter can contain forward slash characters. When using 
URI Templates, client HTTP frameworks, or swagger codegen clients, by default 
will url encode forward slashes '/' in path parameters (ie, %2F). However, the 
server rejects encoded slash characters for path parameters with the following 
error message:

{noformat}
ValueError: The request was rejected because the URL contained a potentially 
malicious String "%25"
{noformat}

This is due to the Spring Security {{StrictHttpFirewall}} which is enabled by 
default. 

One possible solution would be providing our own {{HttpFirewall}} bean that 
subclasses {{StrictHttpFirewall}} to allow encoded slashes if the HTTP method 
is GET and the URL path starts with /policies/read/* or /policies/write/*. 
Then, in the controller code for this endpoint, we could decode the resource 
parameter safely.

Note: The code for this endpoint is in 
[AccessPolicyResource|https://github.com/apache/nifi/blob/cd2c3fd4e6fb9863c116d01bf8d274b80867622f/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessPolicyResource.java#L131].

Another possible solution would be adding an alternate endpoint that uses query 
parameters instead of path parameters.

This is currently a low priority ticket, because most HTTP client frameworks 
offer an option to not encode slashes in path parameters, even if the default 
behavior is to encode slashes in path parameters. RFC 6570 refers to this 
behavior as "Path Segment Expansion" to differentiate it from Path Parameter 
substitution. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to