You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Andrea Cosentino (Jira)" <ji...@apache.org> on 2026/10/16 11:19:00 UTC

[jira] [Created] (CAMEL-25705) camel-netty-http - normalize dot-segments in the request path used for security constraint matching

Andrea Cosentino created CAMEL-25705:
----------------------------------------

             Summary: camel-netty-http - normalize dot-segments in the request path used for security constraint matching
                 Key: CAMEL-25705
                 URL: https://issues.apache.org/jira/browse/CAMEL-25705
             Project: Camel
          Issue Type: Bug
          Components: camel-netty-http
            Reporter: Andrea Cosentino
            Assignee: Andrea Cosentino
             Fix For: 4.24.0, 4.18.6, 4.22.2


When a netty-http consumer uses {{matchOnUriPrefix=true}} together with a {{securityConstraint}} (a {{SecurityConstraintMapping}}) whose inclusions/exclusions are specific sub-paths, the path used to evaluate the constraint is taken from the request URI without resolving relative dot-segments ({{.}} and {{..}}, including their percent-encoded {{%2e}} form).

As a consequence a request path such as {{/foo/../admin/resource}} is matched against the configured inclusions in its unresolved form ({{/../admin/resource}}) instead of its effective resolved path ({{/admin/resource}}). The constraint lookup can therefore disagree with the path the request is actually dispatched and routed to.

This continues the consistency work started in CAMEL-24412, which aligned the context-path strip of the constraint lookup to be case-insensitive the same way consumer dispatch is. The remaining gap is dot-segment resolution: the security-constraint target should collapse {{.}}/{{..}} segments so it is evaluated against the same effective path, and a request whose resolved path escapes the endpoint context (for example a leading {{..}}) should be rejected rather than silently evaluated as a different, unmatched resource.

*Code-level change*
* {{HttpServerChannelHandler.extractTarget(URI)}} derives the constraint target from {{uri.getPath()}} and strips the context-path, but never normalizes dot-segments.
* {{PatternHelper.matchPattern}} (used by {{SecurityConstraintMapping.includedUrl}}/{{excludedUrl}}) then matches the unresolved path against the configured inclusions/exclusions.
* Resolve dot-segments on the target before the inclusion/exclusion match (and fail closed when the resolved path would escape the endpoint context).

*Tests*
Add a regression test using a specific inclusion (for example {{/admin/*}}, without a catch-all) and assert consistent handling for the plain path, the literal {{..}} form and the percent-encoded {{%2e%2e}} form.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)