[jira] [Created] (OAK-10200) CompositeAccessControlManager.getEffectivePolicies(String) should filter duplicate policies
Angela Schreiber created OAK-10200: -- Summary: CompositeAccessControlManager.getEffectivePolicies(String) should filter duplicate policies Key: OAK-10200 URL: https://issues.apache.org/jira/browse/OAK-10200 Project: Jackrabbit Oak Issue Type: Improvement Components: core, security Reporter: Angela Schreiber Assignee: Angela Schreiber Fix For: 1.52.0 in a composite authorization setup different components may provide the same effective policies (e.g. ReadPolicy singleton). the implementation should filter out the duplicates. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10188) Document OAK-10130 JackrabbitAccessControlManager.getEffectivePolicies(Set,String...)
[
https://issues.apache.org/jira/browse/OAK-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10188.
Fix Version/s: 1.52.0
Resolution: Fixed
> Document OAK-10130
> JackrabbitAccessControlManager.getEffectivePolicies(Set,String...)
> -
>
> Key: OAK-10188
> URL: https://issues.apache.org/jira/browse/OAK-10188
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: doc, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.52.0
>
>
> document the new method for {{JackrabbitAccessControlManager}}
> {code}
> Iterator getEffectivePolicies(@NotNull Set
> principals, @Nullable String... absPaths)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10188) Document OAK-10130 JackrabbitAccessControlManager.getEffectivePolicies(Set,String...)
Angela Schreiber created OAK-10188:
--
Summary: Document OAK-10130
JackrabbitAccessControlManager.getEffectivePolicies(Set,String...)
Key: OAK-10188
URL: https://issues.apache.org/jira/browse/OAK-10188
Project: Jackrabbit Oak
Issue Type: Documentation
Components: doc, security
Reporter: Angela Schreiber
Assignee: Angela Schreiber
document the new method for {{JackrabbitAccessControlManager}}
{code}
Iterator getEffectivePolicies(@NotNull Set
principals, @Nullable String... absPaths)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10130) Add API to retrieve effective policies for a set of principals for a given path
[
https://issues.apache.org/jira/browse/OAK-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10130.
Fix Version/s: 1.52.0
Resolution: Fixed
> Add API to retrieve effective policies for a set of principals for a given
> path
> ---
>
> Key: OAK-10130
> URL: https://issues.apache.org/jira/browse/OAK-10130
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: authorization-cug, authorization-principalbased, core,
> jackrabbit-api, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.52.0
>
>
> JCR and Jackrabbit API currently provide the following methods to retrieve
> effective policies:
> h4. javax.jcr.security.AccessControlManager
> {code}
> AccessControlPolicy[] getEffectivePolicies(String absPath)
> throws PathNotFoundException, AccessDeniedException,
> RepositoryException;
> {code}
> h4. org.apache.jackrabbit.api.security.JackrabbitAccessControlManager
> {code}
> AccessControlPolicy[] getEffectivePolicies(@NotNull Set
> principals) throws AccessDeniedException, AccessControlException,
> UnsupportedRepositoryOperationException, RepositoryException;
> {code}
> h4. The missing piece
> What is not possible today however is retrieving the effective policies for a
> given set of principals that take effect on a particular path. While
> consumers of the method provided {{JackrabbitAccessControlManager}} might be
> able to guess where the policies take effect and thus filter the accordingly,
> this should not be taken for granted and it would be better if there was an
> API to retrieve the filtered set as the implementations of
> {{JackrabbitAccessControlManager}} are able to determine the effect (instead
> of guessing) in particular when restrictions are present.
> I would there suggest to introduce in {{JackrabbitAccessControlManager}}
> something like
> {code}
> Iterator getEffectivePolicies(@NotNull
> Set principals, @Nullable String absPath) throws
> AccessDeniedException, AccessControlException,
> UnsupportedRepositoryOperationException, RepositoryException;
> {code}
> cc: [~cschneider] who highlighted the issue to me while investigating an
> issue with Sling Content Distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10135.
Fix Version/s: 1.52.0
Resolution: Fixed
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.52.0
>
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
> Note: filed this as improvement request (and not a bug) because
> getEffectivePolicy is specified to be a best-effort method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10151) oak-auth-external tests fail with Guava 20
[ https://issues.apache.org/jira/browse/OAK-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10151. Resolution: Not A Bug resolving as not-a-bug due to the fact that the problem is in guava 20 and not in the oak code base. > oak-auth-external tests fail with Guava 20 > -- > > Key: OAK-10151 > URL: https://issues.apache.org/jira/browse/OAK-10151 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Julian Reschke >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10151) oak-auth-external tests fail with Guava 20
[ https://issues.apache.org/jira/browse/OAK-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708263#comment-17708263 ] Angela Schreiber commented on OAK-10151: [~reschke], fine with me. > oak-auth-external tests fail with Guava 20 > -- > > Key: OAK-10151 > URL: https://issues.apache.org/jira/browse/OAK-10151 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Julian Reschke >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10151) oak-auth-external tests fail with Guava 20
[ https://issues.apache.org/jira/browse/OAK-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708244#comment-17708244 ] Angela Schreiber commented on OAK-10151: if 'everywhere' includes code not inside oak then you are right. but for oak i think we should start getting rid of it and if needed write our own replacements either in oak-commons or in an other module. my short term goal here is to get this bug resolved asap :) > oak-auth-external tests fail with Guava 20 > -- > > Key: OAK-10151 > URL: https://issues.apache.org/jira/browse/OAK-10151 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Julian Reschke >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10151) oak-auth-external tests fail with Guava 20
[ https://issues.apache.org/jira/browse/OAK-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708240#comment-17708240 ] Angela Schreiber commented on OAK-10151: [~reschke], wouldn't it be easier to slowly get rid of guava usage altogether? for me that would feel natural. > oak-auth-external tests fail with Guava 20 > -- > > Key: OAK-10151 > URL: https://issues.apache.org/jira/browse/OAK-10151 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Julian Reschke >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10170) simplify usage of authorizableiterator
[
https://issues.apache.org/jira/browse/OAK-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10170.
Fix Version/s: 1.52.0
Resolution: Fixed
> simplify usage of authorizableiterator
> --
>
> Key: OAK-10170
> URL: https://issues.apache.org/jira/browse/OAK-10170
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.52.0
>
>
> the code concatenating iterators in {{AuthorizableImpl}} and {{GroupImpl}}
> should be simplified in those cases where one of 2 iterators is known to be
> empty.
> [~reschke], fyi. this second subtask to further limit the guava related fix
> to the bare minimum.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10151) oak-auth-external tests fail with Guava 20
[ https://issues.apache.org/jira/browse/OAK-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707017#comment-17707017 ] Angela Schreiber commented on OAK-10151: [~reschke], not sure if getting rid of guava is feasible without major effort. but i would replace _every_ usage of Iterators.concat in oak by either a variant 1 or variant 2. no strong pref. > oak-auth-external tests fail with Guava 20 > -- > > Key: OAK-10151 > URL: https://issues.apache.org/jira/browse/OAK-10151 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Julian Reschke >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10170) simplify usage of authorizableiterator
[
https://issues.apache.org/jira/browse/OAK-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10170:
---
Component/s: core
> simplify usage of authorizableiterator
> --
>
> Key: OAK-10170
> URL: https://issues.apache.org/jira/browse/OAK-10170
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> the code concatenating iterators in {{AuthorizableImpl}} and {{GroupImpl}}
> should be simplified in those cases where one of 2 iterators is known to be
> empty.
> [~reschke], fyi. this second subtask to further limit the guava related fix
> to the bare minimum.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10169) improve output of test-assertions
[ https://issues.apache.org/jira/browse/OAK-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10169. Fix Version/s: 1.52.0 Resolution: Fixed > improve output of test-assertions > - > > Key: OAK-10169 > URL: https://issues.apache.org/jira/browse/OAK-10169 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10170) simplify usage of authorizableiterator
[
https://issues.apache.org/jira/browse/OAK-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reassigned OAK-10170:
--
Assignee: Angela Schreiber
> simplify usage of authorizableiterator
> --
>
> Key: OAK-10170
> URL: https://issues.apache.org/jira/browse/OAK-10170
> Project: Jackrabbit Oak
> Issue Type: Technical task
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> the code concatenating iterators in {{AuthorizableImpl}} and {{GroupImpl}}
> should be simplified in those cases where one of 2 iterators is known to be
> empty.
> [~reschke], fyi. this second subtask to further limit the guava related fix
> to the bare minimum.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10170) simplify usage of authorizableiterator
Angela Schreiber created OAK-10170:
--
Summary: simplify usage of authorizableiterator
Key: OAK-10170
URL: https://issues.apache.org/jira/browse/OAK-10170
Project: Jackrabbit Oak
Issue Type: Technical task
Reporter: Angela Schreiber
the code concatenating iterators in {{AuthorizableImpl}} and {{GroupImpl}}
should be simplified in those cases where one of 2 iterators is known to be
empty.
[~reschke], fyi. this second subtask to further limit the guava related fix to
the bare minimum.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10169) improve output of test-assertions
[ https://issues.apache.org/jira/browse/OAK-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10169: -- Assignee: Angela Schreiber > improve output of test-assertions > - > > Key: OAK-10169 > URL: https://issues.apache.org/jira/browse/OAK-10169 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10169) improve output of test-assertions
Angela Schreiber created OAK-10169: -- Summary: improve output of test-assertions Key: OAK-10169 URL: https://issues.apache.org/jira/browse/OAK-10169 Project: Jackrabbit Oak Issue Type: Technical task Components: auth-external Reporter: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706108#comment-17706108
]
Angela Schreiber commented on OAK-10166:
hi [~mmoquillon], thanks for reporting this issue. the implementation of JCR
lock feature in oak is broken and the token is bogus. see also OAK-4460.
we are aware of the fact that JCR locking is not proper implemented and are
trying to get rid of supporting locking altogether.
nonetheless, you are welcome to contribute a patch if that would help unblock
you.
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Priority: Major
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10166:
---
Component/s: core
jcr
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Priority: Major
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10166) Locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10166:
---
Affects Version/s: 1.48.0
> Locking issue when editing a document by WebDAV with LibreOffice
>
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Priority: Major
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10166:
---
Summary: Oak creates bogus lock token causing locking issue when editing a
document by WebDAV with LibreOffice (was: Locking issue when editing a
document by WebDAV with LibreOffice)
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Priority: Major
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (OAK-10166) Locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber moved JCR-4916 to OAK-10166:
-
Key: OAK-10166 (was: JCR-4916)
Workflow: no-reopen-closed (was: no-reopen-closed, patch-avail)
Project: Jackrabbit Oak (was: Jackrabbit Content Repository)
> Locking issue when editing a document by WebDAV with LibreOffice
>
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Miguel Moquillon
>Priority: Major
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10135:
---
Fix Version/s: (was: 1.50.0)
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
> Note: filed this as improvement request (and not a bug) because
> getEffectivePolicy is specified to be a best-effort method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reopened OAK-10135:
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
> Note: filed this as improvement request (and not a bug) because
> getEffectivePolicy is specified to be a best-effort method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10135.
Resolution: Fixed
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
> Note: filed this as improvement request (and not a bug) because
> getEffectivePolicy is specified to be a best-effort method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10135:
---
Description:
Oak default authorization setup allows to configure paths that are always
readable, which by default applies to namespaces, node types and privileges.
Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
{{NamedAccessControllPolicy}} if the path refers to a node where this
read-policy is configured.
In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
principals)}} does not include it. Obviously this ReadPolicy applies for every
set of principals.
However, for consistency and to avoid confusion the
{{NamedAccessControllPolicy}} should be included in the set if the editing
session has sufficient permission on any of the configured paths.
Note: filed this as improvement request (and not a bug) because
getEffectivePolicy is specified to be a best-effort method.
was:
Oak default authorization setup allows to configure paths that are always
readable, which by default applies to namespaces, node types and privileges.
Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
{{NamedAccessControllPolicy}} if the path refers to a node where this
read-policy is configured.
In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
principals)}} does not include it. Obviously this ReadPolicy applies for every
set of principals.
However, for consistency and to avoid confusion the
{{NamedAccessControllPolicy}} should be included in the set if the editing
session has sufficient permission on any of the configured paths.
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
> Note: filed this as improvement request (and not a bug) because
> getEffectivePolicy is specified to be a best-effort method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
[
https://issues.apache.org/jira/browse/OAK-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10135:
---
Fix Version/s: 1.50.0
> JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should
> include ReadPolicy
> -
>
> Key: OAK-10135
> URL: https://issues.apache.org/jira/browse/OAK-10135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased, core, security,
> security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> Oak default authorization setup allows to configure paths that are always
> readable, which by default applies to namespaces, node types and privileges.
> Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
> {{NamedAccessControllPolicy}} if the path refers to a node where this
> read-policy is configured.
> In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
> principals)}} does not include it. Obviously this ReadPolicy applies for
> every set of principals.
> However, for consistency and to avoid confusion the
> {{NamedAccessControllPolicy}} should be included in the set if the editing
> session has sufficient permission on any of the configured paths.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10135) JackrabbitAccessControlManager.getEffectivePolicies(Set principals) should include ReadPolicy
Angela Schreiber created OAK-10135:
--
Summary: JackrabbitAccessControlManager.getEffectivePolicies(Set
principals) should include ReadPolicy
Key: OAK-10135
URL: https://issues.apache.org/jira/browse/OAK-10135
Project: Jackrabbit Oak
Issue Type: Improvement
Components: authorization-principalbased, core, security, security-spi
Reporter: Angela Schreiber
Assignee: Angela Schreiber
Oak default authorization setup allows to configure paths that are always
readable, which by default applies to namespaces, node types and privileges.
Today {{AccessControlManager.getEffectivePolicies(String path)}} includes a
{{NamedAccessControllPolicy}} if the path refers to a node where this
read-policy is configured.
In contrast {{JackrabbitAccessControlManager.getEffectivePolicies(Set
principals)}} does not include it. Obviously this ReadPolicy applies for every
set of principals.
However, for consistency and to avoid confusion the
{{NamedAccessControllPolicy}} should be included in the set if the editing
session has sufficient permission on any of the configured paths.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10132) Duplication in XPathConditionVisitor and ImpersonationImpl
[
https://issues.apache.org/jira/browse/OAK-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10132.
Fix Version/s: 1.50.0
Resolution: Fixed
> Duplication in XPathConditionVisitor and ImpersonationImpl
> --
>
> Key: OAK-10132
> URL: https://issues.apache.org/jira/browse/OAK-10132
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.50.0
>
>
> Both {{ImpersonationImpl}} and
> {{XPathConditionVisitor#visit(Condition.Impersonation condition)}} contain
> the same code to evaluate if a given principal can impersonate all users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10132) Duplication in XPathConditionVisitor and ImpersonationImpl
Angela Schreiber created OAK-10132:
--
Summary: Duplication in XPathConditionVisitor and ImpersonationImpl
Key: OAK-10132
URL: https://issues.apache.org/jira/browse/OAK-10132
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Angela Schreiber
Assignee: Angela Schreiber
Both {{ImpersonationImpl}} and
{{XPathConditionVisitor#visit(Condition.Impersonation condition)}} contain the
same code to evaluate if a given principal can impersonate all users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10131) ExternalGroupPrincipalProvider should return ItemBasedPrincipals if dynamic group option is enabled
[
https://issues.apache.org/jira/browse/OAK-10131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10131.
Resolution: Fixed
> ExternalGroupPrincipalProvider should return ItemBasedPrincipals if dynamic
> group option is enabled
> ---
>
> Key: OAK-10131
> URL: https://issues.apache.org/jira/browse/OAK-10131
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.50.0
>
>
> if dynamic-group option is enabled in the default sync configuration external
> group identities will be backed by a group in the repository.
> the {{ExternalGroupPrincipalProvider}} may therefore return instances of
> {{GroupPrincipal}} that also implement the {{ItemBasedPrinicipal}} interface
> with lazy evaluation of the path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10131) ExternalGroupPrincipalProvider should return ItemBasedPrincipals if dynamic group option is enabled
Angela Schreiber created OAK-10131:
--
Summary: ExternalGroupPrincipalProvider should return
ItemBasedPrincipals if dynamic group option is enabled
Key: OAK-10131
URL: https://issues.apache.org/jira/browse/OAK-10131
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
Assignee: Angela Schreiber
Fix For: 1.50.0
if dynamic-group option is enabled in the default sync configuration external
group identities will be backed by a group in the repository.
the {{ExternalGroupPrincipalProvider}} may therefore return instances of
{{GroupPrincipal}} that also implement the {{ItemBasedPrinicipal}} interface
with lazy evaluation of the path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10130) Add API to retrieve effective policies for a set of principals for a given path
Angela Schreiber created OAK-10130:
--
Summary: Add API to retrieve effective policies for a set of
principals for a given path
Key: OAK-10130
URL: https://issues.apache.org/jira/browse/OAK-10130
Project: Jackrabbit Oak
Issue Type: New Feature
Components: authorization-cug, authorization-principalbased, core,
jackrabbit-api, security
Reporter: Angela Schreiber
Assignee: Angela Schreiber
JCR and Jackrabbit API currently provide the following methods to retrieve
effective policies:
h4. javax.jcr.security.AccessControlManager
{code}
AccessControlPolicy[] getEffectivePolicies(String absPath)
throws PathNotFoundException, AccessDeniedException,
RepositoryException;
{code}
h4. org.apache.jackrabbit.api.security.JackrabbitAccessControlManager
{code}
AccessControlPolicy[] getEffectivePolicies(@NotNull Set
principals) throws AccessDeniedException, AccessControlException,
UnsupportedRepositoryOperationException, RepositoryException;
{code}
h4. The missing piece
What is not possible today however is retrieving the effective policies for a
given set of principals that take effect on a particular path. While consumers
of the method provided {{JackrabbitAccessControlManager}} might be able to
guess where the policies take effect and thus filter the accordingly, this
should not be taken for granted and it would be better if there was an API to
retrieve the filtered set as the implementations of
{{JackrabbitAccessControlManager}} are able to determine the effect (instead of
guessing) in particular when restrictions are present.
I would there suggest to introduce in {{JackrabbitAccessControlManager}}
something like
{code}
Iterator getEffectivePolicies(@NotNull Set
principals, @Nullable String absPath) throws AccessDeniedException,
AccessControlException, UnsupportedRepositoryOperationException,
RepositoryException;
{code}
cc: [~cschneider] who highlighted the issue to me while investigating an issue
with Sling Content Distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10121) Extend SessionImpl.hasCapability to cover access control write operations
[ https://issues.apache.org/jira/browse/OAK-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10121. Resolution: Fixed > Extend SessionImpl.hasCapability to cover access control write operations > - > > Key: OAK-10121 > URL: https://issues.apache.org/jira/browse/OAK-10121 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.50.0 > > > for building access control related UIs there is currently no way to > determine if ac mgt operations on a given node would fail because that node > is owned by a read-only immutable mount. > for other methods [~rombert] expanded Session.hasCapability to take mounts > into account. i would suggest that we extend the API method to also cover > setPolicy and removePolicy operations called on the AccessControlManager. > this would allow to determine if altering access control content is possible > or prevented (either by lack of permission or due to a readonly mount). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10120) SessionImpl.hasCapability is prone to NPE
[ https://issues.apache.org/jira/browse/OAK-10120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10120. Resolution: Fixed > SessionImpl.hasCapability is prone to NPE > - > > Key: OAK-10120 > URL: https://issues.apache.org/jira/browse/OAK-10120 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.50.0 > > > when calling Session.hasCapability on a node with operation 'addNode' but > passing no or an invalid arguments the call will fail with NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10069) Best practices on how to setup access control external identities
[ https://issues.apache.org/jira/browse/OAK-10069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10069. Fix Version/s: 1.50.0 Resolution: Fixed > Best practices on how to setup access control external identities > - > > Key: OAK-10069 > URL: https://issues.apache.org/jira/browse/OAK-10069 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: auth-external, doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.50.0 > > > I have recently seen troublesome patterns for defining access control content > for external identities (specially groups). the oak documentation should > provide guidelines on how to do this. > cc: [~jhoh] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10120) SessionImpl.hasCapability is prone to NPE
[ https://issues.apache.org/jira/browse/OAK-10120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10120: --- Fix Version/s: 1.50.0 > SessionImpl.hasCapability is prone to NPE > - > > Key: OAK-10120 > URL: https://issues.apache.org/jira/browse/OAK-10120 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.50.0 > > > when calling Session.hasCapability on a node with operation 'addNode' but > passing no or an invalid arguments the call will fail with NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10120) SessionImpl.hasCapability is prone to NPE
[ https://issues.apache.org/jira/browse/OAK-10120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10120: -- Assignee: Angela Schreiber > SessionImpl.hasCapability is prone to NPE > - > > Key: OAK-10120 > URL: https://issues.apache.org/jira/browse/OAK-10120 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > > when calling Session.hasCapability on a node with operation 'addNode' but > passing no or an invalid arguments the call will fail with NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10121) Extend SessionImpl.hasCapability to cover access control write operations
[ https://issues.apache.org/jira/browse/OAK-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10121: --- Fix Version/s: 1.50.0 > Extend SessionImpl.hasCapability to cover access control write operations > - > > Key: OAK-10121 > URL: https://issues.apache.org/jira/browse/OAK-10121 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.50.0 > > > for building access control related UIs there is currently no way to > determine if ac mgt operations on a given node would fail because that node > is owned by a read-only immutable mount. > for other methods [~rombert] expanded Session.hasCapability to take mounts > into account. i would suggest that we extend the API method to also cover > setPolicy and removePolicy operations called on the AccessControlManager. > this would allow to determine if altering access control content is possible > or prevented (either by lack of permission or due to a readonly mount). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10121) Extend SessionImpl.hasCapability to cover access control write operations
Angela Schreiber created OAK-10121: -- Summary: Extend SessionImpl.hasCapability to cover access control write operations Key: OAK-10121 URL: https://issues.apache.org/jira/browse/OAK-10121 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Angela Schreiber for building access control related UIs there is currently no way to determine if ac mgt operations on a given node would fail because that node is owned by a read-only immutable mount. for other methods [~rombert] expanded Session.hasCapability to take mounts into account. i would suggest that we extend the API method to also cover setPolicy and removePolicy operations called on the AccessControlManager. this would allow to determine if altering access control content is possible or prevented (either by lack of permission or due to a readonly mount). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10121) Extend SessionImpl.hasCapability to cover access control write operations
[ https://issues.apache.org/jira/browse/OAK-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10121: -- Assignee: Angela Schreiber > Extend SessionImpl.hasCapability to cover access control write operations > - > > Key: OAK-10121 > URL: https://issues.apache.org/jira/browse/OAK-10121 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > for building access control related UIs there is currently no way to > determine if ac mgt operations on a given node would fail because that node > is owned by a read-only immutable mount. > for other methods [~rombert] expanded Session.hasCapability to take mounts > into account. i would suggest that we extend the API method to also cover > setPolicy and removePolicy operations called on the AccessControlManager. > this would allow to determine if altering access control content is possible > or prevented (either by lack of permission or due to a readonly mount). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10120) SessionImpl.hasCapability is prone to NPE
Angela Schreiber created OAK-10120: -- Summary: SessionImpl.hasCapability is prone to NPE Key: OAK-10120 URL: https://issues.apache.org/jira/browse/OAK-10120 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Angela Schreiber when calling Session.hasCapability on a node with operation 'addNode' but passing no or an invalid arguments the call will fail with NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10117) oak-run console does not start up - CommandNameCompleter construction fails
[ https://issues.apache.org/jira/browse/OAK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690511#comment-17690511 ] Angela Schreiber commented on OAK-10117: [~reschke], agreed what can i say > oak-run console does not start up - CommandNameCompleter construction fails > --- > > Key: OAK-10117 > URL: https://issues.apache.org/jira/browse/OAK-10117 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Labels: candidate_oak_1_22 > Fix For: 1.50.0 > > > FATAL : groovy.lang.GroovyRuntimeException: Could not find matching > constructor for: > org.codehaus.groovy.tools.shell.completion.CommandNameCompleter(org.codehaus.groovy.tools.shell.CommandRegistry) > groovy.lang.GroovyRuntimeException: Could not find matching constructor for: > org.codehaus.groovy.tools.shell.completion.CommandNameCompleter(org.codehaus.groovy.tools.shell.CommandRegistry) > at > groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1749) > at > groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1556) > at > org.codehaus.groovy.runtime.callsite.MetaClassConstructorSite.callConstructor(MetaClassConstructorSite.java:46) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:249) > at > org.apache.jackrabbit.oak.console.commands.OakHelpCommand.createCompleters(OakHelpCommand.groovy:41) > at > org.codehaus.groovy.tools.shell.CommandSupport.getCompleter(CommandSupport.groovy:143) > at jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown > Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323) > at > org.codehaus.groovy.runtime.metaclass.MethodMetaProperty$GetBeanMethodMetaProperty.getProperty(MethodMetaProperty.java:76) > at > org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.getProperty(GetEffectivePogoPropertySite.java:85) > at > org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.callGetProperty(GetEffectivePogoPropertySite.java:45) > at > org.codehaus.groovy.tools.shell.CommandsMultiCompleter.add(InteractiveShellRunner.groovy:179) > at > org.codehaus.groovy.tools.shell.CommandsMultiCompleter$add.call(Unknown > Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) > at > org.codehaus.groovy.tools.shell.CommandsMultiCompleter$add.call(Unknown > Source) > at > org.codehaus.groovy.tools.shell.InteractiveShellRunner.run(InteractiveShellRunner.groovy:89) > at java_lang_Runnable$run.call(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119) > at > org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run(GroovyConsole.groovy:265) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43) > at > org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:190) > at > org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:58) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:156) > at >
[jira] [Commented] (OAK-10115) Build Jackrabbit/jackrabbit-oak-trunk #827 failed
[ https://issues.apache.org/jira/browse/OAK-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17689751#comment-17689751 ] Angela Schreiber commented on OAK-10115: odd... commit https://github.com/apache/jackrabbit-oak/commit/9ad1ebaa022802f3851974af2c3848ccb0fb23b0 only modified org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager. don't see how that can impact branch coverage in org.apache.jackrabbit.oak.security.authentication.token. > Build Jackrabbit/jackrabbit-oak-trunk #827 failed > - > > Key: OAK-10115 > URL: https://issues.apache.org/jira/browse/OAK-10115 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #827 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #827|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/827/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/827/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10107) update javdoc of class org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager
[ https://issues.apache.org/jira/browse/OAK-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10107. Fix Version/s: 1.50.0 Resolution: Fixed > update javdoc of class > org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager > > > Key: OAK-10107 > URL: https://issues.apache.org/jira/browse/OAK-10107 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: core, docs >Reporter: Juerg Meier >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.50.0 > > > javadoc requires update as it currently inherits from > [ReadOnlyNodeTypeManager|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/nodetype/ReadOnlyNodeTypeManager.html]. > Consequently, methods registerNodeType() and unregisterNodeType() are said to > throw an UnsupportedRepositoryOperationException, which is not the case. This > methods work according to the JCR spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10107) update javdoc of class org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager
[ https://issues.apache.org/jira/browse/OAK-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10107: -- Assignee: Angela Schreiber > update javdoc of class > org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager > > > Key: OAK-10107 > URL: https://issues.apache.org/jira/browse/OAK-10107 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: core, docs >Reporter: Juerg Meier >Assignee: Angela Schreiber >Priority: Minor > > javadoc requires update as it currently inherits from > [ReadOnlyNodeTypeManager|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/nodetype/ReadOnlyNodeTypeManager.html]. > Consequently, methods registerNodeType() and unregisterNodeType() are said to > throw an UnsupportedRepositoryOperationException, which is not the case. This > methods work according to the JCR spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10107) update javdoc of class org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager
[ https://issues.apache.org/jira/browse/OAK-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10107: --- Component/s: core > update javdoc of class > org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager > > > Key: OAK-10107 > URL: https://issues.apache.org/jira/browse/OAK-10107 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: core, docs >Reporter: Juerg Meier >Priority: Minor > > javadoc requires update as it currently inherits from > [ReadOnlyNodeTypeManager|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/nodetype/ReadOnlyNodeTypeManager.html]. > Consequently, methods registerNodeType() and unregisterNodeType() are said to > throw an UnsupportedRepositoryOperationException, which is not the case. This > methods work according to the JCR spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10099) DynamicSyncContext: skip warning for everyone group
[ https://issues.apache.org/jira/browse/OAK-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10099. Fix Version/s: 1.50.0 Resolution: Fixed > DynamicSyncContext: skip warning for everyone group > --- > > Key: OAK-10099 > URL: https://issues.apache.org/jira/browse/OAK-10099 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.50.0 > > > upon dynamic membership import the DynamicSyncContext will log a warning for > unexpected membership with groups owned by a different IDP but ignoring > automembership. > if a group exists for the everyone principal it should equally be ignored > instead of logging a warning. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10099) DynamicSyncContext: skip warning for everyone group
[ https://issues.apache.org/jira/browse/OAK-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10099: --- Component/s: auth-external > DynamicSyncContext: skip warning for everyone group > --- > > Key: OAK-10099 > URL: https://issues.apache.org/jira/browse/OAK-10099 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > > upon dynamic membership import the DynamicSyncContext will log a warning for > unexpected membership with groups owned by a different IDP but ignoring > automembership. > if a group exists for the everyone principal it should equally be ignored > instead of logging a warning. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10099) DynamicSyncContext: skip warning for everyone group
Angela Schreiber created OAK-10099: -- Summary: DynamicSyncContext: skip warning for everyone group Key: OAK-10099 URL: https://issues.apache.org/jira/browse/OAK-10099 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Angela Schreiber Assignee: Angela Schreiber upon dynamic membership import the DynamicSyncContext will log a warning for unexpected membership with groups owned by a different IDP but ignoring automembership. if a group exists for the everyone principal it should equally be ignored instead of logging a warning. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-7015) Deprecate TreeFactory/RootFactory
[
https://issues.apache.org/jira/browse/OAK-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682914#comment-17682914
]
Angela Schreiber commented on OAK-7015:
---
[~reschke], as discussed the downstream project is using
{{TreeFactory#createTree(@NotNull NodeBuilder builder)}} for which there is no
replacement and passes the Tree to {{IndexDefinitionBuilder#build(Tree tree)}}.
I quickly check remaining usages in the oak code base and they are as well
limited to indexing/search.
I would recommend to clean up the index/search code and make sure the builder
consistently operates on NodeStates/NodeBuilder objects. in this particular
case the code looks as follows:
{code}
indexBuilder.build(TreeFactory.createTree(luceneIdxBuilder));
{code}
which is a bit odd. it ignores the return value of the build method and the
original object is a builder. so the extra conversion to Tree doesn't make
sense to me. in particular as a tree should always be connected to a parent,
which in this case is not possible.
{{IndexDefinitionBuilder.build(Tree)}} in turn:
{code}
public Tree build(Tree tree) {
NodeStateCopyUtils.copyToTree(this.build(), tree);
return tree;
}
{code}
so again mixing NodeBuilder, NodeState, Tree. i would recommend to clean that
up and replace it with methods that take a NodeBuilder for consistency.
can you create a bug for that?
> Deprecate TreeFactory/RootFactory
> -
>
> Key: OAK-7015
> URL: https://issues.apache.org/jira/browse/OAK-7015
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.7.12, 1.8.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-7015) Deprecate TreeFactory/RootFactory
[
https://issues.apache.org/jira/browse/OAK-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682594#comment-17682594
]
Angela Schreiber commented on OAK-7015:
---
hi [~reschke] , the proper replacement would be {{RootProvider}} and
{{TreeProvider}} which are injected as OSGi components.
what are the exact circumstances of the usage? test setup or production code?
> Deprecate TreeFactory/RootFactory
> -
>
> Key: OAK-7015
> URL: https://issues.apache.org/jira/browse/OAK-7015
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.7.12, 1.8.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10087) TypeEditor: constraint exception for invalid child node should contain that node's effective type
[ https://issues.apache.org/jira/browse/OAK-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10087: --- Summary: TypeEditor: constraint exception for invalid child node should contain that node's effective type (was: TypeEditor: constraint exception for invalid chiuld node should contain that node's effective type) > TypeEditor: constraint exception for invalid child node should contain that > node's effective type > - > > Key: OAK-10087 > URL: https://issues.apache.org/jira/browse/OAK-10087 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_22 > Fix For: 1.50.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10082) Group.getMembers() needs to resolve inherited members of dynamic groups
[
https://issues.apache.org/jira/browse/OAK-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10082.
Resolution: Fixed
> Group.getMembers() needs to resolve inherited members of dynamic groups
> ---
>
> Key: OAK-10082
> URL: https://issues.apache.org/jira/browse/OAK-10082
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> while {{GroupImpl.getMembers}} works for dynamic groups, it fails to resolve
> inherited dynamic members of. one case where this becomes apparent is a setup
> like described in OAK-10067.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10082) Group.getMembers() needs to resolve inherited members of dynamic groups
[
https://issues.apache.org/jira/browse/OAK-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10082:
---
Fix Version/s: 1.50.0
> Group.getMembers() needs to resolve inherited members of dynamic groups
> ---
>
> Key: OAK-10082
> URL: https://issues.apache.org/jira/browse/OAK-10082
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.50.0
>
>
> while {{GroupImpl.getMembers}} works for dynamic groups, it fails to resolve
> inherited dynamic members of. one case where this becomes apparent is a setup
> like described in OAK-10067.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10082) Group.getMembers() needs to resolve inherited members of dynamic groups
Angela Schreiber created OAK-10082:
--
Summary: Group.getMembers() needs to resolve inherited members of
dynamic groups
Key: OAK-10082
URL: https://issues.apache.org/jira/browse/OAK-10082
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Angela Schreiber
Assignee: Angela Schreiber
while {{GroupImpl.getMembers}} works for dynamic groups, it fails to resolve
inherited dynamic members of. one case where this becomes apparent is a setup
like described in OAK-10067.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10074) AutoMembershipProvider consistency with ExternalPrincipalProvider
[
https://issues.apache.org/jira/browse/OAK-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10074.
Fix Version/s: 1.48.0
Resolution: Fixed
> AutoMembershipProvider consistency with ExternalPrincipalProvider
> -
>
> Key: OAK-10074
> URL: https://issues.apache.org/jira/browse/OAK-10074
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.48.0
>
>
> upon compute effective group principals in {{ExternalPrincipalProvider}} the
> global {{group.automembership}} configuration is applied to all external
> identities.
> for consistency the same logic should be applied for
> {{AutoMembershipProvider.getMembers}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10074) AutoMembershipProvider consistency with ExternalPrincipalProvider
Angela Schreiber created OAK-10074:
--
Summary: AutoMembershipProvider consistency with
ExternalPrincipalProvider
Key: OAK-10074
URL: https://issues.apache.org/jira/browse/OAK-10074
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
Assignee: Angela Schreiber
upon compute effective group principals in {{ExternalPrincipalProvider}} the
global {{group.automembership}} configuration is applied to all external
identities.
for consistency the same logic should be applied for
{{AutoMembershipProvider.getMembers}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10073) Additional tests combining dynamic groups and automembership
[ https://issues.apache.org/jira/browse/OAK-10073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10073. Resolution: Fixed > Additional tests combining dynamic groups and automembership > > > Key: OAK-10073 > URL: https://issues.apache.org/jira/browse/OAK-10073 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10073) Additional tests combining dynamic groups and automembership
Angela Schreiber created OAK-10073: -- Summary: Additional tests combining dynamic groups and automembership Key: OAK-10073 URL: https://issues.apache.org/jira/browse/OAK-10073 Project: Jackrabbit Oak Issue Type: Task Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber Fix For: 1.48.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10071) Consistently filter duplicate authorizables in iterators
[ https://issues.apache.org/jira/browse/OAK-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10071. Fix Version/s: 1.48.0 Resolution: Fixed > Consistently filter duplicate authorizables in iterators > > > Key: OAK-10071 > URL: https://issues.apache.org/jira/browse/OAK-10071 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > iterators returned by membership related methods (like Authorizable.memberof > and Group.getMembers and their declared variants) should consistently filter > duplicates. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10071) Consistently filter duplicate authorizables in iterators
Angela Schreiber created OAK-10071: -- Summary: Consistently filter duplicate authorizables in iterators Key: OAK-10071 URL: https://issues.apache.org/jira/browse/OAK-10071 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Angela Schreiber Assignee: Angela Schreiber Fix For: 1.48.0 iterators returned by membership related methods (like Authorizable.memberof and Group.getMembers and their declared variants) should consistently filter duplicates. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10067) ExternalGroupPrincipalProvider does not resolve inherited groups that cross IDP boundaries
[ https://issues.apache.org/jira/browse/OAK-10067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10067. Fix Version/s: 1.48.0 Resolution: Fixed > ExternalGroupPrincipalProvider does not resolve inherited groups that cross > IDP boundaries > -- > > Key: OAK-10067 > URL: https://issues.apache.org/jira/browse/OAK-10067 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > if a dynamic group is member of group that does not belong to the same IDP > (such as e.g. a local group that is not listed in automembership), the > ExternalGroupPrincipalProvider will fail to resolve the inherited membership > for external users. > Note that resolving the membership of the dynamic group itself works, but for > external members of that dynamic group (i.e. external users) the IDP-boundary > crossing membership will not be resolved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10067) ExternalGroupPrincipalProvider does not resolve inherited groups that cross IDP boundaries
[ https://issues.apache.org/jira/browse/OAK-10067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10067: --- Summary: ExternalGroupPrincipalProvider does not resolve inherited groups that cross IDP boundaries (was: ExternalGroupPrincipalProvider#getMembership does not resolve inherited groups that cross IDP boundaries) > ExternalGroupPrincipalProvider does not resolve inherited groups that cross > IDP boundaries > -- > > Key: OAK-10067 > URL: https://issues.apache.org/jira/browse/OAK-10067 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > if a dynamic group is member of group that does not belong to the same IDP > (such as e.g. a local group that is not listed in automembership), the > ExternalGroupPrincipalProvider will fail to resolve the inherited membership > for external users. > Note that resolving the membership of the dynamic group itself works, but for > external members of that dynamic group (i.e. external users) the IDP-boundary > crossing membership will not be resolved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10069) Best practices on how to setup access control external identities
[ https://issues.apache.org/jira/browse/OAK-10069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10069: --- Fix Version/s: 1.48.0 > Best practices on how to setup access control external identities > - > > Key: OAK-10069 > URL: https://issues.apache.org/jira/browse/OAK-10069 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: auth-external, doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > I have recently seen troublesome patterns for defining access control content > for external identities (specially groups). the oak documentation should > provide guidelines on how to do this. > cc: [~jhoh] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10069) Best practices on how to setup access control external identities
Angela Schreiber created OAK-10069: -- Summary: Best practices on how to setup access control external identities Key: OAK-10069 URL: https://issues.apache.org/jira/browse/OAK-10069 Project: Jackrabbit Oak Issue Type: Documentation Components: auth-external, doc Reporter: Angela Schreiber Assignee: Angela Schreiber I have recently seen troublesome patterns for defining access control content for external identities (specially groups). the oak documentation should provide guidelines on how to do this. cc: [~jhoh] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10067) ExternalGroupPrincipalProvider#getMembership does not resolve inherited groups that cross IDP boundaries
Angela Schreiber created OAK-10067: -- Summary: ExternalGroupPrincipalProvider#getMembership does not resolve inherited groups that cross IDP boundaries Key: OAK-10067 URL: https://issues.apache.org/jira/browse/OAK-10067 Project: Jackrabbit Oak Issue Type: Bug Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber if a dynamic group is member of group that does not belong to the same IDP (such as e.g. a local group that is not listed in automembership), the ExternalGroupPrincipalProvider will fail to resolve the inherited membership for external users. Note that resolving the membership of the dynamic group itself works, but for external members of that dynamic group (i.e. external users) the IDP-boundary crossing membership will not be resolved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10061) WARN when for an external group a local group with the same name is already present
[ https://issues.apache.org/jira/browse/OAK-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10061: --- Fix Version/s: 1.48.0 > WARN when for an external group a local group with the same name is already > present > --- > > Key: OAK-10061 > URL: https://issues.apache.org/jira/browse/OAK-10061 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Affects Versions: 1.46.0, 1.22.13 >Reporter: Joerg Hoh >Priority: Major > Fix For: 1.48.0 > > > When a local group named "group" is present, any sync of an external group > (from an IDP) with the same name fails silently. > There should be a WARN like this: "Cannot create externally managed group > named XX because a local group with the same name already exists; principal Y > will miss group memberships" in the logs to make this problem obvious and to > ease the debugging of this situation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10061) WARN when for an external group a local group with the same name is already present
[ https://issues.apache.org/jira/browse/OAK-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10061. Assignee: Angela Schreiber Resolution: Fixed > WARN when for an external group a local group with the same name is already > present > --- > > Key: OAK-10061 > URL: https://issues.apache.org/jira/browse/OAK-10061 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Affects Versions: 1.46.0, 1.22.13 >Reporter: Joerg Hoh >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > When a local group named "group" is present, any sync of an external group > (from an IDP) with the same name fails silently. > There should be a WARN like this: "Cannot create externally managed group > named XX because a local group with the same name already exists; principal Y > will miss group memberships" in the logs to make this problem obvious and to > ease the debugging of this situation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10060) Add ability to configure which principals could break a jcr:lock
[ https://issues.apache.org/jira/browse/OAK-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10060: --- Fix Version/s: 1.48.0 > Add ability to configure which principals could break a jcr:lock > > > Key: OAK-10060 > URL: https://issues.apache.org/jira/browse/OAK-10060 > Project: Jackrabbit Oak > Issue Type: Story > Components: jcr >Reporter: Gilles Knobloch >Priority: Major > Fix For: 1.48.0 > > > Today, the "admin" user only can break a lock. > It would help if we'd have the ability to configure more users/groups who > would be able to do this, and not depend on a single super user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10060) Add ability to configure which principals could break a jcr:lock
[ https://issues.apache.org/jira/browse/OAK-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656681#comment-17656681 ] Angela Schreiber commented on OAK-10060: hi [~gknob], thanks for reporting this improvement. you probably are aware of the fact that JCR locking in oak is deprecated. but i admit that the hardcoded lock-break for the admin isn't particularly nice specially in the light of Adobe AEMaaCS. since the lock feature is not actively maintained by the oak team it would be good though if your team could come up with a contribution (preferably a PR in git). > Add ability to configure which principals could break a jcr:lock > > > Key: OAK-10060 > URL: https://issues.apache.org/jira/browse/OAK-10060 > Project: Jackrabbit Oak > Issue Type: Story > Components: jcr >Reporter: Gilles Knobloch >Priority: Major > > Today, the "admin" user only can break a lock. > It would help if we'd have the ability to configure more users/groups who > would be able to do this, and not depend on a single super user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10011) Configure SonarClould for Oak
[ https://issues.apache.org/jira/browse/OAK-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646463#comment-17646463 ] Angela Schreiber commented on OAK-10011: [~ngupta], yesdone :-) > Configure SonarClould for Oak > - > > Key: OAK-10011 > URL: https://issues.apache.org/jira/browse/OAK-10011 > Project: Jackrabbit Oak > Issue Type: Task > Components: continuous integration >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.46.0 > > > [~mreutegg], [~ngupta] with basic sonarcloud integration setup (OAK-10009), > we can now fine tune the analysis and configure the main-branch analysis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10011) Configure SonarClould for Oak
[ https://issues.apache.org/jira/browse/OAK-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10011. Resolution: Done > Configure SonarClould for Oak > - > > Key: OAK-10011 > URL: https://issues.apache.org/jira/browse/OAK-10011 > Project: Jackrabbit Oak > Issue Type: Task > Components: continuous integration >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.46.0 > > > [~mreutegg], [~ngupta] with basic sonarcloud integration setup (OAK-10009), > we can now fine tune the analysis and configure the main-branch analysis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643153#comment-17643153
]
Angela Schreiber commented on OAK-9956:
---
hi [~reschke], [~kwin], i would be quite reluctant to fundamentally change the
behavior for the sake of compliance if it was already wrong in the reference
implementation in jackrabbit and for all the years we run oak in production.
this may lead to regressions for edge cases that will be hard to track and i
don't really see a huge benefit in it. changing the exception to
{{RepositoryException}} to make it not misleading looks ok though.
cc: [~mreutegg]
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-9956.diff
>
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10000) Build Jackrabbit/jackrabbit-oak-trunk #712 failed
[
https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-1.
Resolution: Fixed
> Build Jackrabbit/jackrabbit-oak-trunk #712 failed
> -
>
> Key: OAK-1
> URL: https://issues.apache.org/jira/browse/OAK-1
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #712 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk
> #712|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/]
> [console
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/console]
> {noformat}
> [WARNING] Files with unapproved licenses:
> .github/workflows/build.yml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10000) Build Jackrabbit/jackrabbit-oak-trunk #712 failed
[
https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638544#comment-17638544
]
Angela Schreiber edited comment on OAK-1 at 11/25/22 7:51 AM:
--
[~mreutegg], checked the latest log: no more unapproved licences but
elastic-search tests failing. i am resolving this ticket as the problem stated
in the description has been fixed.
was (Author: anchela):
[~mreutegg], checked the latest log: no more unapproved licences but
elastic-search tests failing.
> Build Jackrabbit/jackrabbit-oak-trunk #712 failed
> -
>
> Key: OAK-1
> URL: https://issues.apache.org/jira/browse/OAK-1
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #712 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk
> #712|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/]
> [console
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/console]
> {noformat}
> [WARNING] Files with unapproved licenses:
> .github/workflows/build.yml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10000) Build Jackrabbit/jackrabbit-oak-trunk #712 failed
[
https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638544#comment-17638544
]
Angela Schreiber commented on OAK-1:
[~mreutegg], checked the latest log: no more unapproved licences but
elastic-search tests failing.
> Build Jackrabbit/jackrabbit-oak-trunk #712 failed
> -
>
> Key: OAK-1
> URL: https://issues.apache.org/jira/browse/OAK-1
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #712 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk
> #712|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/]
> [console
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/console]
> {noformat}
> [WARNING] Files with unapproved licenses:
> .github/workflows/build.yml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10000) Build Jackrabbit/jackrabbit-oak-trunk #712 failed
[
https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638355#comment-17638355
]
Angela Schreiber commented on OAK-1:
[~mreutegg], i believe i added the same header as is present with _stale.yml_
in the same folder. do you know if it rather needs to be excluded from the
rat-plugin? i checked in the main pom.xml and didn't see a rule for the
stale.yml file. hmmm
> Build Jackrabbit/jackrabbit-oak-trunk #712 failed
> -
>
> Key: OAK-1
> URL: https://issues.apache.org/jira/browse/OAK-1
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #712 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk
> #712|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/]
> [console
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/console]
> {noformat}
> [WARNING] Files with unapproved licenses:
> .github/workflows/build.yml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10000) Build Jackrabbit/jackrabbit-oak-trunk #712 failed
[
https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638323#comment-17638323
]
Angela Schreiber commented on OAK-1:
[~mreutegg], sorry my bad. i will add it
> Build Jackrabbit/jackrabbit-oak-trunk #712 failed
> -
>
> Key: OAK-1
> URL: https://issues.apache.org/jira/browse/OAK-1
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #712 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk
> #712|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/]
> [console
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/712/console]
> {noformat}
> [WARNING] Files with unapproved licenses:
> .github/workflows/build.yml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10012) Redundant modifier in oak-jackrabbit-api
[
https://issues.apache.org/jira/browse/OAK-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10012:
---
Summary: Redundant modifier in oak-jackrabbit-api (was: Redundant
modifiers in oak-jackrabbit-api)
> Redundant modifier in oak-jackrabbit-api
>
>
> Key: OAK-10012
> URL: https://issues.apache.org/jira/browse/OAK-10012
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jackrabbit-api
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Trivial
>
> trivial improvement to get rid of redundant modifiers in
> {{JackrabbitAccessControlManager}} and {{JackrabbitRepository}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10012) Redundant modifier in oak-jackrabbit-api
[
https://issues.apache.org/jira/browse/OAK-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10012.
Fix Version/s: 1.46.0
Resolution: Fixed
> Redundant modifier in oak-jackrabbit-api
>
>
> Key: OAK-10012
> URL: https://issues.apache.org/jira/browse/OAK-10012
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jackrabbit-api
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Trivial
> Fix For: 1.46.0
>
>
> trivial improvement to get rid of redundant modifiers in
> {{JackrabbitAccessControlManager}} and {{JackrabbitRepository}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10012) Redundant modifiers in oak-jackrabbit-api
Angela Schreiber created OAK-10012:
--
Summary: Redundant modifiers in oak-jackrabbit-api
Key: OAK-10012
URL: https://issues.apache.org/jira/browse/OAK-10012
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jackrabbit-api
Reporter: Angela Schreiber
Assignee: Angela Schreiber
trivial improvement to get rid of redundant modifiers in
{{JackrabbitAccessControlManager}} and {{JackrabbitRepository}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10011) Configure SonarClould for Oak
Angela Schreiber created OAK-10011: -- Summary: Configure SonarClould for Oak Key: OAK-10011 URL: https://issues.apache.org/jira/browse/OAK-10011 Project: Jackrabbit Oak Issue Type: Task Components: continuous integration Reporter: Angela Schreiber Assignee: Angela Schreiber Fix For: 1.46.0 [~mreutegg], [~ngupta] with basic sonarcloud integration setup (OAK-10009), we can now fine tune the analysis and configure the main-branch analysis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10009) Enable SonarClould for Oak
[ https://issues.apache.org/jira/browse/OAK-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10009. Fix Version/s: 1.46.0 Resolution: Fixed > Enable SonarClould for Oak > -- > > Key: OAK-10009 > URL: https://issues.apache.org/jira/browse/OAK-10009 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.46.0 > > > followup for INFRA-23854 to configure sonarcloud integration with the oak > see > https://sonarcloud.io/project/configuration?id=apache_jackrabbit-oak=GitHubActions > cc: [~mreutegg], [~ngupta] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10009) Enable SonarClould for Oak
[ https://issues.apache.org/jira/browse/OAK-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10009: --- Description: followup for INFRA-23854 to configure sonarcloud integration with the oak see https://sonarcloud.io/project/configuration?id=apache_jackrabbit-oak=GitHubActions cc: [~mreutegg], [~ngupta] was: followup for INFRA-23854 to configure sonarcloud integration with the oak cc: [~mreutegg], [~ngupta] > Enable SonarClould for Oak > -- > > Key: OAK-10009 > URL: https://issues.apache.org/jira/browse/OAK-10009 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > followup for INFRA-23854 to configure sonarcloud integration with the oak > see > https://sonarcloud.io/project/configuration?id=apache_jackrabbit-oak=GitHubActions > cc: [~mreutegg], [~ngupta] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10009) Enable SonarClould for Oak
Angela Schreiber created OAK-10009: -- Summary: Enable SonarClould for Oak Key: OAK-10009 URL: https://issues.apache.org/jira/browse/OAK-10009 Project: Jackrabbit Oak Issue Type: Task Reporter: Angela Schreiber Assignee: Angela Schreiber followup for INFRA-23854 to configure sonarcloud integration with the oak cc: [~mreutegg], [~ngupta] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10001) Bump up minimal Java version to 11
[ https://issues.apache.org/jira/browse/OAK-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635374#comment-17635374 ] Angela Schreiber commented on OAK-10001: i would do it asap so, if it's easy doable i would do it for 1.46. it takes more time, it should not delay a release for it. > Bump up minimal Java version to 11 > -- > > Key: OAK-10001 > URL: https://issues.apache.org/jira/browse/OAK-10001 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Active support for Java 8 ended a few months ago (see > [https://endoflife.date/java]). > Java 11 has been available for four years, and offers various improvements > (in particular, it contains extensions that may help in avoiding use of Guava > (see OAK-7182)). > (Note that even Java 11 will be out of active support in a few months - so a > subsequent update to the next LTS release - Java 17 - is not that far away). > Potential downsides: > - backports to 1.22 might become harder (1.8 will be EOLd next spring > anyway). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10001) Bump up minimal Java version to 11
[ https://issues.apache.org/jira/browse/OAK-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634858#comment-17634858 ] Angela Schreiber commented on OAK-10001: agreed. > Bump up minimal Java version to 11 > -- > > Key: OAK-10001 > URL: https://issues.apache.org/jira/browse/OAK-10001 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Active support for Java 8 ended a few months ago (see > https://endoflife.date/java). > Java 11 has been available for four years, and offers various improvements > (in particular, it contains extensions that may help in avoiding use of Guava > (see OAK-7182). > (Note that even Java 11 will be out of active support in a few months - so a > subsequent update to the next LTS release - Java 17 - is not that far away). > Potential downsides: > - backports to 1.22 might become harder (1.8 will be EOLd next spring anyway). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10001) Bump up minimal Java version to 11
[
https://issues.apache.org/jira/browse/OAK-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634787#comment-17634787
]
Angela Schreiber commented on OAK-10001:
+1
regarding:
{quote}
backports to 1.22 might become harder (1.8 will be EOLd next spring anyway).
{quote}
it's already next to impossible for certain bug fixes due to public api
involvement for several backport requests i received. i feel we are at the
point where backporting non-critical bugs should be avoided and consumers
should be encouraged to upgrade to the latest oak.
> Bump up minimal Java version to 11
> --
>
> Key: OAK-10001
> URL: https://issues.apache.org/jira/browse/OAK-10001
> Project: Jackrabbit Oak
> Issue Type: New Feature
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> Active support for Java 8 ended a few months ago (see
> https://endoflife.date/java).
> Java 11 has been available for four years, and offers various improvements
> (in particular, it contains extensions that may help in avoiding use of Guava
> (see OAK-7182).
> (Note that even Java 11 will be out of active support in a few months - so a
> subsequent update to the next LTS release - Java 17 - is not that far away).
> Potential downsides:
> - backports to 1.22 might become harder (1.8 will be EOLd next spring anyway).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630254#comment-17630254 ] Angela Schreiber commented on OAK-7182: --- [~reschke], sounds like a reasonable plan to me. one more thing: is there anything we can do to prevent introducing new leakages as it happened again in the segment-tar code? also: is the segment team aware of this ([~miroslav])? > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9974) permission eval: entries are evaluated in reverse order
[ https://issues.apache.org/jira/browse/OAK-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-9974. --- Fix Version/s: 1.46.0 Resolution: Fixed > permission eval: entries are evaluated in reverse order > --- > > Key: OAK-9974 > URL: https://issues.apache.org/jira/browse/OAK-9974 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.46.0 > > > [~rma61...@adobe.com] spotted that section 'Default Permission Evaluation in > Detail' of the oak documentation is misleading about the order of evaluation > of access control entries. it should mention that it's evaluated in reverse > order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-9974) permission eval: entries are evaluated in reverse order
Angela Schreiber created OAK-9974: - Summary: permission eval: entries are evaluated in reverse order Key: OAK-9974 URL: https://issues.apache.org/jira/browse/OAK-9974 Project: Jackrabbit Oak Issue Type: Documentation Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber [~rma61...@adobe.com] spotted that section 'Default Permission Evaluation in Detail' of the oak documentation is misleading about the order of evaluation of access control entries. it should mention that it's evaluated in reverse order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9972) Create FAQ for dynamic sync
[ https://issues.apache.org/jira/browse/OAK-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-9972. --- Fix Version/s: 1.46.0 Resolution: Done > Create FAQ for dynamic sync > > > Key: OAK-9972 > URL: https://issues.apache.org/jira/browse/OAK-9972 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: auth-external, doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.46.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-9972) Create FAQ for dynamic sync
Angela Schreiber created OAK-9972: - Summary: Create FAQ for dynamic sync Key: OAK-9972 URL: https://issues.apache.org/jira/browse/OAK-9972 Project: Jackrabbit Oak Issue Type: Documentation Components: auth-external, doc Reporter: Angela Schreiber Assignee: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9970) Internal code calls LockManager.isLocked(String)
[
https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-9970.
---
Resolution: Fixed
> Internal code calls LockManager.isLocked(String)
>
>
> Key: OAK-9970
> URL: https://issues.apache.org/jira/browse/OAK-9970
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.46.0
>
>
> similar to OAK-9966 for {{Node.isLocked}} which calls
> {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
> to be resolved again from the absolute path, when it was already there for
> the {{Node}} object.
> the same applies for
> - version operations that check for the node being locked
> - import operation that checks for the target node being locked.
> NOTE: this pattern applies for all other lock related methods. but since JCR
> locking is not properly implemented, i suggest to focus on the
> {{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called
> frequently in code that is just performing regular writes.
> cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-9970) Internal code calls LockManager.isLocked(String)
[
https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reassigned OAK-9970:
-
Assignee: Angela Schreiber
> Internal code calls LockManager.isLocked(String)
>
>
> Key: OAK-9970
> URL: https://issues.apache.org/jira/browse/OAK-9970
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> similar to OAK-9966 for {{Node.isLocked}} which calls
> {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
> to be resolved again from the absolute path, when it was already there for
> the {{Node}} object.
> the same applies for
> - version operations that check for the node being locked
> - import operation that checks for the target node being locked.
> NOTE: this pattern applies for all other lock related methods. but since JCR
> locking is not properly implemented, i suggest to focus on the
> {{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called
> frequently in code that is just performing regular writes.
> cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9970) Internal code calls LockManager.isLocked(String)
[
https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-9970:
--
Fix Version/s: 1.46.0
> Internal code calls LockManager.isLocked(String)
>
>
> Key: OAK-9970
> URL: https://issues.apache.org/jira/browse/OAK-9970
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.46.0
>
>
> similar to OAK-9966 for {{Node.isLocked}} which calls
> {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
> to be resolved again from the absolute path, when it was already there for
> the {{Node}} object.
> the same applies for
> - version operations that check for the node being locked
> - import operation that checks for the target node being locked.
> NOTE: this pattern applies for all other lock related methods. but since JCR
> locking is not properly implemented, i suggest to focus on the
> {{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called
> frequently in code that is just performing regular writes.
> cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9970) Internal code calls LockManager.isLocked(String)
[
https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-9970:
--
Description:
similar to OAK-9966 for {{Node.isLocked}} which calls
{{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
to be resolved again from the absolute path, when it was already there for the
{{Node}} object.
the same applies for
- version operations that check for the node being locked
- import operation that checks for the target node being locked.
NOTE: this pattern applies for all other lock related methods. but since JCR
locking is not properly implemented, i suggest to focus on the
{{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called
frequently in code that is just performing regular writes.
cc: [~joerghoh]
was:
similar to OAK-9966 for {{Node.isLocked}} which calls
{{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
to be resolved again from the absolute path, when it was already there for the
{{Node}} object.
the same applies for
- version operations that check for the node being locked
- import operation that checks for the target node being locked.
NOTE: this pattern applies for all other lock related methods. but since JCR
locking is not properly implemented, i suggest to focus on the
{{Node.isLocked}} method, which is called frequently in code that is just
performing regular writes.
cc: [~joerghoh]
> Internal code calls LockManager.isLocked(String)
>
>
> Key: OAK-9970
> URL: https://issues.apache.org/jira/browse/OAK-9970
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Angela Schreiber
>Priority: Major
>
> similar to OAK-9966 for {{Node.isLocked}} which calls
> {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
> to be resolved again from the absolute path, when it was already there for
> the {{Node}} object.
> the same applies for
> - version operations that check for the node being locked
> - import operation that checks for the target node being locked.
> NOTE: this pattern applies for all other lock related methods. but since JCR
> locking is not properly implemented, i suggest to focus on the
> {{Node.isLocked}} and {{LockManager.isLocked}} methods, which are called
> frequently in code that is just performing regular writes.
> cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9970) Internal code calls LockManager.isLocked(String)
[
https://issues.apache.org/jira/browse/OAK-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-9970:
--
Description:
similar to OAK-9966 for {{Node.isLocked}} which calls
{{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
to be resolved again from the absolute path, when it was already there for the
{{Node}} object.
the same applies for
- version operations that check for the node being locked
- import operation that checks for the target node being locked.
NOTE: this pattern applies for all other lock related methods. but since JCR
locking is not properly implemented, i suggest to focus on the
{{Node.isLocked}} method, which is called frequently in code that is just
performing regular writes.
cc: [~joerghoh]
was:
similar to OAK-9966 for {{Node.isLocked}} which calls
{{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
to be resolved again from the absolute path, when it was already there for the
{{Node}} object.
NOTE: this pattern applies for all other lock related methods. but since JCR
locking is not properly implemented, i suggest to focus on the
{{Node.isLocked}} method, which is called frequently in code that is just
performing regular writes.
cc: [~joerghoh]
> Internal code calls LockManager.isLocked(String)
>
>
> Key: OAK-9970
> URL: https://issues.apache.org/jira/browse/OAK-9970
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Angela Schreiber
>Priority: Major
>
> similar to OAK-9966 for {{Node.isLocked}} which calls
> {{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
> to be resolved again from the absolute path, when it was already there for
> the {{Node}} object.
> the same applies for
> - version operations that check for the node being locked
> - import operation that checks for the target node being locked.
> NOTE: this pattern applies for all other lock related methods. but since JCR
> locking is not properly implemented, i suggest to focus on the
> {{Node.isLocked}} method, which is called frequently in code that is just
> performing regular writes.
> cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-9970) Internal code calls LockManager.isLocked(String)
Angela Schreiber created OAK-9970:
-
Summary: Internal code calls LockManager.isLocked(String)
Key: OAK-9970
URL: https://issues.apache.org/jira/browse/OAK-9970
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Angela Schreiber
similar to OAK-9966 for {{Node.isLocked}} which calls
{{LockManager.isLocked(String absPath)}}. This results in the {{Tree}} object
to be resolved again from the absolute path, when it was already there for the
{{Node}} object.
NOTE: this pattern applies for all other lock related methods. but since JCR
locking is not properly implemented, i suggest to focus on the
{{Node.isLocked}} method, which is called frequently in code that is just
performing regular writes.
cc: [~joerghoh]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
