Joerg Hoh created SLING-13380:
---------------------------------
Summary: Document misleading containment results for glob
arguments in Path.matches() and PathSet.matches()
Key: SLING-13380
URL: https://issues.apache.org/jira/browse/SLING-13380
Project: Sling
Issue Type: Task
Components: API
Affects Versions: API 3.0.2
Reporter: Joerg Hoh
h2. Problem
{\{Path.matches(String)}} interprets an \{{otherPath}} argument starting with
\{{glob:}} as a pattern. This can produce misleading results when callers use
the method as a concrete-path containment check.
For example:
{code:java}
new Path("/apps").matches("glob:/**"); // returns true
{code}
The result does not establish containment: \{{glob:/**}} is not a concrete path
inside \{{/apps}} and also matches paths outside that subtree.
{\{PathSet.matches(String)}} inherits this behavior:
{code:java}
PathSet.fromStrings("/apps").matches("glob:/**"); // returns Path("/apps")
{code}
The checked consumers in Sling provide concrete paths, so this misuse was not
found there. Pattern arguments are documented functionality; this ticket
preserves existing behavior while warning against using it as a containment or
authorization guarantee.
h2. Proposed changes
* Add a warning and an example to the Javadoc of \{{Path.matches(String)}}.
* Add a corresponding warning to \{{PathSet.matches(String)}}, referencing the
example.
* Add passing tests that explicitly document the known incorrect containment
behavior.
* Leave runtime behavior unchanged.
I don't think that we should change the semantic of these methods (for example
disallow globs in the {{otherPath}} argument) as it is part of the Sling API.
If ever warranted, we can extend {{Path}} and {{PathSet}} with a
{{matchesNonGlob(String otherPath)}} method and switch the consumers within
Sling to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
