You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Ashish Chopra (Jira)" <ji...@apache.org> on 2020/08/14 12:11:00 UTC

[jira] [Commented] (OAK-9179) Documentation (and comments) about rep:glob patterns in ACE restriction is confusing

    [ 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)