[jira] [Created] (JCRVLT-347) Enable ignored principal-based ITs once Oak 1.18.0 is released
angela created JCRVLT-347: - Summary: Enable ignored principal-based ITs once Oak 1.18.0 is released Key: JCRVLT-347 URL: https://issues.apache.org/jira/browse/JCRVLT-347 Project: Jackrabbit FileVault Issue Type: Task Components: vlt Reporter: angela Assignee: angela the fix for JCRVLT-340 comes with 3 tests that are currently marked ignored due to their dependency to a fix that will be available with Oak 1.18.0. this issues serves as reminder to enable the affected test cases (all with ImportMode.REPLACE) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCRVLT-340.
---
Resolution: Fixed
Fix Version/s: 3.2.10
Committed revision 1864011.
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 3.2.10
>
> Attachments: JCRVLT-340.patch
>
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895328#comment-16895328
]
angela commented on JCRVLT-340:
---
proposed patch attached
[~stillalex], fyi
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCRVLT-340.patch
>
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-340:
--
Attachment: JCRVLT-340.patch
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCRVLT-340.patch
>
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (JCRVLT-346) IntegrationTestBase: allow for custom security setup
[
https://issues.apache.org/jira/browse/JCRVLT-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCRVLT-346.
---
Resolution: Fixed
Fix Version/s: 3.2.10
Committed revision 1863939.
> IntegrationTestBase: allow for custom security setup
>
>
> Key: JCRVLT-346
> URL: https://issues.apache.org/jira/browse/JCRVLT-346
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 3.2.10
>
>
> today all test extending from {{IntegrationTestBase}} have the same Oak
> security setup, which makes it impossible to write tests for a different set
> of options or for additional security modules.
> while addressing this issue, we should also replace usage of the deprecate
> {{SecurityProviderImpl}} by {{SecurityProviderBuilder}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCRVLT-344: -- Component/s: vlt > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc, vlt >Reporter: angela >Assignee: angela >Priority: Major > Fix For: 3.2.10 > > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCRVLT-344. --- Resolution: Fixed Fix Version/s: 3.2.10 > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Assignee: angela >Priority: Major > Fix For: 3.2.10 > > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (JCRVLT-346) IntegrationTestBase: allow for custom security setup
angela created JCRVLT-346:
-
Summary: IntegrationTestBase: allow for custom security setup
Key: JCRVLT-346
URL: https://issues.apache.org/jira/browse/JCRVLT-346
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: vlt
Reporter: angela
Assignee: angela
today all test extending from {{IntegrationTestBase}} have the same Oak
security setup, which makes it impossible to write tests for a different set of
options or for additional security modules.
while addressing this issue, we should also replace usage of the deprecate
{{SecurityProviderImpl}} by {{SecurityProviderBuilder}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893476#comment-16893476 ] angela commented on JCRVLT-344: --- [~kwin], good catch. fixed in my local changes. > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Assignee: angela >Priority: Major > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned JCRVLT-344: - Assignee: angela > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Assignee: angela >Priority: Major > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893453#comment-16893453 ] angela commented on JCRVLT-344: --- [~reschke], the reason why i decided to move to _oak-jackrabbit-api_ was that i fixed a minor bug in _oak-jackrabbit-api_, which will be released with Oak 1.16.0. > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Priority: Major > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892588#comment-16892588 ] angela commented on JCRVLT-344: --- [~tripod], proposed patch attached. i tested it with the release-candidate of oak 1.16.0. once oak 1.16.0 is released, the patch could be committed. let me know if you have any concerns. > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Priority: Major > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCRVLT-344: -- Attachment: JCRVLT-344.patch > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Priority: Major > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (JCRVLT-344) update version of jackrabbit and oak dependencies
angela created JCRVLT-344: - Summary: update version of jackrabbit and oak dependencies Key: JCRVLT-344 URL: https://issues.apache.org/jira/browse/JCRVLT-344 Project: Jackrabbit FileVault Issue Type: Task Components: Misc Reporter: angela in order to address JCRVLT-340 the version properties of jackrabbit and oak need to be adjusted to use the most recent releases: 2.18.2 1.16 since there some significant moves made in the code base the following additional changes need to follow: * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer exist) - subsequently adjust the changed package names (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCRVLT-344: -- Description: in order to address JCRVLT-340 the version properties of jackrabbit and oak need to be adjusted to use the most recent releases: 2.18.2 1.16.0 since there some significant moves made in the code base the following additional changes need to follow: * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer exist) - subsequently adjust the changed package names (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as jackrabbit-api will no longer be maintained was: in order to address JCRVLT-340 the version properties of jackrabbit and oak need to be adjusted to use the most recent releases: 2.18.2 1.16 since there some significant moves made in the code base the following additional changes need to follow: * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer exist) - subsequently adjust the changed package names (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as jackrabbit-api will no longer be maintained > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Priority: Major > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned JCRVLT-340:
-
Assignee: angela
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886235#comment-16886235
]
angela commented on JCR-4458:
-
[~reschke], unfortunately not...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
angela created JCRVLT-340:
-
Summary: Adjust JackrabbitACLImporter to handle extensions
provided by OAK-8190
Key: JCRVLT-340
URL: https://issues.apache.org/jira/browse/JCRVLT-340
Project: Jackrabbit FileVault
Issue Type: New Feature
Components: vlt
Reporter: angela
Request to adjust {{JackrabbitACLImporter}} and {{DocViewSAXImporter}} to
handle the policies defined by the optional authorization model provided by
OAK-8190.
I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4444) Add nullable/notnull annotations for jackrabbit security API extensions
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856792#comment-16856792 ] angela commented on JCR-: - [~reschke]... ok... but i can also way a bit... whatever is better. there is no real pressure, i just find it confusing not to have the annotations. > Add nullable/notnull annotations for jackrabbit security API extensions > --- > > Key: JCR- > URL: https://issues.apache.org/jira/browse/JCR- > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api >Reporter: angela >Assignee: angela >Priority: Major > > due to the missing nullable/notnull annotations and unspecific javadoc it's > not always clear, if null params are allow and if null return values should > be expected. adding the missing annotations will IMO clarify the API contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JCR-4444) Add nullable/notnull annotations for jackrabbit security API extensions
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned JCR-: --- Assignee: angela > Add nullable/notnull annotations for jackrabbit security API extensions > --- > > Key: JCR- > URL: https://issues.apache.org/jira/browse/JCR- > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api >Reporter: angela >Assignee: angela >Priority: Major > > due to the missing nullable/notnull annotations and unspecific javadoc it's > not always clear, if null params are allow and if null return values should > be expected. adding the missing annotations will IMO clarify the API contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCR-4444) Add nullable/notnull annotations for jackrabbit security API extensions
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849646#comment-16849646 ] angela commented on JCR-: - i guess that depends on when the convert is going to happen > Add nullable/notnull annotations for jackrabbit security API extensions > --- > > Key: JCR- > URL: https://issues.apache.org/jira/browse/JCR- > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-api >Reporter: angela >Priority: Major > > due to the missing nullable/notnull annotations and unspecific javadoc it's > not always clear, if null params are allow and if null return values should > be expected. adding the missing annotations will IMO clarify the API contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCR-4444) Add nullable/notnull annotations for jackrabbit security API extensions
angela created JCR-: --- Summary: Add nullable/notnull annotations for jackrabbit security API extensions Key: JCR- URL: https://issues.apache.org/jira/browse/JCR- Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Reporter: angela due to the missing nullable/notnull annotations and unspecific javadoc it's not always clear, if null params are allow and if null return values should be expected. adding the missing annotations will IMO clarify the API contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCR-4436) Improve tests for o.a.j.oak.security.authentication.token package
angela created JCR-4436:
---
Summary: Improve tests for o.a.j.oak.security.authentication.token
package
Key: JCR-4436
URL: https://issues.apache.org/jira/browse/JCR-4436
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: core, security
Reporter: angela
Assignee: angela
- remove usage of deprecated {{NodeUtil}}
- declare expected exceptions with test annotation
- missing {{ContentSession.close}}
- move duplicated utilities to {{AbstractTokenTest}}
- redundant imports and exception declarations
- improve coverage
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832375#comment-16832375
]
angela edited comment on JCR-4429 at 5/3/19 9:25 AM:
-
[~stillalex], as discussed i committed the patch at revision 1858564. and
ProviderType annotation at rev 1858566
was (Author: anchela):
[~stillalex], as discussed i committed the patch at revision 1858564.
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 2.20, 2.19.3
>
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCR-4432) Update version of jackrabbit dependency
angela created JCR-4432:
---
Summary: Update version of jackrabbit dependency
Key: JCR-4432
URL: https://issues.apache.org/jira/browse/JCR-4432
Project: Jackrabbit Content Repository
Issue Type: Task
Components: parent
Reporter: angela
in order to make the api extensions added with JCR-4429 available with a stable
version of _jackrabbit-api_, we should update the corresponding version in the
{{parent.pom}} once released.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-4429.
-
Resolution: Fixed
[~stillalex], as discussed i committed the patch at revision 1858564.
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 2.20, 2.19.3
>
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4429:
Fix Version/s: 2.20
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 2.20, 2.19.3
>
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831610#comment-16831610
]
angela commented on JCR-4429:
-
[~stillalex], updated patch that explicitly mentions the link to
{{AccessControlManager#getEffectivePolicies(String path)}}.
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4429:
Fix Version/s: 2.19.3
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 2.19.3
>
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4429:
Attachment: JCR-4429-2.patch
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCR-4429-2.patch, JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned JCR-4429:
---
Assignee: angela
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
angela created JCR-4429:
---
Summary: Add extension of JackrabbitAccessControlList bound to a
principal
Key: JCR-4429
URL: https://issues.apache.org/jira/browse/JCR-4429
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api
Reporter: angela
Attachments: JCR-4429.patch
while {{JackrabbitAccessControlManager}} supports editing policies by
principals since quite some time, available set of access control policies
didn't provide a variant that was naturally bound to a given principal. the
attached patch would introduce an extension of {{AccessControlList}} that was
actually bound to a principal.
[~stillalex], i would appreciate if you had time to take a look at the proposed
extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4429) Add extension of JackrabbitAccessControlList bound to a principal
[
https://issues.apache.org/jira/browse/JCR-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4429:
Attachment: JCR-4429.patch
> Add extension of JackrabbitAccessControlList bound to a principal
> -
>
> Key: JCR-4429
> URL: https://issues.apache.org/jira/browse/JCR-4429
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Reporter: angela
>Priority: Major
> Attachments: JCR-4429.patch
>
>
> while {{JackrabbitAccessControlManager}} supports editing policies by
> principals since quite some time, available set of access control policies
> didn't provide a variant that was naturally bound to a given principal. the
> attached patch would introduce an extension of {{AccessControlList}} that was
> actually bound to a principal.
> [~stillalex], i would appreciate if you had time to take a look at the
> proposed extension. anything missing in terms of contract? does it make sense?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4120:
Priority: Major (was: Minor)
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
> Fix For: 2.18, 2.17.7
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4120:
Labels: (was: candidate_jcr_2_16)
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
> Fix For: 2.18, 2.17.7
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4120:
Issue Type: Improvement (was: Bug)
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Fix For: 2.18, 2.17.7
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4120:
Priority: Minor (was: Major)
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Labels: candidate_jcr_2_16
> Fix For: 2.18, 2.17.7
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4120:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed revision 1846665.
I committed the changes to 'Spi2davexRepositoryServiceFactory' with slightly
modified comments in particular also linking to JCR-4120 as for any setup with
jcrserver <1.5 this modification is most probably a breaking change.
in terms of testing: i ran the ConformanceTest present with
_jackrabbit-jcr2dav_ and all executed tests passed with no default workspace
name set in the factory (verified that this code is actually executed).
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
> Fix For: 2.18
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688002#comment-16688002
]
angela commented on JCR-4120:
-
[~kwin], for future contributions: please don't add unrelated changes to a
patch. just looked at the patch and saw unrelated changes to exceptions,
trivial javadoc modifications (but then not making this consistently). I will
only review the part that is related to this issue and will not commit
unrelated modifications.
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
> Fix For: 2.18
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (JCR-4120) Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to "default"
[
https://issues.apache.org/jira/browse/JCR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned JCR-4120:
---
Assignee: angela
> Spi2DavexRepositoryServiceImpl always hardcodes the default workspace name to
> "default"
> ---
>
> Key: JCR-4120
> URL: https://issues.apache.org/jira/browse/JCR-4120
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
> Fix For: 2.18
>
>
> Basically the patch from JCR-2113 breaks the default workspace handling when
> the {{org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory}} is
> being used, because it always assumes that the default workspace name is
> {{default}}. This is unfortunately not always true. The only reason why the
> default workspace name need to be passed at all seems to be backwards
> compatibility (prior to version 1.5 this was mandatory, see JCR-1842).
> Unfortunately the assumed default workspace name being {{default}} may lead
> to issues, as this is then used to with each call to
> {{org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(...)}} where it
> falls back to the default workspace name when no explicit workspace name is
> given.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-299) Test coverage for privilege import
angela created JCRVLT-299: - Summary: Test coverage for privilege import Key: JCRVLT-299 URL: https://issues.apache.org/jira/browse/JCRVLT-299 Project: Jackrabbit FileVault Issue Type: Sub-task Components: Packaging Reporter: angela -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-292) Order of ACLs are altered on installation of content packages
[
https://issues.apache.org/jira/browse/JCRVLT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496192#comment-16496192
]
angela commented on JCRVLT-292:
---
[~stillalex], [~reschke], I have been thinking about this issue over and over
again. I don't feel comfortable to push this patch without having proper test
coverage in place.
Therefore I created a new container for the test coverage and created specific
subtasks for the security related parts, marking the one for access control
import as blocking this issue.
> Order of ACLs are altered on installation of content packages
> -
>
> Key: JCRVLT-292
> URL: https://issues.apache.org/jira/browse/JCRVLT-292
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: angela
>Priority: Major
> Attachments: JCRVLT-292-2.patch, JCRVLT-292.patch
>
>
> When installing a content package with AccessControlHandling _overwrite_
> access control entries contained in a given list are grouped by principal and
> ultimately imported with a different order that originally defined in the
> package.
> This alters the effective permissions for those {{Subject}}s that contain the
> principals for which the ACEs got imported.
> Example:
> 1. grant group1 read at /testroot
> 2. deny group2 read at specific subset of items within the tree defined by
> /testroot
> 3. grant group1 read/write at specific subset of items within the tree
> defined by /testroot
> The ACL resulting from the package import will contain the entries in the
> following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-297) Test coverage for user/group import
angela created JCRVLT-297: - Summary: Test coverage for user/group import Key: JCRVLT-297 URL: https://issues.apache.org/jira/browse/JCRVLT-297 Project: Jackrabbit FileVault Issue Type: Sub-task Components: Packaging Reporter: angela -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCRVLT-296) Test coverage for access control import
angela created JCRVLT-296: - Summary: Test coverage for access control import Key: JCRVLT-296 URL: https://issues.apache.org/jira/browse/JCRVLT-296 Project: Jackrabbit FileVault Issue Type: Sub-task Components: Packaging Reporter: angela -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCRVLT-295) Improve test coverage for Jackrabbit FVault
angela created JCRVLT-295: - Summary: Improve test coverage for Jackrabbit FVault Key: JCRVLT-295 URL: https://issues.apache.org/jira/browse/JCRVLT-295 Project: Jackrabbit FileVault Issue Type: Task Components: Misc Reporter: angela IMHO it would be crucial to have good test coverage for Jackrabbit FVault in order to be able to contribute improvements and bug fixes. Today it is very hard to assess whether a given behaviour is actually intended or rather a bug or somthing that might be improved. JCRVLT-292 is a perfect example where I don't feel comfortable pushing a proposed fix, because I can't decide whether the original behaviour was actually intended or not... in other words if it's really a bug or works as designed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-292) Order of ACLs are altered on installation of content packages
[
https://issues.apache.org/jira/browse/JCRVLT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495066#comment-16495066
]
angela commented on JCRVLT-292:
---
[~stillalex], [~reschke], slightly simplified patch... to be honest it somehow
worries me that no tests start failing with my changes. as a next step i will
take another look at existing tests and see what could be done with moderate
effort.
> Order of ACLs are altered on installation of content packages
> -
>
> Key: JCRVLT-292
> URL: https://issues.apache.org/jira/browse/JCRVLT-292
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: angela
>Priority: Major
> Attachments: JCRVLT-292-2.patch, JCRVLT-292.patch
>
>
> When installing a content package with AccessControlHandling _overwrite_
> access control entries contained in a given list are grouped by principal and
> ultimately imported with a different order that originally defined in the
> package.
> This alters the effective permissions for those {{Subject}}s that contain the
> principals for which the ACEs got imported.
> Example:
> 1. grant group1 read at /testroot
> 2. deny group2 read at specific subset of items within the tree defined by
> /testroot
> 3. grant group1 read/write at specific subset of items within the tree
> defined by /testroot
> The ACL resulting from the package import will contain the entries in the
> following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-292) Order of ACLs are altered on installation of content packages
[
https://issues.apache.org/jira/browse/JCRVLT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-292:
--
Attachment: JCRVLT-292-2.patch
> Order of ACLs are altered on installation of content packages
> -
>
> Key: JCRVLT-292
> URL: https://issues.apache.org/jira/browse/JCRVLT-292
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: angela
>Priority: Major
> Attachments: JCRVLT-292-2.patch, JCRVLT-292.patch
>
>
> When installing a content package with AccessControlHandling _overwrite_
> access control entries contained in a given list are grouped by principal and
> ultimately imported with a different order that originally defined in the
> package.
> This alters the effective permissions for those {{Subject}}s that contain the
> principals for which the ACEs got imported.
> Example:
> 1. grant group1 read at /testroot
> 2. deny group2 read at specific subset of items within the tree defined by
> /testroot
> 3. grant group1 read/write at specific subset of items within the tree
> defined by /testroot
> The ACL resulting from the package import will contain the entries in the
> following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495044#comment-16495044
]
angela commented on JCRVLT-293:
---
[~reschke], i was using 1.8.0_40.
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-292) Order of ACLs are altered on installation of content packages
[
https://issues.apache.org/jira/browse/JCRVLT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-292:
--
Attachment: JCRVLT-292.patch
Status: Patch Available (was: Open)
[~tripod], attached an IT illustrating the issue and a proposed patch of
{{JackrabbitACLImporter}}. The test fails without the patch but passes with the
fix in place... however see JCRVLT-293 for other test failure, which I am not
entirely sure how to weight them.
While I think the proposed fix actually introduces a backwards compatibility
issue, the fix doesn't seem to cause other tests to fail. I would feel a lot
more comfortable with the proposed fix, if there was a bigger test coverage
(both IT and unit tests) that would help me understand if the behaviour today
was actually intended or if we are really looking at a bug (or improvement)
here.
> Order of ACLs are altered on installation of content packages
> -
>
> Key: JCRVLT-292
> URL: https://issues.apache.org/jira/browse/JCRVLT-292
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: angela
>Priority: Major
> Attachments: JCRVLT-292.patch
>
>
> When installing a content package with AccessControlHandling _overwrite_
> access control entries contained in a given list are grouped by principal and
> ultimately imported with a different order that originally defined in the
> package.
> This alters the effective permissions for those {{Subject}}s that contain the
> principals for which the ACEs got imported.
> Example:
> 1. grant group1 read at /testroot
> 2. deny group2 read at specific subset of items within the tree defined by
> /testroot
> 3. grant group1 read/write at specific subset of items within the tree
> defined by /testroot
> The ACL resulting from the package import will contain the entries in the
> following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-293:
--
Description:
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _-Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
was:
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _ -Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
angela created JCRVLT-293:
-
Summary: Failing tests when building vault-core with -Doak=true
Key: JCRVLT-293
URL: https://issues.apache.org/jira/browse/JCRVLT-293
Project: Jackrabbit FileVault
Issue Type: Bug
Components: Misc
Reporter: angela
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _ -Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-292) Order of ACLs are altered on installation of content packages
angela created JCRVLT-292:
-
Summary: Order of ACLs are altered on installation of content
packages
Key: JCRVLT-292
URL: https://issues.apache.org/jira/browse/JCRVLT-292
Project: Jackrabbit FileVault
Issue Type: Bug
Components: Packaging
Reporter: angela
When installing a content package with AccessControlHandling _overwrite_ access
control entries contained in a given list are grouped by principal and
ultimately imported with a different order that originally defined in the
package.
This alters the effective permissions for those {{Subject}}s that contain the
principals for which the ACEs got imported.
Example:
1. grant group1 read at /testroot
2. deny group2 read at specific subset of items within the tree defined by
/testroot
3. grant group1 read/write at specific subset of items within the tree defined
by /testroot
The ACL resulting from the package import will contain the entries in the
following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348911#comment-16348911
]
angela commented on JCR-3923:
-
[~kwin], can you file a documentation issue with
https://issues.apache.org/jira/projects/OAK then we can take care of explicitly
mentioning the concat-nature and highlight the fact that for the root-node a
leading / in the pattern won't work.
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348836#comment-16348836
]
angela edited comment on JCR-3923 at 2/1/18 4:21 PM:
-
[~reschke], it should also work on the root node. I don't know about
jackrabbit-core but afaik it works with Oak (there should even be some test
case if i remember correctly). One common mistake though is that the specified
pattern is defined with a leading path, which on the root node will result in
an invalid path that is never matched as the GlobPattern just concatenates
string.
in any case issues with Oak should be reported with the Oak project as it's a
separate code base with a separate jira bucket.
was (Author: anchela):
[~reschke], it should also work on the root node. I don't know about
jackrabbit-core but afaik it works with Oak (there should even be some test
case if i remember correctly). One common mistake though is that the specified
pattern is defined with a leading path, which on the root node will result in
an invalid path that is never matched as the GlobPattern just concatenates
string.
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348836#comment-16348836
]
angela commented on JCR-3923:
-
[~reschke], it should also work on the root node. I don't know about
jackrabbit-core but afaik it works with Oak (there should even be some test
case if i remember correctly). One common mistake though is that the specified
pattern is defined with a leading path, which on the root node will result in
an invalid path that is never matched as the GlobPattern just concatenates
string.
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4249) Introduce replacement for java.security.acl.Group
[
https://issues.apache.org/jira/browse/JCR-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336047#comment-16336047
]
angela commented on JCR-4249:
-
[~stillalex], the patch looks good to me. just one minor thing i noticed in
{{GroupPrincipal.members()}}: the {{isMember}} method is explicitly specified
to evaluate _inherited_ membership. does this also apply to
{{GroupPrincipal.members()}}? in other words: is {{GroupPrincipal.members()}}
the complete enumeration of principals for which {{isMember}} returns true?
> Introduce replacement for java.security.acl.Group
> -
>
> Key: JCR-4249
> URL: https://issues.apache.org/jira/browse/JCR-4249
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: JCR API, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 2.17.1
>
> Attachments: JCR-4249-v2.patch, JCR-4249.patch
>
>
> See OAK-7024 and JCR-4246 for more information.
> I've decided to split off the api changes to have them in early for a release
> so both projects could use the same class as replacement of the Group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4249) Introduce replacement for java.security.acl.Group
[
https://issues.apache.org/jira/browse/JCR-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16331333#comment-16331333
]
angela commented on JCR-4249:
-
[~stillalex], the patch looks good to me... the only thing that we might want
to add: I would mention in the javadoc of {{PrincipalManager}} that it used to
be {{java.security.acl.Group}} and when + why this has been adjusted... as long
as it's not remove implementations might have prinicipals that implement both
interfaces for backwards compatibility. wdyt?
> Introduce replacement for java.security.acl.Group
> -
>
> Key: JCR-4249
> URL: https://issues.apache.org/jira/browse/JCR-4249
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: JCR API, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 2.17.1
>
> Attachments: JCR-4249.patch
>
>
> See OAK-7024 and JCR-4246 for more information.
> I've decided to split off the api changes to have them in early for a release
> so both projects could use the same class as replacement of the Group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4144:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed revision 1799557.
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.16, 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057627#comment-16057627
]
angela commented on JCR-4144:
-
[~reschke], how long to i have to wait?... i already tested it with the patch
from JCR_4150 and the _jackrabbit-api_ looked fine (not so the data... but
that's a different issue) :-)
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057532#comment-16057532
]
angela commented on JCR-4144:
-
[~reschke], i applied your patch for JCR-4150 and extended the proposed patch
by provider type annotations and a minor version increase. unless your or
[~stillalex] objects i would go ahead and commit the proposed improvement.
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request
[
https://issues.apache.org/jira/browse/JCR-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055266#comment-16055266
]
angela commented on JCR-4146:
-
[~reschke], patch looks good to me. in order to minimize the risk for
regressions i would suggest to run the litmus test-suite for the regular webdav
implementation and the TCK tests against the jcr-2-spi-2-webdav setup (using
the jcr-remoting). For the latter building _jackrabbit-jcr2dav_ must be run
with _-PintegrationTesting_ => the
{{org.apache.jackrabbit.jcr2dav.ConformanceTest}} collects the TCK, the jcr2spi
test suite and the jcr2spi-security test suite.
> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
> Attachments: JCR-4146-2.diff, JCR-4146.diff
>
>
> This issue was first observed via crxDE: the user did a copy / paste on a
> node with the .json extension (let's say test.json). After saving, the new
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X
> COPY -H 'Overwrite: T' -H 'Destination:
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json'
> -X COPY -H 'Overwrite: T' -H 'Destination:
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is
> called "copytest".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request
[
https://issues.apache.org/jira/browse/JCR-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050099#comment-16050099
]
angela commented on JCR-4146:
-
:-)
> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a
> node with the .json extension (let's say test.json). After saving, the new
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X
> COPY -H 'Overwrite: T' -H 'Destination:
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json'
> -X COPY -H 'Overwrite: T' -H 'Destination:
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is
> called "copytest".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4147) clirr profile needs to use sensible baselines
[ https://issues.apache.org/jira/browse/JCR-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049274#comment-16049274 ] angela commented on JCR-4147: - [~reschke], i only learned about the clirr profile yesterday... looking at http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/package-info.java?view=log it seems that i don't have amnesia it really was never updated since Jukka introduced it 5 years ago... all the API extensions we added got "unnoticed" from a export version pov. +1 for both suggestions. > clirr profile needs to use sensible baselines > - > > Key: JCR-4147 > URL: https://issues.apache.org/jira/browse/JCR-4147 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-parent >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_jcr_2_10, candidate_jcr_2_12, > candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8 > Fix For: 2.15.4 > > > For the "clirr" profile, we currently use a baseline of Jackrabbit 2.2.0 > throughout. This doesn't make any sense, it should be the previous stable > release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCR-4146) json extension is removed by AbstractWebdavServlet on COPY request
[
https://issues.apache.org/jira/browse/JCR-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049031#comment-16049031
]
angela commented on JCR-4146:
-
i would need to dig into the code again... wild guess: could it be that the
.json ending gets interpreted as a hint to process the request with the
remoting-servlet instead of the default webdav server servlet?
> json extension is removed by AbstractWebdavServlet on COPY request
> --
>
> Key: JCR-4146
> URL: https://issues.apache.org/jira/browse/JCR-4146
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.15.3
>Reporter: Ana Vinatoru
>Assignee: Julian Reschke
>
> This issue was first observed via crxDE: the user did a copy / paste on a
> node with the .json extension (let's say test.json). After saving, the new
> node was named "Copy of test" instead of "Copy of test.json".
> I tracked the request to the AbstractWebdavServlet.doCopy method - and this
> is where the .json extension seems to be lost.
> The Destination header sent by crxde includes the extension, but the new
> resource created in doCopy does not have it.
> The request looked like this:
> {code:java}
> curl -u admin:admin
> 'http://localhost:4502/crx/server/crx.default/jcr%3aroot/libs/test.json' -X
> COPY -H 'Overwrite: T' -H 'Destination:
> /crx/server/crx.default/jcr%3aroot/libs/Copy%20of%20test.json' -v
> {code}
> To rule out issues in other layers, I tested with the Jackrabbit 2.14.x
> standalone.
> I uploaded the test.json file via WebDav, then executed the following curl
> request:
> {code:java}
> curl -u admin:admin 'http://localhost:9001/server/default/jcr:root/test.json'
> -X COPY -H 'Overwrite: T' -H 'Destination:
> /server/default/jcr:root/copytest.json' -v
> {code}
> The new node was created, but instead of being named "copytest.json", it is
> called "copytest".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048031#comment-16048031
]
angela edited comment on JCR-4144 at 6/13/17 3:33 PM:
--
[~reschke], i did the following
{code}
mvn clean install -Pclirr
{code}
but maybe that's not the right way to use the _clirr_ profile? i was just
spotting the profile while looking if we _really_ don't have the baseline
plugin in the default build profile.
since i distinctly remember not having come across this profile before and i
don't remember having ever touched the export version when adding extensions to
the API, i wasn't too surprised about the errors... but that might also be
caused amnesia ;-)
was (Author: anchela):
[~reschke], i did the following
{code}
mvn clean install -Pclirr
{code}
but maybe that's not the right way to use the _clirr_ profile? i was just
spotting the profile while looking if we _really_ don't have the baseline
plugin in the default build profile.
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048031#comment-16048031
]
angela commented on JCR-4144:
-
[~reschke], i did the following
{code}
mvn clean install -Pclirr
{code}
but maybe that's not the right way to use the _clirr_ profile? i was just
spotting the profile while looking if we _really_ don't have the baseline
plugin in the default build profile.
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047705#comment-16047705
]
angela commented on JCR-4144:
-
[~reschke], don't know... i just stopped looking any further when seeing the
ERRORs with the API.
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046699#comment-16046699
]
angela commented on JCR-4144:
-
[~alex.parvulescu], you are right!... but we would have a _clirr_ profile,
which actually throws a dozen of ERRORs for changes we made to the Jackrabbit
API over the last 5 years.
cc: [~reschke]
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046671#comment-16046671
]
angela edited comment on JCR-4144 at 6/12/17 3:23 PM:
--
[~alexparvulescu], [~reschke], may i ask you to review to proposed API
extension? I run the jackrabbit build with integration tests and wonder why the
baseline plugin didn't prompt me to increase the export version of
_org.apache.jackrabbit.api.security_... any idea?
was (Author: anchela):
[~alexparvulescu], [~reschke], may i ask you to review to proposed API
extension? I run the jackrabbit build with integration tests and wonder why it
didn't prompt me to increase the export version of
_org.apache.jackrabbit.api.security_... any idea?
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4144:
Status: Patch Available (was: Open)
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4144:
Attachment: JCR-4144.patch
[~alexparvulescu], [~reschke], may i ask you to review to proposed API
extension? I run the jackrabbit build with integration tests and wonder why it
didn't prompt me to increase the export version of
_org.apache.jackrabbit.api.security_... any idea?
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
> Attachments: JCR-4144.patch
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046627#comment-16046627
]
angela commented on JCR-4144:
-
[~nitin.nizhawan], thanks for the report. i will take a look as soon as time
permits
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCR-4144) JackrabbitAccessControlList should have an API boolean isMultiValueRestriction(restrictionName)
[
https://issues.apache.org/jira/browse/JCR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4144:
Issue Type: New Feature (was: Improvement)
> JackrabbitAccessControlList should have an API boolean
> isMultiValueRestriction(restrictionName)
> ---
>
> Key: JCR-4144
> URL: https://issues.apache.org/jira/browse/JCR-4144
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
>Affects Versions: 2.15.3
>Reporter: Nitin Nizhawan
> Fix For: 2.15.4
>
>
> JackrabbitAccessControlList \[0\] has a method int getRestrictionType(String
> restrictionName).
> This method returns the type of the restriction specified restrictionName.
> Although, it does not provide enough information to deduce whether
> restriction is defined to accept single or multiple values. Hence, a method
> with following signature should be added to this API
> {code}
> boolean isMultiValueRestriction(String restrictionName)
> {code}
> \[0\]
> https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCR-4141) SecurityProviderRegistration.maybeUnregister: typo on comment
[
https://issues.apache.org/jira/browse/JCR-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4141:
Fix Version/s: 1.8
1.7.1
> SecurityProviderRegistration.maybeUnregister: typo on comment
> -
>
> Key: JCR-4141
> URL: https://issues.apache.org/jira/browse/JCR-4141
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Reporter: angela
>Priority: Trivial
> Fix For: 1.7.1, 1.8
>
>
> the comment within {{SecurityProviderRegistration.maybeUnregister}} states{
> {code}
> // The preconditions are not satisfied. This may happen when a
> // dependency is unbound from the current component.
> if (preconditions.areSatisfied()) {
> log.info("Aborting: preconditions are satisfied");
> return;
> }
> {code}
> what is actually meant is that the preconditions are still satisfied and we
> therefore have no reason to continue with the unregistration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JCR-4141) SecurityProviderRegistration.maybeUnregister: typo on comment
angela created JCR-4141: --- Summary: SecurityProviderRegistration.maybeUnregister: typo on comment Key: JCR-4141 URL: https://issues.apache.org/jira/browse/JCR-4141 Project: Jackrabbit Content Repository Issue Type: Bug Components: core Reporter: angela Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-4050: Resolution: Won't Fix Status: Resolved (was: Patch Available) i am sorry, but that request doesn't sound right to me. a consumer of the user management API should neither know nor care about implementation details such as how to create the pw hash. and when it comes to the SLING repo-init: the original intention behind this was the creation of service users which don't allow for having a password set anyway. when it comes to regular users i first of all don't see too much benefit in creating them with a repo-init within Sling. second it's sounds like a pretty bad idea from a security pov that the person editing the repo-init file would know and thus specify the password of any user. also this would by-pass all password-constraints that might be required for a given repository instance and which are enforced upon user creation or pw-change operations. finally, it would mean that all repositories get the same password set for a given user, which doesn't sound like a good idea to me... then the hashing is the least problem you are having. i would strongly recommend not to use the Sling repo-init for the setup of regular users but stick with the original intention to use this for service users only. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela closed JCR-4050. --- > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (JCR-3411) UserManager createUser method without Principal
[ https://issues.apache.org/jira/browse/JCR-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-3411. - Resolution: Later > UserManager createUser method without Principal > --- > > Key: JCR-3411 > URL: https://issues.apache.org/jira/browse/JCR-3411 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: jackrabbit-api >Affects Versions: 2.4 >Reporter: Dominik Forster > > Is it possible to get an additional method UserManager.createUser(String > userID, String password, String intermediatePath), so that we don't need to > create a dependency for the PrincipalImpl class? > Regards, > Dominik -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCRVLT-144) Unable to perform checkouts with vlt > 3.1.26
[
https://issues.apache.org/jira/browse/JCRVLT-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15760794#comment-15760794
]
angela commented on JCRVLT-144:
---
maybe just a regression that slipped in when applying the patches for JCR-2113?
> Unable to perform checkouts with vlt > 3.1.26
> -
>
> Key: JCRVLT-144
> URL: https://issues.apache.org/jira/browse/JCRVLT-144
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.1.28, 3.1.30
>Reporter: Radu Cotescu
>Assignee: Tobias Bocanegra
>
> When trying to perform a {{vlt co}} with {{vlt}} > 3.1.26 I get the following
> error message:
> {noformat}
> vlt co --force http://localhost:4502
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m;
> support was removed in 8.0
> Checkout http://localhost:4502/crx/server/-/jcr:root/ with local files using
> root at [...]/content/src/content/jcr_root
> Connecting via JCR remoting to http://localhost:4502/crx/server
> [ERROR] checkout: org.apache.jackrabbit.vault.vlt.VltException: Unable to
> mount filesystem
> caused by: javax.jcr.lock.LockException: Precondition Failed
> caused by: org.apache.jackrabbit.webdav.DavException: Precondition Failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-2113) JSR 283 Access Control Management
[ https://issues.apache.org/jira/browse/JCR-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15760655#comment-15760655 ] angela commented on JCR-2113: - no, sorry, i don't > JSR 283 Access Control Management > - > > Key: JCR-2113 > URL: https://issues.apache.org/jira/browse/JCR-2113 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-server, jackrabbit-jcr2spi, > jackrabbit-spi, jackrabbit-spi-commons, jackrabbit-spi2dav, > jackrabbit-spi2jcr, JCR 2.0 >Reporter: angela >Assignee: angela > Fix For: 2.9.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15693929#comment-15693929 ] angela commented on JCR-4050: - [~bornemannjs], i see your point. on the other hand, the creation of the pw-hash should be consideren an implementation detail of a given user management implementation and i don't see too much benefit of having such an API call without the ability to generate the hash. in other words: a caller of that API would only be able to create a pw-hash by relying on implementation details, which IMO is looking for troubles. but since you are mentioning AEM Package Manager: is this related to Jackrabbit FileVault project? afaik that project within the Jackrabbit family provides means to package and install repository content including users. If that was anyhow related, I would recommend to provide patches there if you find room for improvement in terms of performance and scalability. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15693911#comment-15693911 ] angela commented on JCR-4050: - [~olli], i have to say that i am pretty surprised to see the repo-init tool to allow for creation of regular users. i distinctly remember the initial idea was to provide a tool to create service users and that me and other security engineers strongly suggested to not expand that to regular users. i am not sure I understand what would be the use case for creating regular users during the repo init. and apart from that, if users were to be pre-created based on a configuration that can be share by different installations, i would strongly recommend to create them without password. writing the pw to the provision model really sounds like a very bad idea. /cc [~bdelacretaz] > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3943) [jackrabbi-aws-ext] Data inconsistency due to race condition during async uploads
[
https://issues.apache.org/jira/browse/JCR-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-3943:
Fix Version/s: 2.14
> [jackrabbi-aws-ext] Data inconsistency due to race condition during async
> uploads
> -
>
> Key: JCR-3943
> URL: https://issues.apache.org/jira/browse/JCR-3943
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Priority: Critical
> Fix For: 2.13.5, 2.14
>
> Attachments: coredata14Nov5Dec.txt
>
>
> There is a race condition when {{LocalCache}} is used where if an upload
> ({{file_u}}) has entered the cache but not the {{AsyncUploadCache}} and a
> simultaneous PurgeJob is running, then the uploaded file {{file_u}} can be
> purged from the cache.
> When the async job ultimately runs it fails silently (S3 client fails to
> calculate the hash because of the missing file), thus leaving dangling
> references in the node store as well as the {{AsyncUploadCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3943) [jackrabbi-aws-ext] Data inconsistency due to race condition during async uploads
[
https://issues.apache.org/jira/browse/JCR-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-3943:
Assignee: Amit Jain
> [jackrabbi-aws-ext] Data inconsistency due to race condition during async
> uploads
> -
>
> Key: JCR-3943
> URL: https://issues.apache.org/jira/browse/JCR-3943
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Critical
> Fix For: 2.13.5, 2.14
>
> Attachments: coredata14Nov5Dec.txt
>
>
> There is a race condition when {{LocalCache}} is used where if an upload
> ({{file_u}}) has entered the cache but not the {{AsyncUploadCache}} and a
> simultaneous PurgeJob is running, then the uploaded file {{file_u}} can be
> purged from the cache.
> When the async job ultimately runs it fails silently (S3 client fails to
> calculate the hash because of the missing file), thus leaving dangling
> references in the node store as well as the {{AsyncUploadCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3944) CachingDataStore - Disable AsyncUploadCache
[
https://issues.apache.org/jira/browse/JCR-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-3944.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.14)
> CachingDataStore - Disable AsyncUploadCache
> ---
>
> Key: JCR-3944
> URL: https://issues.apache.org/jira/browse/JCR-3944
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Priority: Minor
>
> Enabling AsyncUploadCache can lead to data inconsistencies. When a node is
> created the {{CachingDataStore#addRecord}} call returns immediately with the
> blob id, while corresponding blob is uploaded asynchronously. This can cause
> the inconsistency as if there is an error in the upload the node is already
> created.
> Also, this may not be visible immediately and it will be very hard to discern
> the root cause.
> AsyncUploadCache is enabled by default with value set to 100 and should be
> disabled by default by setting to 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3997) TraversingItemVisitor causes stackoverflowexception with breadth first traversal
[ https://issues.apache.org/jira/browse/JCR-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-3997: Fix Version/s: (was: 2.14) > TraversingItemVisitor causes stackoverflowexception with breadth first > traversal > > > Key: JCR-3997 > URL: https://issues.apache.org/jira/browse/JCR-3997 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons >Reporter: Chetan Mehrotra > Attachments: OAK-4549-test.patch > > > [TraversingItemVisitor|https://docs.adobe.com/docs/en/spec/jsr170/javadocs/jcr-1.0/javax/jcr/util/TraversingItemVisitor.html] > when used in breadth first traversal mode can lead to StackOverflowException > with very flat child list. This happens because it uses recursion [1] instead > of plain iteration which would increase the stack size proportional to number > of immediate child node. > The code technically belong to JSR-283 project. For now creating the issue > here > [1] > https://java.net/projects/jsr-283/sources/svn/content/trunk/src/java/javax/jcr/util/TraversingItemVisitor.java?rev=967 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3998) New putFile method which uses non referenceable oak:Resource nodetype
[ https://issues.apache.org/jira/browse/JCR-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-3998: Assignee: (was: Chetan Mehrotra) > New putFile method which uses non referenceable oak:Resource nodetype > - > > Key: JCR-3998 > URL: https://issues.apache.org/jira/browse/JCR-3998 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Chetan Mehrotra >Priority: Minor > > With OAK-4567 a new oak:Resource type is being introduced which is a > replacement for nt:resource for cases where referenceable nodes are not > required. > To make use of that we should add new variants of putFile in JcrUtil which > make use of that > See also http://jackrabbit-oak.markmail.org/thread/qicpzm5ltnzfsd42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3998) New putFile method which uses non referenceable oak:Resource nodetype
[ https://issues.apache.org/jira/browse/JCR-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-3998: Fix Version/s: (was: 2.14) > New putFile method which uses non referenceable oak:Resource nodetype > - > > Key: JCR-3998 > URL: https://issues.apache.org/jira/browse/JCR-3998 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > With OAK-4567 a new oak:Resource type is being introduced which is a > replacement for nt:resource for cases where referenceable nodes are not > required. > To make use of that we should add new variants of putFile in JcrUtil which > make use of that > See also http://jackrabbit-oak.markmail.org/thread/qicpzm5ltnzfsd42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3998) New putFile method which uses non referenceable oak:Resource nodetype
[ https://issues.apache.org/jira/browse/JCR-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-3998: Priority: Minor (was: Major) > New putFile method which uses non referenceable oak:Resource nodetype > - > > Key: JCR-3998 > URL: https://issues.apache.org/jira/browse/JCR-3998 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > With OAK-4567 a new oak:Resource type is being introduced which is a > replacement for nt:resource for cases where referenceable nodes are not > required. > To make use of that we should add new variants of putFile in JcrUtil which > make use of that > See also http://jackrabbit-oak.markmail.org/thread/qicpzm5ltnzfsd42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-4007) CachingDataStore - touching every time on getRecord() was unnecessary
[
https://issues.apache.org/jira/browse/JCR-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4007:
Assignee: Amit Jain
> CachingDataStore - touching every time on getRecord() was unnecessary
> -
>
> Key: JCR-4007
> URL: https://issues.apache.org/jira/browse/JCR-4007
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.13.2
>Reporter: Woonsan Ko
>Assignee: Amit Jain
> Labels: PatchAvailable
> Fix For: 2.14
>
>
> At the moment, {{CachingDataStore#getRecord()}} always invokes
> {{#touchInternal()}}, resulting in touching the file *every time* through the
> backend whenever reading a record. This seems to cause a performance degrade
> even when cached locally.
> Touching (updating the lastModifiedDate) must not be done every time. It
> should be done only when {{minModifiedDate}} is set to a number greater than
> zero by {{org.apache.jackrabbit.core.gc.GarbageCollector}} while marking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-4023) [S3DS] Configure failure count in initial migration of blobs from file system to S3
[ https://issues.apache.org/jira/browse/JCR-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-4023: Assignee: Amit Jain (was: Shashank Gupta) > [S3DS] Configure failure count in initial migration of blobs from file system > to S3 > --- > > Key: JCR-4023 > URL: https://issues.apache.org/jira/browse/JCR-4023 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.13.3 >Reporter: Shashank Gupta >Assignee: Amit Jain > Fix For: 2.14 > > Attachments: JCR-4023.patch > > > Currently initial migration fails if there is any intermittent error for > uploading file to S3. The idea is to continue with migration until failures > reaches configurable limit. On reaching limit migration or traversing whole > list of files, migration will abort. > This way next migration has less number to upload to S3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4055) Have AuthorizableQueryManager Support Named search with ignorecase
[
https://issues.apache.org/jira/browse/JCR-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15650463#comment-15650463
]
angela commented on JCR-4055:
-
[~krachi...@gmail.com], thanks for your report. just a quick initial question
back: what happened to the attached patch you were referring to in the initial
description?
please note, that I adjusted the components by adding {{jackrabbit-api}}. any
changes there would also require extra implementation work and testing in
jackrabbit oak.
> Have AuthorizableQueryManager Support Named search with ignorecase
> ---
>
> Key: JCR-4055
> URL: https://issues.apache.org/jira/browse/JCR-4055
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api, jackrabbit-jcr-commons
>Affects Versions: 2.8
>Reporter: Rachit Kumar
>Assignee: angela
>
> Usecase :
> We need to make search on Name and AuthorizableId while searching for users.
> Hence we used the 'named'[0] token while creating the json. But we realized
> that 'named' token doesn't support the ignore case feature due to which our
> search is failing. Can you please include an option to enable/disable the
> ignore case functionality.
> I have found a similar jira[1] reported earlier for the sort option.
> Sample Query :
> select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([rep:principalName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:first-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:last-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/givenName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/familyName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:authorizableId] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:principalName] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and name(a) like 'rohan@sandisk.com'
> order by lower([rep:principalName]
> The name(a) like 'rohan@sandisk.com' doesn't honor the ignorecase.
> Sample Calling :
> public Iterator execute(final String query) throws
> RepositoryException, IOException {
> try {
> return userManager.findAuthorizables(new Query(){
> public void build( QueryBuilder builder){
> try {
> builder.setLimit(0,MAX_RESULT_COUNT);
> new QueryTranslator(builder).translate(query);
> }
> catch (IOException e) {
> throw new IllegalArgumentException(e);
> }
> }
> }
> );
> }
> catch ( IllegalArgumentException e) {
> Throwable cause=e.getCause();
> if (cause instanceof IOException) {
> throw (IOException)cause;
> }
> else {
> throw e;
> }
> }
> }
> [0]
> https://docs.adobe.com/content/docs/en/aem/6-0/develop/ref/javadoc/org/apache/jackrabbit/api/security/user/QueryBuilder.html#nameMatches(java.lang.String)
> [1] https://issues.apache.org/jira/browse/JCR-3845
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-4055) Have AuthorizableQueryManager Support Named search with ignorecase
[
https://issues.apache.org/jira/browse/JCR-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4055:
Fix Version/s: (was: 2.9.1)
> Have AuthorizableQueryManager Support Named search with ignorecase
> ---
>
> Key: JCR-4055
> URL: https://issues.apache.org/jira/browse/JCR-4055
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api, jackrabbit-jcr-commons
>Affects Versions: 2.8
>Reporter: Rachit Kumar
>Assignee: angela
>
> Usecase :
> We need to make search on Name and AuthorizableId while searching for users.
> Hence we used the 'named'[0] token while creating the json. But we realized
> that 'named' token doesn't support the ignore case feature due to which our
> search is failing. Can you please include an option to enable/disable the
> ignore case functionality.
> I have found a similar jira[1] reported earlier for the sort option.
> Sample Query :
> select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([rep:principalName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:first-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:last-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/givenName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/familyName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:authorizableId] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:principalName] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and name(a) like 'rohan@sandisk.com'
> order by lower([rep:principalName]
> The name(a) like 'rohan@sandisk.com' doesn't honor the ignorecase.
> Sample Calling :
> public Iterator execute(final String query) throws
> RepositoryException, IOException {
> try {
> return userManager.findAuthorizables(new Query(){
> public void build( QueryBuilder builder){
> try {
> builder.setLimit(0,MAX_RESULT_COUNT);
> new QueryTranslator(builder).translate(query);
> }
> catch (IOException e) {
> throw new IllegalArgumentException(e);
> }
> }
> }
> );
> }
> catch ( IllegalArgumentException e) {
> Throwable cause=e.getCause();
> if (cause instanceof IOException) {
> throw (IOException)cause;
> }
> else {
> throw e;
> }
> }
> }
> [0]
> https://docs.adobe.com/content/docs/en/aem/6-0/develop/ref/javadoc/org/apache/jackrabbit/api/security/user/QueryBuilder.html#nameMatches(java.lang.String)
> [1] https://issues.apache.org/jira/browse/JCR-3845
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-4055) Have AuthorizableQueryManager Support Named search with ignorecase
[
https://issues.apache.org/jira/browse/JCR-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4055:
Component/s: jackrabbit-api
> Have AuthorizableQueryManager Support Named search with ignorecase
> ---
>
> Key: JCR-4055
> URL: https://issues.apache.org/jira/browse/JCR-4055
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-api, jackrabbit-jcr-commons
>Affects Versions: 2.8
>Reporter: Rachit Kumar
>Assignee: angela
>
> Usecase :
> We need to make search on Name and AuthorizableId while searching for users.
> Hence we used the 'named'[0] token while creating the json. But we realized
> that 'named' token doesn't support the ignore case feature due to which our
> search is failing. Can you please include an option to enable/disable the
> ignore case functionality.
> I have found a similar jira[1] reported earlier for the sort option.
> Sample Query :
> select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([rep:principalName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:first-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([cq:last-name],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/givenName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and contains([profile/familyName],
> 'rohan@sandisk.com*')
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:authorizableId] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and [rep:principalName] like
> 'rohan@sandisk.com'
> union select [jcr:path], [jcr:score], * from [rep:Authorizable] as a where
> isdescendantnode(a, '/home') and name(a) like 'rohan@sandisk.com'
> order by lower([rep:principalName]
> The name(a) like 'rohan@sandisk.com' doesn't honor the ignorecase.
> Sample Calling :
> public Iterator execute(final String query) throws
> RepositoryException, IOException {
> try {
> return userManager.findAuthorizables(new Query(){
> public void build( QueryBuilder builder){
> try {
> builder.setLimit(0,MAX_RESULT_COUNT);
> new QueryTranslator(builder).translate(query);
> }
> catch (IOException e) {
> throw new IllegalArgumentException(e);
> }
> }
> }
> );
> }
> catch ( IllegalArgumentException e) {
> Throwable cause=e.getCause();
> if (cause instanceof IOException) {
> throw (IOException)cause;
> }
> else {
> throw e;
> }
> }
> }
> [0]
> https://docs.adobe.com/content/docs/en/aem/6-0/develop/ref/javadoc/org/apache/jackrabbit/api/security/user/QueryBuilder.html#nameMatches(java.lang.String)
> [1] https://issues.apache.org/jira/browse/JCR-3845
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633074#comment-15633074 ] angela commented on JCR-4050: - [~bornemannjs], thanks for the insights. on the documentation you state that you were evaluating different ways of synchronizing repository content between different instances and that WebDAV was not found to be efficient. Did you also evaluate the JCR-remoting with it's extension that allows to process large chunks of content with a single request? It has been improved recently by [~alfu] allowing to transport protected content (access control content to be precise) in a way that would allow to easily expand that to other protected items such as those stored with user/group content. While I see the point of your extension, my gut feeling tells me that this doesn't belong to the API contract... trying to explore other possibilities that would allow you to efficiently synchronizing your data. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633079#comment-15633079 ] angela commented on JCR-4050: - and btw: the workspace.xml excerpt above only applies to jackrabbit core; in oak it's an OSGi configuration. And since you are mentioning AEM: the user-xml-import is enabled in AEM by default, both with Jackrabbit and Oak > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes
[
https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621540#comment-15621540
]
angela commented on JCR-4050:
-
There exists in fact a way to create users with existing password hashes and
which is actually intended for synchronizing content between repositories: the
JCR xml import. If import of the protected user properties is properly enabled
this would exactly do, what you were looking for. Since the Xml import by
default ignores protected JCR nodes/properties, we defined plugins for both
Jackrabbit Core and Oak that provides that missing functionality.
For Oak it's documented at
http://jackrabbit.apache.org/oak/docs/security/user/default.html#XML_Import
For Jackrabbit Core there exists no official documentation but the mechanism is
the same: configure the protected item imports you wish to be active in the
workspace.xml of your target workspace. For example something like this:
{code}
[...]
{code}
Hope that helps
> Allow creation of users with existing password hashes
> --
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting
> passwords from existing users; we have no public API facing way to create
> users with existing password hashes. We currently have to resort to using
> reflection, grabbing internal tree objects, and a bunch of nastiness that we
> would love to avoid with this change.
> Other consumers may also find this useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608278#comment-15608278
]
angela commented on JCRVLT-111:
---
sure... to be honest, I originally planned to provide tests with decent
coverage but I found myself struggling with the tests present and feared that i
would spend way to much time on this. if you can provide me with some
instructions or explanation on how test-coverage in jackrabbit filevault is
organized I will be happy to provide tests.
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4002) CSRF in Jackrabbit-Webdav using empty content-type
[
https://issues.apache.org/jira/browse/JCR-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422374#comment-15422374
]
angela commented on JCR-4002:
-
looks good to me.
> CSRF in Jackrabbit-Webdav using empty content-type
> --
>
> Key: JCR-4002
> URL: https://issues.apache.org/jira/browse/JCR-4002
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.13.1
>Reporter: Dominique Jäggi
>Assignee: Dominique Jäggi
> Labels: csrf, security, webdav
> Fix For: 2.13.2
>
> Attachments:
> JCR_4002__CSRF_in_Jackrabbit_Webdav_using_empty_content_type.patch
>
>
> As per [0] the CSRF content-type check does not include a null request
> content type. This can be exploited to create a resource via CSRF like so:
> {code}
>
>
>
> function submitRequest()
> {
> var xhr = new XMLHttpRequest();
> xhr.open("POST", "http://localhost:42427/test/csrf.txt";, true);
> xhr.withCredentials = true;
> var body = "This file has been uploaded via CSRF.=\r\n";
> var aBody = new Uint8Array(body.length);
> for (var i = 0; i < aBody.length; i++)
> aBody[i] = body.charCodeAt(i);
> xhr.send(new Blob([aBody]));
> }
>
>
>/>
>
>
>
> {code}
> I will mitigate this particular issue by including a null content type in the
> list of rejected content types.
> [0] https://github.com/cryptomator/cryptomator/issues/319
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329008#comment-15329008
]
angela edited comment on JCRVLT-111 at 8/2/16 2:25 PM:
---
initial untested draft illustrating the nature of the new
{{PrincipalSetPolicy}} and where the API contract of {{ACLManagement}} probably
needs to be altered.
also, i was a bit confused wrt the naming... for me _ACL_ stands for _Access
Control List_ but what i was looking for was the ability to handle any types of
policies. please also note that the JCR specification allows for multiple
policies being present with a given path, which is what will happen with that
new type.
was (Author: anchela):
initial untested draft illustrating the nature of the new
{{PrincipalSetPolicy}} and where the API contract of {{ACLManagement}} probably
needs to be altered.
also, i was a bit confused wrt the naming... for me _ACL_ stands for _Access
Control List_ but we i was looking for was the ability to handle any types of
policies. please also note that the JCR specification allows for multiple
policies being present with a given path, which is what will happen with that
new type.
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
