[
https://issues.apache.org/jira/browse/OAK-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177729#comment-17177729
]
Ashish Chopra commented on OAK-9179:
------------------------------------
Playing around with the {{GlobPatternTest}}, I found a difference between
{{/cat/}} and {{/cat/*}} globs, but that's not what documentation suggests.
Essentially, with a glob as:
{code}
GlobPattern.create("/a/b/c", "/d/")
{code}
a match for:
* {{/a/b/c/d}} -> non-matching
* {{/a/b/c/d/}} -> matching
* {{/a/b/c/d/e}} -> matching
* {{/a/b/c/d/e/f}} -> matching
In contrast, with a glob as:
{code}
GlobPattern.create("/a/b/c", "/d/*");
{code}
* {{/a/b/c/d}} -> non-matching
* {{/a/b/c/d/}} -> non-matching
** {color:red}this was matching in the previous glob without a trailing
wildcard{color}
* {{/a/b/c/d/e}} -> matching
* {{/a/b/c/d/e/f}} -> matching
I'm not exactly sure what is the practical consequence of this difference,
though - does JCR spec allow reading a path like {{/a/b/c/d/}}? (I don't think
we'd be able to prevent access to a property via this anyway because paths like
{{/a/b/c/d/prop}} will be matched still - but maybe I'm missing a nuance here).
> Documentation (and comments) about rep:glob patterns in ACE restriction is
> confusing
> ------------------------------------------------------------------------------------
>
> Key: OAK-9179
> URL: https://issues.apache.org/jira/browse/OAK-9179
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, docs
> Reporter: Ashish Chopra
> Priority: Major
> Attachments: image-2020-08-14-17-04-51-436.png,
> image-2020-08-14-17-10-48-466.png, slash-wildcard.png
>
>
> There appears to be a bit of disconnect (or at least language differences)
> between what the documentation says and what actually happens
> # {{/cat/}} and {{/cat/*}} seem to behave identically
> ** FWIW, that's what documentation also _seems_ to suggest, but the
> terminology is confusing [0] [1]
> ** the tests [2] [3], though not exactly the same, seem imply the equivalence
> ** 'descendants' implies "all", so we should either add "all" to both [0] and
> [1], or remove it altogether for consistency - essentially, we should use the
> exact same description for both the patterns if they are equivalent in all
> respects, or update the language to highlight/contrast the difference
> # {{/cat}} says "the node and all its child items" [4].
> ** the test [5] indicates that descendants can be accessed as well
> ** For consistency, we should consider replacing child-items with
> 'descendants'
> [0] !image-2020-08-14-17-04-51-436.png!
> [1] !slash-wildcard.png!
> [2]
> https://github.com/apache/jackrabbit-oak/blob/762764e0c7120557c1515c54322d6a0936ae04db/oak-core/src/test/java/org/apache/jackrabbit/oak/security/authorization/restriction/GlobPatternTest.java#L401-L402
> [3]
> https://github.com/apache/jackrabbit-oak/blob/762764e0c7120557c1515c54322d6a0936ae04db/oak-core/src/test/java/org/apache/jackrabbit/oak/security/authorization/restriction/GlobPatternTest.java#L231-L232
> [4] !image-2020-08-14-17-10-48-466.png!
> [5]
> https://github.com/apache/jackrabbit-oak/blob/762764e0c7120557c1515c54322d6a0936ae04db/oak-core/src/test/java/org/apache/jackrabbit/oak/security/authorization/restriction/GlobPatternTest.java#L383-L384
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
