Re: [VOTE] Release Apache Jackrabbit Oak 1.64.0

[Angela Schreiber]

+1

thanks and kind regards
angela


From: Julian Reschke 
Sent: Wednesday, May 22, 2024 21:50
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.64.0

A candidate for the Jackrabbit Oak 1.64.0 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.64.0/

The release candidate is a zip archive of the sources in:

  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.64.0/

The SHA1 checksum of the archive is
897cbbd10644e7b419b68aff47ec1853041fb184.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.64.0
897cbbd10644e7b419b68aff47ec1853041fb184

Please vote on releasing this package as Apache Jackrabbit Oak 1.64.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.64.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.62.0

[Angela Schreiber]

  [x] +1 Release this package as Apache Jackrabbit Oak 1.62.0

kind regards
angela


From: Julian Reschke 
Sent: Wednesday, April 3, 2024 22:57
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.62.0



Please vote on releasing this package as Apache Jackrabbit Oak 1.62.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.62.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.58.0

[Angela Schreiber]

+1

kind regards
angela

From: Julian Reschke 
Sent: Wednesday, October 11, 2023 06:01
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.58.0

EXTERNAL: Use caution when clicking on links or opening attachments.


A candidate for the Jackrabbit Oak 1.58.0 release is available at:

 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fjackrabbit%2Foak%2F1.58.0%2F=05%7C01%7Canchela%40adobe.com%7C2cb5996e757b48f16d4d08dbca0ec926%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638325937080671016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=NRQmrUucPiEo%2Fx6XNPoiWbRcMXOICysJUEoX35HqSGc%3D=0

The release candidate is a zip archive of the sources in:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fjackrabbit-oak%2Ftree%2Fjackrabbit-oak-1.58.0%2F=05%7C01%7Canchela%40adobe.com%7C2cb5996e757b48f16d4d08dbca0ec926%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638325937080671016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AgaHrrE%2F%2F8mLOyRk8M9Hfmcc6MSraldqTBVK9bvP7jM%3D=0

The SHA1 checksum of the archive is
da239d1b25ba60cb8d2d311c9bbb3ef86566a57e.

A staged Maven repository is available for review at:

 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F=05%7C01%7Canchela%40adobe.com%7C2cb5996e757b48f16d4d08dbca0ec926%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638325937080671016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gq4wBqtNcy4CK%2FR0ZB5x4IdFfDQaLtImW%2B6y%2FwS1%2Boo%3D=0

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fjackrabbit=05%7C01%7Canchela%40adobe.com%7C2cb5996e757b48f16d4d08dbca0ec926%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638325937080671016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gCLGvshxBr%2FEwbMqUlQj5WUbcL0WWgIIaHN0XZ0qnFU%3D=0
 $ sh check-release.sh oak 1.58.0
da239d1b25ba60cb8d2d311c9bbb3ef86566a57e

Please vote on releasing this package as Apache Jackrabbit Oak 1.58.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.58.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.54.0

[Angela Schreiber]

+1

thanks a lot
angela


From: Julian Reschke 
Sent: Wednesday, July 19, 2023 18:56
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.54.0



A candidate for the Jackrabbit Oak 1.54.0 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.54.0/

The release candidate is a zip archive of the sources in:

  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.54.0/

The SHA1 checksum of the archive is
95f1b68153a1b3d3adf9e9d8aaac9c90325edbcb.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.54.0
95f1b68153a1b3d3adf9e9d8aaac9c90325edbcb

Please vote on releasing this package as Apache Jackrabbit Oak 1.54.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.54.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.16

[Angela Schreiber]

hi julian

+1 Release this package as Apache Jackrabbit Oak 1.22.16

kind regards
angela


From: Julian Reschke 
Sent: Friday, July 14, 2023 07:38
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.16


A candidate for the Jackrabbit Oak 1.22.16 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.16/

The release candidate is a zip archive of the sources in:

  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.22.16/

The SHA1 checksum of the archive is
ae2700633ea1964c37aaa42a6072502e78d5c4d4.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.22.16
ae2700633ea1964c37aaa42a6072502e78d5c4d4

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.16.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.22.16
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: Moving to Oak 1.50 or newer

[Angela Schreiber]

hi jorge

i believe you can even have a tiny simplification. instead of

if (policy instanceof JackrabbitAccessControlPolicy && policy instanceof 
AccessControlList)

you could write:

if (policy instanceof JackrabbitAccessControlList)

because

interface JackrabbitAccessControlList extends JackrabbitAccessControlPolicy, 
AccessControlList

hope that helps
angela


From: Jorge Flórez 
Sent: Thursday, June 1, 2023 20:37
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Moving to Oak 1.50 or newer

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi Angela.

Thank you. I don't mind being extra careful :) , especially in this matter.
I think I just made all the changes, it seems it is working.

This is the code I used to test getting the entries, in case anyone needs
it (or sees an error).

JackrabbitSession jcrSession = (JackrabbitSession) session;
UserManager um = jcrSession.getUserManager();
Authorizable authorizable = um.getAuthorizable(user);
JackrabbitAccessControlManager accessControlManager =
(JackrabbitAccessControlManager) session.getAccessControlManager();
Principal userPrincipal = authorizable.getPrincipal();
AccessControlPolicy[] policies =
accessControlManager.getEffectivePolicies(Collections.singleton(userPrincipal));
JackrabbitAccessControlPolicy jackrabbitPolicy;
AccessControlList acl;
AccessControlEntry[] entries;
List privs;
String path;
JackrabbitAccessControlEntry jackrabbitEntry;

for (AccessControlPolicy policy : policies) {
if (policy instanceof JackrabbitAccessControlPolicy &&
policy instanceof AccessControlList) {
jackrabbitPolicy = (JackrabbitAccessControlPolicy) policy;
path = jackrabbitPolicy.getPath();
LOG.warn(path);

acl = (AccessControlList) policy;
entries = acl.getAccessControlEntries();

for (AccessControlEntry entry : entries) {
if(entry instanceof JackrabbitAccessControlEntry) {
jackrabbitEntry = (JackrabbitAccessControlEntry) entry;
LOG.warn("\tallow --> " + jackrabbitEntry.isAllow());
privs = new ArrayList<>();
for (Privilege priv : jackrabbitEntry.getPrivileges()) {
privs.add(priv.getName());
}
LOG.warn("\t\t" + privs);
}
}
}
else {
LOG.warn("Unused policy " + policy.getClass().getName());
}
}

Best Regards.

Jorge

El jue, 1 jun 2023 a las 8:43, Angela Schreiber ()
escribió:

> Hi Jorge
>
> I would recommend sticking with JCR/Jackrabbit API again, but I admit that
> I am probably extra careful:
>
>
>   *   test if the AccessControlPolicy is an instanceof AccessControlList
>   *   get the list of AccessControlEntries
>   *   test if an AccessControlEntry is a JackrabbitAccessControlEntry
>
> If you want to use the ImmutableACL for simplicity you should in any case
> assert that a given policy is of that type before casting. That's obviously
> possible.
>
> But obviously it depends on your needs. Just be aware that JCR API is
> pretty flexible and doesn't mandate any particular type of policy to be
> returned. So, relying on impl details may force you to adjust your code.
>
> Hope that helps
> Angela
> 
> From: Jorge Flórez 
> Sent: Thursday, June 1, 2023 15:23
> To: oak-dev@jackrabbit.apache.org 
> Subject: Re: Moving to Oak 1.50 or newer
>
> EXTERNAL: Use caution when clicking on links or opening attachments.
>
>
> Hi Angela, thank you for the suggestion.
>
> I passed from
> if(policy instanceof ImmutableACL)
> to
> if(policy instanceof JackrabbitAccessControlPolicy)
>
> I was a bit hesitant because the debugger was showing ImmutableAcl for
> those elements, but it works :)
>
> Thank you.
>
> I have a question, I have some other similar code that gets the entries
> (List). In that case I guess I should still
> use cast to ImmutableACL?
>
> Regards.
>
> Jorge
>
>
>
> El jue, 1 jun 2023 a las 2:19, Angela Schreiber ( >)
> escribió:
>
> > Hi Jorge
> >
> > Yes, that has changed with OAK-10135<
> > https://issues.apache.org/jira/browse/OAK-10135> for consistency
> reasons.
> >
> > Instead of casting to a spi class (ImmutableAcl) or checking for that
> one,
> > I would suggest you verify that the given effective policy is a
> > JackrabbitAccessControlPolicy. This is the interface that provides the
> > getPath() method.
> >
> > see
> >
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlPolicy.java#L38
> >
> > This way you don't rely on some implementation d

Re: Moving to Oak 1.50 or newer

[Angela Schreiber]

Hi Jorge

I would recommend sticking with JCR/Jackrabbit API again, but I admit that I am 
probably extra careful:


  *   test if the AccessControlPolicy is an instanceof AccessControlList
  *   get the list of AccessControlEntries
  *   test if an AccessControlEntry is a JackrabbitAccessControlEntry

If you want to use the ImmutableACL for simplicity you should in any case 
assert that a given policy is of that type before casting. That's obviously 
possible.

But obviously it depends on your needs. Just be aware that JCR API is pretty 
flexible and doesn't mandate any particular type of policy to be returned. So, 
relying on impl details may force you to adjust your code.

Hope that helps
Angela

From: Jorge Flórez 
Sent: Thursday, June 1, 2023 15:23
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Moving to Oak 1.50 or newer

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi Angela, thank you for the suggestion.

I passed from
if(policy instanceof ImmutableACL)
to
if(policy instanceof JackrabbitAccessControlPolicy)

I was a bit hesitant because the debugger was showing ImmutableAcl for
those elements, but it works :)

Thank you.

I have a question, I have some other similar code that gets the entries
(List). In that case I guess I should still
use cast to ImmutableACL?

Regards.

Jorge



El jue, 1 jun 2023 a las 2:19, Angela Schreiber ()
escribió:

> Hi Jorge
>
> Yes, that has changed with OAK-10135<
> https://issues.apache.org/jira/browse/OAK-10135> for consistency reasons.
>
> Instead of casting to a spi class (ImmutableAcl) or checking for that one,
> I would suggest you verify that the given effective policy is a
> JackrabbitAccessControlPolicy. This is the interface that provides the
> getPath() method.
>
> see
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlPolicy.java#L38
>
> This way you don't rely on some implementation detail and it will work for
> all types of policies provided by any kind of authorization model.
>
> hope that helps
> Angela
> 
> From: Jorge Flórez 
> Sent: Wednesday, May 31, 2023 18:50
> To: oak-dev@jackrabbit.apache.org 
> Subject: Re: Moving to Oak 1.50 or newer
>
> EXTERNAL: Use caution when clicking on links or opening attachments.
>
>
> Hi,
> it would seem there is a difference, when I have to get the node paths that
> have an entry with a specific privilege for a user.
> I am getting a
>
> java.lang.ClassCastException: class
>
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ReadPolicy
> cannot be cast to class
>
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ImmutableACL
>
> Using
>
> JackrabbitSession jcrSession = (JackrabbitSession) session;
> JackrabbitAccessControlManager acMgr = (JackrabbitAccessControlManager)
> jcrSession.getAccessControlManager();
> AccessControlPolicy[] policies =
> acMgr.getEffectivePolicies(Collections.singleton(userPrincipal));
>
> for (AccessControlPolicy policy : policies) {
> p = (ImmutableACL) policy;
> path = p.getPath();
> //...
> }
>
> The getEffectivePolicies method returns objects of type ImmutableACL and an
> object of type ReadPolicy.
> I guess I will just have to check before casting, right?
>
> Jorge
>
> El mar, 23 may 2023 a las 8:24, Jorge Flórez (<
> jorgeeduardoflo...@gmail.com>)
> escribió:
>
> > Hi Marcel,
> > thank you for your reply. Regarding MongoDB, it looks like we are
> covered.
> > I need to make some changes in my source code regarding the tika and
> > tika-parsers version. And I got some warnings in the server log like
> >
> > WFLYSRV0003: Could not index class com/google/common/io/Closer.class
> > WFLYSRV0003: Could not index class
> > com/google/common/util/concurrent/AbstractListeningExecutorService.class
> > WFLYSRV0003: Could not index class
> > org/apache/jackrabbit/guava/common/io/Closer.class
> >
> > But besides that, it seems it will work :)
> > I will let you all know if something comes up.
> >
> > Best Regards.
> > Jorge
> >
> > El lun, 22 may 2023 a las 3:26, Marcel Reutegger
> > () escribió:
> >
> >> Hi Jorge,
> >>
> >> On 16.05.23, 20:37, "Jorge Flórez" 
> wrote:
> >> > we are planning to update our oak dependencies, from 1.12.0 to 1.50.0
> >> > (or maybe 1.52.0). We are aware that we need to use Java 11 (already
> >> > using it) and update our Mongo servers. It seems it will be to
> version 6
> >> > (not my decision). If I have existing repositories created and fil

Re: Moving to Oak 1.50 or newer

[Angela Schreiber]

Hi Jorge

Yes, that has changed with 
OAK-10135 for consistency 
reasons.

Instead of casting to a spi class (ImmutableAcl) or checking for that one, I 
would suggest you verify that the given effective policy is a 
JackrabbitAccessControlPolicy. This is the interface that provides the 
getPath() method.

see 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlPolicy.java#L38

This way you don't rely on some implementation detail and it will work for all 
types of policies provided by any kind of authorization model.

hope that helps
Angela

From: Jorge Flórez 
Sent: Wednesday, May 31, 2023 18:50
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Moving to Oak 1.50 or newer

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,
it would seem there is a difference, when I have to get the node paths that
have an entry with a specific privilege for a user.
I am getting a

java.lang.ClassCastException: class
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ReadPolicy
cannot be cast to class
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ImmutableACL

Using

JackrabbitSession jcrSession = (JackrabbitSession) session;
JackrabbitAccessControlManager acMgr = (JackrabbitAccessControlManager)
jcrSession.getAccessControlManager();
AccessControlPolicy[] policies =
acMgr.getEffectivePolicies(Collections.singleton(userPrincipal));

for (AccessControlPolicy policy : policies) {
p = (ImmutableACL) policy;
path = p.getPath();
//...
}

The getEffectivePolicies method returns objects of type ImmutableACL and an
object of type ReadPolicy.
I guess I will just have to check before casting, right?

Jorge

El mar, 23 may 2023 a las 8:24, Jorge Flórez ()
escribió:

> Hi Marcel,
> thank you for your reply. Regarding MongoDB, it looks like we are covered.
> I need to make some changes in my source code regarding the tika and
> tika-parsers version. And I got some warnings in the server log like
>
> WFLYSRV0003: Could not index class com/google/common/io/Closer.class
> WFLYSRV0003: Could not index class
> com/google/common/util/concurrent/AbstractListeningExecutorService.class
> WFLYSRV0003: Could not index class
> org/apache/jackrabbit/guava/common/io/Closer.class
>
> But besides that, it seems it will work :)
> I will let you all know if something comes up.
>
> Best Regards.
> Jorge
>
> El lun, 22 may 2023 a las 3:26, Marcel Reutegger
> () escribió:
>
>> Hi Jorge,
>>
>> On 16.05.23, 20:37, "Jorge Flórez"  wrote:
>> > we are planning to update our oak dependencies, from 1.12.0 to 1.50.0
>> > (or maybe 1.52.0). We are aware that we need to use Java 11 (already
>> > using it) and update our Mongo servers. It seems it will be to version 6
>> > (not my decision). If I have existing repositories created and filled
>> > using 1.12.0, should I do something additional to make them work with
>> > the latest version of Oak?
>>
>> From a DocumentNodeStore perspective, I'm not aware of anything you need
>> to do for the update. The MongoDB Java driver is compatible with MongoDB
>> 6.0, but please note, our automated tests currently do not exercise this
>> combination. I suggest you properly test and report back if you identify
>> any issues on MongoDB 6.0.
>>
>> Regards
>> Marcel
>>
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.52.0

[Angela Schreiber]

+1

kind regards and thanks a lot for take care of the release
angela


From: Julian Reschke 
Sent: Wednesday, May 10, 2023 18:52
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.52.0


A candidate for the Jackrabbit Oak 1.52.0 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.52.0/

The release candidate is a zip archive of the sources in:

  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.52.0/

The SHA1 checksum of the archive is
9122bc1cba321049992ad5c915a7658cb43db0c5.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.52.0
9122bc1cba321049992ad5c915a7658cb43db0c5

Please vote on releasing this package as Apache Jackrabbit Oak 1.52.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.52.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: Referential Integrity of Access Control Policies

[Angela Schreiber]

Hi Konrad

There exists no automatic cleanup for access control entries bound to a 
specific principal or path.

If the tree where the policy is stored gets deleted (or any of it's parents for 
that matter) the policy node will be removed. This may or may not be the 
access-controlled tree where the policy (or it's entries) take effect (see JCR 
specification about the effect of access control policies). Alternatively, the 
policy itself can be removed using AccessControlManager#removePolicy.

In other words:

  *   you can have/define resource-based ACEs for non-existing principals
  *   you can have/define principal-based ACEs for non-existing paths

Hope that helps
Angela




From: Konrad Windszus 
Sent: Friday, April 28, 2023 11:53
To: oak-dev@jackrabbit.apache.org 
Subject: Referential Integrity of Access Control Policies


Hi,
How are access control policies supposed to behave in case the referenced 
principal or node path is deleted? Are they automatically cleaned up?

They are automatically deleted whenever the parent node is being deleted (while 
for resource based ACLs this is expected and makes sense for principal ACLs 
this may sometimes lead to surprises).

I would like to add a paragraph to both 
https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html
 and https://jackrabbit.apache.org/oak/docs/security/accesscontrol/default.html 
to document this, so I would appreciate some pointers.

Thanks in advance,
Konrad

Re: How to check if user is anonymous

[Angela Schreiber]

Hi Konrad

There is no public API to check that as it is an implementation detail that the 
unauthenticated guest session is in oak backed by a user.

So, I suspect the question you want to have an answer for is whether a given 
JCR session is an unauthenticated guest session or not. Is that correct?

In the context of a Sling request the API to call would be 
https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html#getUserPrincipal--
 : a null return value corresponds to the anonymous access.

In Jcr/Oak no corresponding method exist as it usually does not matter through 
which authentication mechanism a given session has been obtained.

But maybe you want to share a bit of context on what you aim to achieve?

Kind regards
Angela



From: Konrad Windszus 
Sent: Wednesday, April 12, 2023 10:49
To: oak-dev@jackrabbit.apache.org 
Subject: How to check if user is anonymous

EXTERNAL: Use caution when clicking on links or opening attachments.


How do I figure out if a org.apache.jackrabbit.api.security.user.User object is 
representing the anonymous user[1] or not.
Unfortunately the interface only has methods isAdmin and isSystemUser [2]
Any pointers appreciated.
Thanks in advance,
Konrad


[1] - 
https://jackrabbit.apache.org/oak/docs/security/user/default.html#anonymous-user
[2] - 
https://javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/org/apache/jackrabbit/api/security/user/User.html

Re: OAK-7182: Make it possible to update Guava

[Angela Schreiber]

ciao julian

the plan sound reasonable to me it's overdue that we get this done, so any 
progress is good IMHO.

kind regards
angela


From: Julian Reschke 
Sent: Monday, February 6, 2023 11:51
To: oak-dev@jackrabbit.apache.org 
Subject: OAK-7182: Make it possible to update Guava



Hi,

I just updated the ticket with a proposed timeline (see
):

OAK 1.48.0 (January 2023)

 bump up default logging levels for deprecated APIs to "warn"
(OAK-10047)

OAK 1.50.0 (March 2023)

 switch to Java 11 und use "forRemoval" deprecations for APIs
exposing Guava (OAK-10007)
 bump up default logging levels for deprecated APIs to "error"
(OAK-10086)

OAK 1.52.0 (May 2023)

 introduce wrapped Guava project for Oak-internal use (OAK-9989)

OAK 1.54.0

 remove deprecated APIs exposing Guava


...feedback appreciated.

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.48.0

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.48.0

all checks ok

kind regards
angela

From: Julian Reschke 
Sent: Tuesday, January 24, 2023 12:12
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.48.0

EXTERNAL: Use caution when clicking on links or opening attachments.


A candidate for the Jackrabbit Oak 1.48.0 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.48.0/

The release candidate is a zip archive of the sources in:

  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.48.0/

The SHA1 checksum of the archive is
a1067257ff94be8edb274cace5a0b503a2dc2fc4.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.48.0
a1067257ff94be8edb274cace5a0b503a2dc2fc4

Please vote on releasing this package as Apache Jackrabbit Oak 1.48.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.48.0
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: Jackrabbit Oak 1.48.0 Release Plan

[Angela Schreiber]

Hi Julian
I hurried up and pushed my changes... the rest can wait for 1.50.0.
So, feel free to cut the release as planned.

Thanks a lot for taking care of it and kind regards
angela

From: Julian Reschke 
Sent: Thursday, January 19, 2023 18:20
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Jackrabbit Oak 1.48.0 Release Plan

EXTERNAL: Use caution when clicking on links or opening attachments.


On 19.01.2023 14:25, Angela Schreiber wrote:
> Hi Julian
>
> I would like to include one more fix and verify a couple of things for 1.48.0
> Unless it is super urgent, I would suggest postponing it for one week.
>
> Please let me know if that would work.
>
> Kind regards
> Angela

I'd like to get 1.48.0 out so that we have a functional release of
oak-run again *and* then switch to Java 11 (which blocks at least one
other change).

So, postponing is ok, but I'd like to avoid postponing more than
absolutely needed.

Best regards, Julian

Re: Jackrabbit Oak 1.48.0 Release Plan

[Angela Schreiber]

Hi Julian

I would like to include one more fix and verify a couple of things for 1.48.0
Unless it is super urgent, I would suggest postponing it for one week.

Please let me know if that would work.

Kind regards
Angela


From: Julian Reschke 
Sent: Thursday, January 19, 2023 14:04
To: oak-dev@jackrabbit.apache.org 
Subject: Jackrabbit Oak 1.48.0 Release Plan

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,

I'm planning to cut Jackrabbit Oak 1.48.0 this weekend.

The list of open issues scheduled for 1.48.0 is empty:

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.48.0%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

(after re-scheduling or removing "fixVersion" for some unresolved issues)

The CI tests are passing:

https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/

(most of the time)

The candidate release notes are here:

https://github.com/apache/jackrabbit-oak/blob/OAK-10072/RELEASE-NOTES.txt

If there are any objections please let me know.

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.14

[Angela Schreiber]

+1
angela


From: Nitin Gupta 
Sent: Monday, January 16, 2023 16:41
To: oak-dev@jackrabbit.apache.org ; 
resc...@apache.org 
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.22.14



[X] +1 Release this package as Apache Jackrabbit Oak 1.22.14



[INFO] 

[INFO] Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

[INFO] OS name: "mac os x", version: "10.15.7", arch: "x86_64", family: "mac"

[INFO] Java version: 11.0.2, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home

[INFO] MAVEN_OPTS:

[INFO] 

[INFO] ALL CHECKS OK

[INFO] 


From: Julian Reschke 
Date: Monday, 16 January 2023 at 8:14 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.14
EXTERNAL: Use caution when clicking on links or opening attachments.


A candidate for the Jackrabbit Oak 1.22.14 release is available at:

 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fjackrabbit%2Foak%2F1.22.14%2F=05%7C01%7Cnitigup%40adobe.com%7C51294825753c43bf4b3b08daf7d0237c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638094770564832141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3IL1sTLZqpFjSJmh4MIab%2FjDZBb3NqDqbgldEyeEtPY%3D=0

The release candidate is a zip archive of the sources in:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fjackrabbit-oak%2Ftree%2Fjackrabbit-oak-1.22.14%2F=05%7C01%7Cnitigup%40adobe.com%7C51294825753c43bf4b3b08daf7d0237c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638094770564832141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=7GB4OYHQPRbRIHfqIx6%2BGNxIBkhYK7vsj5wiIWYoVPo%3D=0

The SHA1 checksum of the archive is
f67ab705f0486a2e6613e616af235d053875de15.

A staged Maven repository is available for review at:

 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F=05%7C01%7Cnitigup%40adobe.com%7C51294825753c43bf4b3b08daf7d0237c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638094770564832141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=w1p2RArLAF8%2BZaRRT7w59SkGh2KYZ5ThI9TSUQNLgAg%3D=0

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fjackrabbit=05%7C01%7Cnitigup%40adobe.com%7C51294825753c43bf4b3b08daf7d0237c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638094770564832141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9IUQTUroxVTbmVlE46ghJMp3X88t9HtcMpv6tm1gJ1g%3D=0
 $ sh check-release.sh oak 1.22.14
f67ab705f0486a2e6613e616af235d053875de15

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.14.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.22.14
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: Authorisation Restrictions: When are those evaluated?

[Angela Schreiber]

hi konrad

> you cannot limit creation of a new node with a specific node type (with a node
> type restriction ACE) nor the migration of an existing node to a certain node
> type to certain principals only.

for changing primary type should be doable if it applies to a dedicated subtree.
what i wanted to state is: if you want it to be enforced for all nodes across 
the whole content tree it might become tricky to manage if additional entries 
allowed writing in a subtree so, the requirement 'for a given principal 
certain restrictions should be applied across the whole repository content' 
cannot easily be reflected with the resource-based access control model afaik.

for adding nodes: note that jcr:addChildNodes privilege is evaluated on the 
parent and not for the node to be added. so, the restriction would need to be 
applied with an ACE that grants/denies adding the jcr:primaryType property 
which is mandatory for all nodes and thus is an indication of the add-node 
operation.

> Therefore it is probably reasonable to document that it is not reasonable to 
> use
> property evaluating restrictions with write permissions

i wouldn't say that though. one just has to be aware that add/remove node is 
granted on the parent (remove also on the node itself).

kind regards
angela



From: Konrad Windszus 
Sent: Tuesday, January 10, 2023 11:15
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Authorisation Restrictions: When are those evaluated?

EXTERNAL: Use caution when clicking on links or opening attachments.


Thanks Angela for the response and happy new year to you as well

> On 10. Jan 2023, at 10:27, Angela Schreiber  wrote:
>
> the current restriction API does not allow to limit to/for certain 
> principals. restrictions are not aware of the principal a given entry is 
> evaluated for but are only aware of the path and the item the permissions 
> applies to.

The question was more whether the item which is evaluated by the restriction in 
the case of write operations is the before or after state in the repository.

I guess it is just the before state, which means that you cannot limit creation 
of a new node with a specific node type (with a node type restriction ACE) nor 
the migration of an existing node to a certain node type to certain principals 
only.

Therefore it is probably reasonable to document that it is not reasonable to 
use property evaluating restrictions with write permissions, am I right?


Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Angela Schreiber]

hi konrad
happy new year and sorry for the delay in responding!

restrictions are part of the permission evaluation. so read operations will 
respect restrictions upon access of items and write operations are checked by 
the PermissionValidator (i.e. during commit).

there are one or two limited cases where permissions are additionally checked 
in the JCR layer when the check was needed for JCR compliance but not possible 
in oak.

the current restriction API does not allow to limit to/for certain principals. 
restrictions are not aware of the principal a given entry is evaluated for but 
are only aware of the path and the item the permissions applies to.

in other words: if you want to reliably limit/allow writing of certain nodes 
for a given principal i don't think it's doable with restrictions today. you 
could bind an ACE for a given principal and a restriction to the root node but 
the effect might then be overwritten by a different entry down in the hierarchy.

maybe you can elaborate a bit on the use case? maybe there is way to address 
this in a reliable way.

kind regards
angela



From: Konrad Windszus 
Sent: Wednesday, December 28, 2022 15:45
To: oak-dev@jackrabbit.apache.org 
Subject: Authorisation Restrictions: When are those evaluated?

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,
I haven’t found any hint in 
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html 
on when the restrictions are being evaluated.
Is it before the changes have been committed, afterwards or both?

This is particularly crucial to know for restrictions evaluating properties 
which are modified through a commit (e.g. a node name through Session.move(…), 
a property value modification via Node.setProperty(…), a primary type change 
via Node.setPrimaryType()).

For example is it possible to restrict writing of nodes with a particular type 
(irrespective of their location and parent node structure) to only a certain 
principal?

Thanks in advance,
Konrad

Re: Unresolved Conflict Question

[Angela Schreiber]

Hi Jorge

Thanks for your contribution and the PR. I will take a look today.

Kind regards
Angela

From: Jorge Flórez 
Sent: Tuesday, December 6, 2022 19:54
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Unresolved Conflict Question

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,
I am sorry for the extremely late reply. The last weeks have been very
difficult. I created https://issues.apache.org/jira/browse/OAK-10025 and I
think I created a pull request (I think, I am new in this matter).
I added this to the ticket:
https://github.com/apache/jackrabbit-oak/pull/786.


Best Regards.
Jorge

El mar, 15 nov 2022 a las 7:52, Angela Schreiber ()
escribió:

> hi jorge
>
> imho this would be a great addition to the oak documentation e.g. linked
> into the section https://jackrabbit.apache.org/oak/docs/dos_and_donts.html
>
> would it be possible for you to create ticket and a PR for oak-doc?
>
> kind regards
> angela
> 
> From: Jorge Flórez 
> Sent: Monday, November 14, 2022 21:32
> To: oak-dev@jackrabbit.apache.org 
> Subject: Re: Unresolved Conflict Question
>
> EXTERNAL: Use caution when clicking on links or opening attachments.
>
>
> Hi,
> after some reading, testing and debugging, I think I understand how it
> works. So I thought write something if anyone is in the same situation:
>
> - There are no nodes (I think) with a "conflict" state in a content
> repository. I searched the paths reported in my log with conflicts and
> found no indicator (special mixin, child nodes, properties, etc). The
> rep:MergeConflict is "added" by the AnnotatingConflictHandler in runtime so
> the ConflictValidator checks if the node "has" that mixin and then throws a
> CommitFailedException, discarding the changes that were about to be saved.
> It is not like that mixin is added to the node in the repository.
>
> - To avoid or minimize conflicts:
> 1. Try to keep the JCR sessions as short as possible. i.e. create the
> session, make changes, call session.save(), call session.logout. If you
> need to do something additional in the repository, a few lines after (maybe
> after some processing that could take some time), create the session again
> and repeat.
>
> 2. Try to use session.refresh(true) before saving, if you think that some
> significant time can pass between the login() and the session.save() call.
>
> 3. You could write your own conflict handler and add it when configuring
> your Oak or WhiteBoard instances. Only if you know what you are doing (i.e.
> you know how to resolve conflict in each one of the possible situations).
> By default, the AnnotatingConflictHandler instance will discard your
> changes and your commit will fail. The worst that will happen is that some
> changes were not persisted (if you are ok with that).
> Please check
> org.apache.jackrabbit.oak.plugins.commit.JcrLastModifiedConflictHandler. It
> seems like a good example to follow.
>
> 4. Enable the DEBUG level on
> org.apache.jackrabbit.oak.plugins.commit.MergingNodeStateDiff and
> org.apache.jackrabbit.oak.plugins.commit.ConflictValidator loggers if you
> want to have more information on the circumstances of a conflict that
> happened in a point of time.
>
> References
>
> https://cqdump.joerghoh.de/2015/11/02/aem-anti-pattern-long-running-sessions/
>
> https://cqdump.joerghoh.de/2015/12/22/how-can-i-avoid-oak-writemerge-conflicts/
> https://jackrabbit.apache.org/oak/docs/FAQ.html
>
> https://adapt.to/content/dam/adaptto/production/presentations/2015/adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf/_jcr_content/renditions/original./adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf
>
> Thanks.
>
> Jorge
>
>
> El mié, 5 oct 2022 a las 10:58, Jorge Flórez (<
> jorgeeduardoflo...@gmail.com>)
> escribió:
>
> > Hi,
> >
> > in a production log I have some messages like this one:
> >
> > javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
> in
> > /F/EDTG/2010286E/00_Hoja_Control_2017_T5.pdf
> > at
> >
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:238)
> > at
> >
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213)
> > at
> >
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669)
> > at
> >
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495)
> >

Re: Unresolved Conflict Question

[Angela Schreiber]

hi jorge

imho this would be a great addition to the oak documentation e.g. linked into 
the section https://jackrabbit.apache.org/oak/docs/dos_and_donts.html

would it be possible for you to create ticket and a PR for oak-doc?

kind regards
angela

From: Jorge Flórez 
Sent: Monday, November 14, 2022 21:32
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Unresolved Conflict Question

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,
after some reading, testing and debugging, I think I understand how it
works. So I thought write something if anyone is in the same situation:

- There are no nodes (I think) with a "conflict" state in a content
repository. I searched the paths reported in my log with conflicts and
found no indicator (special mixin, child nodes, properties, etc). The
rep:MergeConflict is "added" by the AnnotatingConflictHandler in runtime so
the ConflictValidator checks if the node "has" that mixin and then throws a
CommitFailedException, discarding the changes that were about to be saved.
It is not like that mixin is added to the node in the repository.

- To avoid or minimize conflicts:
1. Try to keep the JCR sessions as short as possible. i.e. create the
session, make changes, call session.save(), call session.logout. If you
need to do something additional in the repository, a few lines after (maybe
after some processing that could take some time), create the session again
and repeat.

2. Try to use session.refresh(true) before saving, if you think that some
significant time can pass between the login() and the session.save() call.

3. You could write your own conflict handler and add it when configuring
your Oak or WhiteBoard instances. Only if you know what you are doing (i.e.
you know how to resolve conflict in each one of the possible situations).
By default, the AnnotatingConflictHandler instance will discard your
changes and your commit will fail. The worst that will happen is that some
changes were not persisted (if you are ok with that).
Please check
org.apache.jackrabbit.oak.plugins.commit.JcrLastModifiedConflictHandler. It
seems like a good example to follow.

4. Enable the DEBUG level on
org.apache.jackrabbit.oak.plugins.commit.MergingNodeStateDiff and
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator loggers if you
want to have more information on the circumstances of a conflict that
happened in a point of time.

References
https://cqdump.joerghoh.de/2015/11/02/aem-anti-pattern-long-running-sessions/
https://cqdump.joerghoh.de/2015/12/22/how-can-i-avoid-oak-writemerge-conflicts/
https://jackrabbit.apache.org/oak/docs/FAQ.html
https://adapt.to/content/dam/adaptto/production/presentations/2015/adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf/_jcr_content/renditions/original./adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf

Thanks.

Jorge


El mié, 5 oct 2022 a las 10:58, Jorge Flórez ()
escribió:

> Hi,
>
> in a production log I have some messages like this one:
>
> javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in
> /F/EDTG/2010286E/00_Hoja_Control_2017_T5.pdf
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:238)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:420)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273)
> at
> deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:417)
>
> I have been reading and I think I got some understanding, but I still have
> questions:
>
> 1 Does the past message mean that the node cannot be modified further in
> any way?
> 2 As far as I know, some conflict handlers are added to my JCR instance by
> default:
> RepMembersConflictHandler, JcrLastModifiedConflictHandler,
> AnnotatingConflictHandler and one wrapper. If my guess is correct, the
> "conflict" was managed by the AnnotatingConflictHandler which always
> returns *Resolution.THEIRS* and adds rep:MergeConflict mixin to the node.
> Does this mean that all I have to do is remove the mixin to get rid of
> "OakState0001: Unresolved conflicts"?
> 3 Or should I write my own handler that for example always returns 
> *Resolution.THEIRS
> *and that's it? or in the handler I have to manually make the respective
> changes in all of the events?
>
> I hope I have been clear. Thanks in advance.
>
> Regards.
>
> Jorge
>
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.44.0

[Angela Schreiber]

+1

kind regards
angela


From: Marcel Reutegger 
Sent: Tuesday, July 12, 2022 5:16 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.44.0


Hi,

A candidate for the Jackrabbit Oak 1.44.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.44.0/

The release candidate is a zip archive of the sources in:

 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.44.0/

The SHA1 checksum of the archive is 9953efef17ffe2d09e963462b47a8b483603615f.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.44.0 9953efef17ffe2d09e963462b47a8b483603615f

Please vote on releasing this package as Apache Jackrabbit Oak 1.44.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.44.0
[ ] -1 Do not release this package because...

Regards
Marcel

Re: OAK-9712: blob-cloud-azure instead of segment-azure?

[Angela Schreiber]

hi

regarding missing license headers: would it be an option to run the check as 
part of the default build?

i usually build oak multiple times before pushing any changes and having the 
license header check included would help me.

wdyt?
angela



From: Miroslav Smiljanic 
Sent: Monday, March 14, 2022 6:41 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: OAK-9712: blob-cloud-azure instead of segment-azure?

Hi,

Recently I experienced a problem with another PR build, and it seemed
caused by build infrastructure issues.

This time, I thought the same is happening again, and before merging PR
(that added new test cases and updated doc), run tests locally.

I am sorry I have rushed with the PR approval that caused project build
issues later on.

Matt, your suggestion sounds reasonable.

Regards,
Miroslav


On Thu, Mar 10, 2022 at 4:33 PM Marcel Reutegger 
wrote:

> Hi,
>
> On 08.03.22, 15:55, "Matt Ryan"  wrote:
> > - Open issues, questions, concerns, etc. in tickets and PRs must be
> > addressed satisfactorily before code is committed.
>
> I agree. To me it seems like changes for OAK-9712 were rushed in.
> The PR also had failed checks for most of the modules, because
> a license header was missing. I admit, a missing license header
> is not a big deal. But it looks like for this PR the Jenkins test results
> were simply ignored and impact could have been worse.
>
> Regards
> Marcel
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.11

[Angela Schreiber]

[x ] +1 Release this package as Apache Jackrabbit Oak 1.22.11

kind regards
angela


From: Nitin Gupta 
Sent: Tuesday, February 22, 2022 7:39 AM
To: oak-dev@jackrabbit.apache.org
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.11

A candidate for the Jackrabbit Oak 1.22.11 release is available at:


https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.11/


The release candidate is a zip archive of the sources in:


 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.22.11/


The SHA1 checksum of the archive is a30de1acef87debdcc73773d434529c4ab287283.


A staged Maven repository is available for review at:


https://repository.apache.org/


The command for running automated checks against this release candidate is:


# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit

$ sh check-release.sh oak 1.22.11 a30de1acef87debdcc73773d434529c4ab287283


Please vote on releasing this package as Apache Jackrabbit Oak 1.22.11.

The vote is open for the next 72 hours and passes if a majority of at

least three +1 Jackrabbit PMC votes are cast.


[ ] +1 Release this package as Apache Jackrabbit Oak 1.22.11

[ ] -1 Do not release this package because...

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.26

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.8.26

all checks ok

kind regards
angela


From: Miroslav Smiljanic 
Sent: Tuesday, February 1, 2022 10:46 AM
To: oak-dev@jackrabbit.apache.org
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.8.26

[X] +1 Release this package as Apache Jackrabbit Oak 1.8.26

[INFO] 5. Compare SCM tag with src zip contents
[INFO]
[INFO]Exporting SCM tag...
[INFO]Unzipping jackrabbit-oak-1.8.26-src.zip...
[INFO]Comparing sources...
[INFO]
[INFO]OK: No differences found
[INFO]
[INFO] 6. Build the release candidate
[INFO]
[INFO]Running the Maven build: mvn clean verify -Ppedantic
[INFO]
[INFO]OK: mvn clean verify -Ppedantic
[INFO]
[INFO]

[INFO] Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
[INFO] OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
[INFO] Java version: 11.0.6, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-11.0.6.jdk/Contents/Home
[INFO] MAVEN_OPTS:
[INFO]

[INFO] ALL CHECKS OK

On Tue, Feb 1, 2022 at 9:38 AM Nitin Gupta  wrote:

>  [X] +1 Release this package as Apache Jackrabbit Oak 1.8.26
>
>
> [INFO]
> 
> [INFO] Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> [INFO] OS name: "mac os x", version: "10.15.7", arch: "x86_64", family:
> "mac"
> [INFO] Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> [INFO] MAVEN_OPTS:
> [INFO]
> 
> [INFO] ALL CHECKS OK
> [INFO]
> 
>
>
> Regards,
> Nitin
>
>
> On Tue, Feb 1, 2022 at 1:34 PM Nitin Gupta  wrote:
> >
> > A candidate for the Jackrabbit Oak 1.8.26 release is available at:
> >
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.26/
> >
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> > https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.8.26/
> >
> >
> > The SHA1 checksum of the archive is
> 94170b7d173fa85998abe93994aaa573ccf257ee.
> >
> >
> > A staged Maven repository is available for review at:
> >
> >
> > https://repository.apache.org/
> >
> >
> > The command for running automated checks against this release candidate
> is:
> >
> >
> > # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> >
> > $ sh check-release.sh oak 1.8.26
> 94170b7d173fa85998abe93994aaa573ccf257ee
> >
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.8.26.
> >
> > The vote is open for the next 72 hours and passes if a majority of at
> >
> > least three +1 Jackrabbit PMC votes are cast.
> >
> >
> > [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.26
> >
> > [ ] -1 Do not release this package because...
> >
> >
> > Regards,
> > Nitin
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.10

[Angela Schreiber]

 [X] +1 Release this package as Apache Jackrabbit Oak 1.22.10

all checks ok

kind regards
angela


From: Nitin Gupta 
Sent: Thursday, January 20, 2022 11:55 AM
To: oak-dev@jackrabbit.apache.org
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.22.10

 [X] +1 Release this package as Apache Jackrabbit Oak 1.22.10

All checks OK

...

[INFO] 

[INFO] Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

[INFO] OS name: "mac os x", version: "10.15.7", arch: "x86_64", family: "mac"

[INFO] Java version: 11.0.2, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home

[INFO] MAVEN_OPTS:

[INFO] 

[INFO] ALL CHECKS OK

[INFO] 

...


On Thu, Jan 20, 2022 at 4:21 PM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.22.10 release is available at:
>
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.10/
>
>
> The release candidate is a zip archive of the sources in:
>
>
>  https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.22.10/
>
>
> The SHA1 checksum of the archive is 3bee22a6a915a7cac395538df9254eaedfb6e639.
>
>
> A staged Maven repository is available for review at:
>
>
> https://repository.apache.org/
>
>
> The command for running automated checks against this release candidate is:
>
>
> # run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
>
> $ sh check-release.sh oak 1.22.10 3bee22a6a915a7cac395538df9254eaedfb6e639
>
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.10.
>
> The vote is open for the next 72 hours and passes if a majority of at
>
> least three +1 Jackrabbit PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.22.10
>
> [ ] -1 Do not release this package because...

Re: Property "rep:fullname" on rep:User nodes

[Angela Schreiber]

Hi Konrad

The default value doesn't make sense IMHO and should not have been added in the 
first place.
It is however covered by the node type of users/groups as they allow for 
arbitrary properties being written below the user node (or some subtree for 
that matter).

I would be a bit reluctant though to drop it without a compelling reason.
If we conclude in the oak team that is likely not used anywhere and the default 
value really bothers us, we can obviously drop it.

Kind regards
Angela

From: Konrad Windszus 
Sent: Wednesday, January 19, 2022 3:46 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Property "rep:fullname" on rep:User nodes

Hi,
In the default sync handler I found a mapping from "cn" to "rep:fullname" 
(https://github.com/apache/jackrabbit-oak/blob/91a2b5aa48432ea5349499e8287ea05bcb02fada/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncConfigImpl.java#L91).

The property "rep:fullname" seems to be an arbitrary property name though, as 
it is not part of the node type definition outlined at 
https://jackrabbit.apache.org/oak/docs/security/user/default.html#Representation_in_the_Repository.
Also I couldn't find this property name in the Oak codebase except for in the 
default sync handler 
(https://github.com/apache/jackrabbit-oak/search?q=rep%3Afullname).

Is there any reason why I should set this property in User nodes or does that 
only exist for legacy reasons?
Who is expected to read from this property?

Thanks,
Konrad

Re: Oak-it-osgi module

[Angela Schreiber]

Hi Carlo

In the various security related modules I used 
org.apache.sling.testing.osgi-mock to test the OSGi setup.
I never used oak-it-osgi as a base for tests.

Kind regards
Angela



From: Carlo Jelmini 
Sent: Tuesday, January 18, 2022 3:54 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Oak-it-osgi module

Hi Angela,

I agree with the idea. However, what is then the best approach to add OSGi 
integration tests in other modules, without duplicating the Pax-Exam setup? 
Does it make sense to use oak-it-osgi as a test dependency (using the “tests” 
classifier)?

Regards,
Carlo

From: Angela Schreiber 
Date: Tuesday, 18 January 2022 at 08:43
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Oak-it-osgi module
Hi Carlo

The oak-it-osgi module is IMHO not particularly well maintained and I would 
rather add the tests to the very modules the belong to.

Kind regards
Angela





From: Carlo Jelmini 
Sent: Monday, January 17, 2022 4:15 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Oak-it-osgi module

Hi,

I’m looking for a good place to add integration tests for the issue “Enable 
configuration of more than one read-only mount in the composite node store“[0] 
and I think the module “oak-it-osgi” is the best candidate.

However, I’m surprised to see that, with the current maven-failsafe-plugin 
configuration, the integration tests are not executed by Maven. Moreover, when 
enabling execution, the tests fail to start the forked OSGi container. Lastly, 
most tests just print to the console, without any assertions.

I have fixed all the above-mentioned issues and I could submit a PR, but now I 
wonder if the module is still maintained or whether I’m misunderstanding its 
purpose.
Is it ok if the integration tests from this module are executed, with actual 
assertions, on each build? Should I then submit my fixes?
If this module is not the right place, where should I move my integration tests 
which validate OSGi configurations for multiple mounts with composite node 
store?

Thanks,

Carlo

[0] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOAK-9553data=04%7C01%7Cjelmini%40adobe.com%7C3eeec7577bda4ec0d6f808d9da5640c5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637780886281304090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MpqgnhPduzRZiKtUkk8mfRXKTp2riu%2FEjmV6TGoet3M%3Dreserved=0

Re: Oak-it-osgi module

[Angela Schreiber]

Hi Carlo

The oak-it-osgi module is IMHO not particularly well maintained and I would 
rather add the tests to the very modules the belong to.

Kind regards
Angela





From: Carlo Jelmini 
Sent: Monday, January 17, 2022 4:15 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Oak-it-osgi module

Hi,

I’m looking for a good place to add integration tests for the issue “Enable 
configuration of more than one read-only mount in the composite node store“[0] 
and I think the module “oak-it-osgi” is the best candidate.

However, I’m surprised to see that, with the current maven-failsafe-plugin 
configuration, the integration tests are not executed by Maven. Moreover, when 
enabling execution, the tests fail to start the forked OSGi container. Lastly, 
most tests just print to the console, without any assertions.

I have fixed all the above-mentioned issues and I could submit a PR, but now I 
wonder if the module is still maintained or whether I’m misunderstanding its 
purpose.
Is it ok if the integration tests from this module are executed, with actual 
assertions, on each build? Should I then submit my fixes?
If this module is not the right place, where should I move my integration tests 
which validate OSGi configurations for multiple mounts with composite node 
store?

Thanks,

Carlo

[0] https://issues.apache.org/jira/browse/OAK-9553

Re: Check if a node has children NOT matching a pattern

[Angela Schreiber]

Hi Jörg

Thanks a lot for reaching out.

IMHO it makes sense to have this reported as feature request for jackrabbit-api 
as there is no easy way to extend the existing JCR Node API contract.

There already exists a JackrabbitNode interface in oak-jackrabbit-api, which we 
could use to add the new functionality.

Would you be able to file a feature request in JIRA for this?
Obviously, a patch or PR would be welcome as well.

Kind regards
Angela

PS: i am wondering why the Pattern param would be named 'notmatchingNodeNames'. 
it could be any kind of regex Pattern, couldn't it?

PS2: for consistency we might also consider adding 
JackrabbitNode.getChildren(Pattern pattern) alongside the new hasChildren 
method.



From: Jörg Hoh 
Sent: Friday, January 14, 2022 11:03 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Check if a node has children NOT matching a pattern

Hi,

I have a requirement to check if a node has child nodes, which do not match
a certain pattern. This is definitely important, because

node.hasChildren()

will return true, if there is a "rep:policy" childnode below it. But this
node is an implementation detail of Oak, and it does not indicate that
there is a "real" child node below this node. The same happens with
"jcr:content" child nodes or other implementation specific nodes, which are
not considered as "independent child nodes" from an application point of
view.
The existing API allows only to check for the presence of child nodes
matching a certain glob (but not "not matching"), so it is of no help for
me.

Right now it is implemented by iterating over the child nodes and returning
when the first child is detected which does not match the above criteria.
This works fine, but it is slow when the child node list is very long (e.g.
hundreds of nodes). Because then just getting the iterator can take
miliseconds, especially when the Oak repo is backed by Mongo.
On top i need to execute this operation quite a number of times within a
single request, so that getting these iterators can consume quite some
time, making my requests slower than they should be.

I would like to have an API similar to the existing API, maybe looking like
this:

node.hasChildren(Pattern notmatchingNodeNames)

which allows me to provide a pattern to it. As soon as a childnode's name
is found not matching the pattern, the function returns true. This would
allow the implementation to iterate only over the minimal number of child
nodes, and I would expect it to be much faster than my existing
implementation for these larger folders.

I know that the JCR API can hardly be extended by this, but having this in
a Util class would be fine as well.

WDYT?

Jörg

--
Cheers,
Jörg Hoh,

https://cqdump.joerghoh.de
Twitter: @joerghoh

Re: [VOTE] Release Apache Jackrabbit Oak 1.42.0

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.42.0

kind regards
angela


From: Miroslav Smiljanic 
Sent: Friday, January 7, 2022 1:04 PM
To: oak-dev@jackrabbit.apache.org
Subject: [VOTE] Release Apache Jackrabbit Oak 1.42.0

Hi All,

A candidate for the Jackrabbit Oak 1.42.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.42.0/

The release candidate is a zip archive of the sources in:

 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.42.0/

The SHA1 checksum of the archive is
552de5af4137f5820d314e3c1f51c069a2c343fb.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.42.0
552de5af4137f5820d314e3c1f51c069a2c343fb

Please vote on releasing this package as Apache Jackrabbit Oak 1.42.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.42.0
[ ] -1 Do not release this package because...

Regards,
Miroslav

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.22

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.6.22

kind regards
angela


From: Julian Reschke 
Sent: Monday, November 15, 2021 2:44 PM
To: oak-dev@jackrabbit.apache.org
Subject: [VOTE] Release Apache Jackrabbit Oak 1.6.22

A candidate for the Jackrabbit Oak 1.6.22 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.22/

The release candidate is a zip archive of the sources in:

 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.6.22/

The SHA1 checksum of the archive is
c092e06ecbac4acaa3507b32696ee85f992dfffc.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.6.22
c092e06ecbac4acaa3507b32696ee85f992dfffc

Please vote on releasing this package as Apache Jackrabbit Oak 1.6.22.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.6.22
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.25

[Angela Schreiber]

hi nitin

[x] +1 Release this package as Apache Jackrabbit Oak 1.8.25

thanks and kind regards
angela

From: Nitin Gupta 
Sent: Monday, November 1, 2021 1:48 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.8.25

A candidate for the Jackrabbit Oak 1.8.25 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.25/

The release candidate is a zip archive of the sources in:

https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.8.25/

The SHA1 checksum of the archive is f25cecbb18bfbcc6beb239ba040de523f1756260.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.8.25 f25cecbb18bfbcc6beb239ba040de523f1756260

Please vote on releasing this package as Apache Jackrabbit Oak 1.8.25.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.8.25
[ ] -1 Do not release this package because...

Regards,
Nitin

Re: trunk compile fails

[Angela Schreiber]

Hi Marco

I just ran the oak build again and it passed.
However, I vaguely remember having seen that very test failing in the past. 
Would you mind creating a JIRA ticket? I think it makes sense for the segment 
teams to take a look.

Kind regards
Angela

From: Marco Piovesana 
Sent: Thursday, October 28, 2021 5:51 PM
To: oak-dev@jackrabbit.apache.org 
Subject: trunk compile fails

Hi all,
I cloned the Oak repo today (28th of october) and, if I run the build
command (*mvn clean install*), I have the following failing test:
*PersistentDiskCacheTest.cleanupTest:126 Segment(s) not cleaned up in cache
expected:<0> but was:<2>*

if I run again the build it will eventually complete correctly. I tried on
two different machines, one linux and one macos, and it happened on both.
Did it happen to anyone else?

Marco.

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.9

[Angela Schreiber]

​+1 Release this package as Apache Jackrabbit Oak 1.22.9

kind regards
angela

From: Nitin Gupta 
Sent: Wednesday, October 6, 2021 12:36 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.9

A candidate for the Jackrabbit Oak 1.22.9 release is available at:


https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.9/


The release candidate is a zip archive of the sources in:


 https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.22.9/


The SHA1 checksum of the archive is
4d152de3d7b6e0893fc18dba9cc2cdb00afeb209.


A staged Maven repository is available for review at:


https://repository.apache.org/


The command for running automated checks against this release candidate is:


# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit

$ sh check-release.sh oak 1.22.9
4d152de3d7b6e0893fc18dba9cc2cdb00afeb209


Please vote on releasing this package as Apache Jackrabbit Oak 1.22.9.

The vote is open for the next 72 hours and passes if a majority of at

least three +1 Jackrabbit PMC votes are cast.


[ ] +1 Release this package as Apache Jackrabbit Oak 1.22.9

[ ] -1 Do not release this package because...

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Angela Schreiber]

hi

IMHO we should not vote on a release if everyone is requied to manually alter 
the check-release.sh in order to verify that the checks are ok.

kind regards
angela

From: Marcel Reutegger 
Sent: Thursday, July 15, 2021 4:14 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

On 15.07.21, 12:05, "Andrei Dulceanu"  wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

Checks OK after I did some manual changes to the check-release.sh as
suggested in https://issues.apache.org/jira/browse/JCR-4706

+1 Release this package as Apache Jackrabbit Oak 1.22.8

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.40.0

[Angela Schreiber]

all checks ok

+1 Release this package as Apache Jackrabbit Oak 1.40.0

kind regards
anggela

From: Miroslav Smiljanic 
Sent: Friday, May 28, 2021 7:49 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.40.0

Hi All,

A candidate for the Jackrabbit Oak 1.40.0 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.40.0/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.40.0/

The SHA1 checksum of the archive is
d44c42205818f815e0e81e097a267aaa7bc1.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.40.0
d44c42205818f815e0e81e097a267aaa7bc1

Please vote on releasing this package as Apache Jackrabbit Oak 1.40.0.
The vote passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.40.0
[ ] -1 Do not release this package because...

Regards,
Miroslav

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.21

[Angela Schreiber]

all checks were ok

+1 Release this package as Apache Jackrabbit Oak 1.6.21

kind regards
angela

From: Nitin Gupta 
Sent: Friday, May 28, 2021 1:12 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.6.21

A candidate for the Jackrabbit Oak 1.6.21 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.21/


The release candidate is a zip archive of the sources in:



https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.6.21/


The SHA1 checksum of the archive is
f10e32bc7840e46af1e8b4b54dff1e3235b889b4.


A staged Maven repository is available for review at:


https://repository.apache.org/


The command for running automated checks against this release candidate is:


# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit

$ sh check-release.sh oak 1.6.21
f10e32bc7840e46af1e8b4b54dff1e3235b889b4


Please vote on releasing this package as Apache Jackrabbit Oak 1.6.21.

The vote is open for the next 72 hours and passes if a majority of at

least three +1 Jackrabbit PMC votes are cast.


[ ] +1 Release this package as Apache Jackrabbit Oak 1.6.21

[ ] -1 Do not release this package because...


Regards,

Nitin

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.7

[Angela Schreiber]

+1
All checks ok

From: Marcel Reutegger 
Sent: Friday, April 9, 2021 12:49 PM
To: Oak devs 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.7

Hi,

A candidate for the Jackrabbit Oak 1.22.7 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.7/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.7/

The SHA1 checksum of the archive is 4a8b7752abbe0d5bb7b58791cf620ec810d9b5ff.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.22.7 4a8b7752abbe0d5bb7b58791cf620ec810d9b5ff

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.7.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.22.7
[ ] -1 Do not release this package because...

Regards
 Marcel

Re: User created date property

[Angela Schreiber]

Hi Jorge

Your observation is correct: Authorizable.getProperty filters out properties in 
the jcr or rep namespace and only returns properties that could also be set 
using Authorizable.setProperty.

If you add mix:created to a given user node (IMHO that is allowed) to have the 
jcr:created property set, you need to get the user node to read the jcr:created 
property. Alternatively, if you wish to avoid having that implementation detail 
(i.e. user is stored as a node) in your application, I suggest using a custom 
'AuthorizableAction' that sets a custom 'created' property upon user creation.

see http://jackrabbit.apache.org/oak/docs/security/user/authorizableaction.html 
for the corresponding documentation. NOTE: i recently fixed that part of the 
documentation. it missed to point to the required-service-ids in the security 
provider (see 
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user/authorizableaction.md?r1=1846652=1885915).
 that is necessary in order to make sure the security provider is only 
registered if all dependencies are properly registered.

Hope that helps
Angela


From: jorgeeflorez 
Sent: Thursday, February 11, 2021 8:37 PM
To: oak-dev@jackrabbit.apache.org 
Subject: User created date property

Hi,
I need to put and use additional properties on users and so far no problems
with those properties. I could even add a mixin to the node that represents
the user! (I am not sure if this is allowed).

It seems that the "jcr:created" property cannot be seen using
Authorizable.getProperty method. Should I get the node using the
autorizable's path and get the property? or should I handle a custom
property for that in this case? I just want to get the date the user was
created...

Thanks.

Jorge

Re: Jackrabbit Oak 1.38.0 release plan

[Angela Schreiber]

hi

afaik the test class you refer to in the ticket summary was added in the light 
of OAK-9275.

kind regards
angela

From: Julian Reschke 
Sent: Thursday, January 21, 2021 3:54 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Jackrabbit Oak 1.38.0 release plan

Am 21.01.2021 um 15:47 schrieb Angela Schreiber:
> hi julian
>
> so far i didn't manage to reproduce the test failure you describe in 
> OAK-9324<https://issues.apache.org/jira/browse/OAK-9324> and nor did i see it 
> failing in the integration. so, not sure this should block the release given 
> that it might be limited to windows.
> also note: the ticket you link as likely root cause for the failing test 
> (OAK-9275<https://issues.apache.org/jira/browse/OAK-9275>) was about 
> restoring test-coverage (caused by 
> OAK-8769<https://issues.apache.org/jira/browse/OAK-8769>).
> ...

Well yes, it most certainly has to do with the Windows platform.

I can only state that tests did pass up to this change, and now they
fail. As such, if there was a release vote, I would have to vote "-1".

If this is not a regression of the code per se, but just tests that did
not run before, then the right thing would be to disable these tests on
Windows, and link that change to the ticket.

Best regards, Julian

Re: Jackrabbit Oak 1.38.0 release plan

[Angela Schreiber]

hi julian

so far i didn't manage to reproduce the test failure you describe in 
OAK-9324 and nor did i see it 
failing in the integration. so, not sure this should block the release given 
that it might be limited to windows.
also note: the ticket you link as likely root cause for the failing test 
(OAK-9275) was about restoring 
test-coverage (caused by 
OAK-8769).

kind regards
angela

From: Julian Reschke 
Sent: Thursday, January 21, 2021 2:55 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Jackrabbit Oak 1.38.0 release plan

Am 21.01.2021 um 14:52 schrieb Andrei Dulceanu:
> Hi all,
>
> I'm planning to cut Jackrabbit Oak 1.38.0 tomorrow.
>
> I transitioned all open issues scheduled for 1.38.0 to 1.40.0:
> ...

See : tests fail on
Windows. I don't think we should release with this issue.

Best regards, Julian

Re: When to update the documentation

[Angela Schreiber]

hi

same here... for new features i usually refer to jira or the released version 
to clarify that it's not available in older versions.

if i remember correctly we discussed this in the past. afaik the conclusion was 
back then that the documentation should reflect the latest trunk as we don't 
keep seperate doc versions for the different branches.

kind regards
angela

From: Andrei Dulceanu 
Sent: Thursday, January 21, 2021 9:42 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: When to update the documentation

Hi Miroslav,

I always included any documentation updates in the same commit introducing
the change. I guess it's more transparent and this way one makes sure not
to forget about it later.

Regards,
Andrei

On Wed, Jan 20, 2021 at 1:13 PM Miroslav Smiljanic 
wrote:

> Hi All,
>
> I have created an issue and proposed a patch to improve execution of
> multiple benchmarks with Oak-Segment-Azure fixture. Feedback in the issue
> is welcome.
>
> https://issues.apache.org/jira/browse/OAK-9328
>
> I have a question about updating the documentation. The patch is
> introducing the new system property which should be documented. In this
> case do we update documentation immediately after applying the patch, or we
> wait till after the next release?
>
> Regards,
> Miroslav
>

Intent to backport OAK-8769

[Angela Schreiber]

Hi

I intend to backport task "OAK-8769 : oak-auth-ldap pom needs maintenance" to 
the 1.22 branch. The fix (among other things) updates the following 
dependencies to more recent versions: org.apache.directory.api:all-api, 
org.apache.mina:mina-core

Let me know if you have any concerns.

Kind regards
Angela

Re: [filevault] Installing users and access control entries in the same package

[Angela Schreiber]

hi robert

glad that it helped.

for features like jackrabbit fvault or sling content distribution the contract 
imposed by the specification seems just a bit too restrictive... also the 
specification doesn't define how principals are managed (easy way out ).
anyway that's why the additional import-behavior option exists both for 
access control content as well as for user management (group membership, 
impersonating principals) in oak.

kind regards
angela

From: Robert Munteanu 
Sent: Tuesday, August 25, 2020 1:24 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: [filevault] Installing users and access control entries in the 
same package

Hi Angela,

On Tue, 2020-08-25 at 07:39 +, Angela Schreiber wrote:
> hi robert
>
> without having a closer look, i would suspect that your repository
> comes with default import-behavior configuration that strictly
> follows JCR specification which mandates a given principal to exist
> when dealing with access control management. oak comes with a variety
> of import-behavior options and if you configure it to be
> 'besteffort', it will allow to create ACEs for principals, which do
> not yet exist.

That does help, thank you. I've swiched the Sling Starter to use this
configuration from now on.

Best regards,

Robert

>
> hope that helps
> angela
> 
> From: Robert Munteanu 
> Sent: Friday, August 21, 2020 6:47 PM
> To: oak-dev@jackrabbit.apache.org 
> Subject: [filevault] Installing users and access control entries in
> the same package
>
> Hi,
>
> I am trying to install a content package that includes:
>
> - two users under /home/users/slingshot
> - content with ACEs that reference the two users under
> /content/slingshot
>
> When installing the content packages I see that the /content entry is
> processed first, leading to errors like
>
>   E  /content/slingshot/users/slingshot1/rep:policy
>   ! org.xml.sax.SAXException:
> javax.jcr.security.AccessControlException: Unknown principal
> slingshot1
> javax.jcr.security.AccessControlException: Unknown principal
> slingshot1
>
> and only later on is the user created
>
>   -  /home
>   -  /home/users
>   A  /home/users/slingshot
>   A  /home/users/slingshot/slingshot1
>
> Obviously, reinstalling the content package fixes the problem but I'm
> looking for a more error-safe way of installing the content package.
>
> How can I install this content package with users and ACEs from
> without
> errors?
>
> Thanks,
> Robert
>

Re: [filevault] Installing users and access control entries in the same package

[Angela Schreiber]

hi robert

without having a closer look, i would suspect that your repository comes with 
default import-behavior configuration that strictly follows JCR specification 
which mandates a given principal to exist when dealing with access control 
management. oak comes with a variety of import-behavior options and if you 
configure it to be 'besteffort', it will allow to create ACEs for principals, 
which do not yet exist.

hope that helps
angela

From: Robert Munteanu 
Sent: Friday, August 21, 2020 6:47 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [filevault] Installing users and access control entries in the same 
package

Hi,

I am trying to install a content package that includes:

- two users under /home/users/slingshot
- content with ACEs that reference the two users under
/content/slingshot

When installing the content packages I see that the /content entry is
processed first, leading to errors like

  E  /content/slingshot/users/slingshot1/rep:policy
  ! org.xml.sax.SAXException:
javax.jcr.security.AccessControlException: Unknown principal slingshot1
javax.jcr.security.AccessControlException: Unknown principal slingshot1

and only later on is the user created

  -  /home
  -  /home/users
  A  /home/users/slingshot
  A  /home/users/slingshot/slingshot1

Obviously, reinstalling the content package fixes the problem but I'm
looking for a more error-safe way of installing the content package.

How can I install this content package with users and ACEs from without
errors?

Thanks,
Robert

Re: Slow performance in AbstractNodeState.equals

[Angela Schreiber]

Hi Alexander

Thanks for creating a JIRA ticket. I added a comment mentioning those 
committers that to my knowledge have been working on this and have insight in 
order to review your report and patch.

Hope that helps
Angela

From: Alexander Lüders 
Sent: Wednesday, July 29, 2020 12:08 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Slow performance in AbstractNodeState.equals

Hi Angela,

thanks for taking the time to respond.
I did as you suggested and created a ticket here:
https://issues.apache.org/jira/browse/OAK-9158

Best regards,
Alex

Am 28.07.2020 um 10:10 schrieb Angela Schreiber:
> Hi Alexander
>
> Thanks for the detailed report and analysis.
> May I suggest that you create a ticket at
> https://issues.apache.org/jira/projects/OAK/issues
> <https://issues.apache.org/jira/projects/OAK/issues> with component
> documentmk providing all the details and attaching the patch? I think
> that's the best way to move forward.
>
> Unfortunately, I am not sufficiently familiar with that area of Oak to
> review the proposed modification, but Marcel Reutegger and Julian
> Reschke will for sure be able to provide you with feedback and
> suggestions and I would suggest you ping them directly in the Jira ticket.
>
> Kind regards
> Angela
>
>
> 
> *From:* Alexander Lüders 
> *Sent:* Friday, July 24, 2020 3:19 PM
> *To:* oak-dev@jackrabbit.apache.org 
> *Subject:* Re: Slow performance in AbstractNodeState.equals
> Hi again,
>
> digging deeper I derived following patch which solved the performance
> issue:
>
> Index:
> oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===
> ---
> oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
> (revision 17ea60b0bfb0ca3670c99208170a774a6c99fdfc)
> +++
> oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
> (date 1595575140063)
> @@ -83,7 +83,11 @@
>  // revision does not match: might still be equals
>  } else if (that instanceof ModifiedNodeState) {
>  ModifiedNodeState modified = (ModifiedNodeState) that;
> -if (modified.getBaseState() == this) {
> +NodeState baseState = modified.getBaseState();
> +if (baseState instanceof ModifiedDocumentNodeState) {
> +baseState = ((ModifiedDocumentNodeState)
> baseState).getBaseState();
> +}
> +if (baseState == this) {
>  return EqualsDiff.equals(this, modified);
>  }
>  }
>
> I am not entirely sure that this is correct but comparing with the
> /ModifiedDocumentNodeState#equals/ method, I assume it to be.
> The latter method compares the passed object with its baseState not
> the /ModifiedDocumentNodeState/ instance itself. This is the prime
> difference when comparing the differences of
> /ModifiedDocumentNodeState#equals/ and /AbstractNodeDocumentState#equals/.
> The patch above transfers that logic to
> /AbstractNodeDocumentState#equals/.
>
> What do you think?
>
> Many thanks for your help.
> Best regards,
> Alexander Lüders
>
> Am 23.07.2020 um 17:26 schrieb Alexander Lüders:
>> Dear Jackrabbit Oak developers,
>>
>> we are currently trying to hunt down a performance issue we are
>> facing at a customer site.
>> We strongly need your help on this so any comments would be greatly
>> appreciated.
>>
>> We have a MongoDB as a backend of a Oak repository where we see
>> hundreds of expensive queries being executed during a rather simple
>> operation.
>> It happens when we are saving a session in which we added a child
>> node to a node already containing a very large number of children.
>> This has not been the case with Jackrabbit Oak 1.4.8 and 1.4.26 but
>> it is an issue with 1.10.8 and 1.22.3.
>> Newer versions have not been tested yet but looking at the source we
>> believe that they will show that performance issue too.
>>
>> What we know so far:
>>
>> * The queries against the /MongoDocumentStore /are triggered via
>> /AbstractNodeState.equals/ (see stacktrace below)
>> * A TODO "inefficient unless there are very few child nodes" in that
>> method indicates poor performance but this has been there since a
>> long time and cannot explain the issue
>> * OAK-7401 introduc

Re: Node type definition update

[Angela Schreiber]

Hi Philipp

Looking at the code of NodeTypeRegistry.register it also ends up calling 
NodeTypeManager.registerNodeTypes. Without having a closer look I would expect 
this to work the same. But there might be subtle differences, which I am not 
aware of that explain the difference.

Would you be able to extract a test-case illustrating the problem and attach it 
to a bug report in the Oak JIRA? that would be great.

thanks and kind regards
Angela



From: Philipp Koetz, mVISE AG 
Sent: Monday, July 27, 2020 3:24 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Node type definition update

Hallo oak devs and community,

we are currently looking for a way to update our node type definitions using 
the cnd file. First of all, we are using OAK 1.6.20.

In general we create our custom node types via a cnd file

   NodeTypeRegistry.register(root, cndFileStream, 
"custom node types");

This worked mostly fine as long as we didn't had changes to these. Now we 
wanted to add an additional value to the value constrain, but on existing 
repositories, these changes are not applied.

We managed to change these by using the NodeTypeManager, defining the node type 
through a  NodeTypeTemplate and register it again.

   NodeTypeTemplate mixin = 
nodeTypeManager.createNodeTypeTemplate();
   ...
   nodeTypeManager.registerNodeType(mixin, true);

My question now is, is there a way to update node type definitions also with 
the cnd file or do we have to us the NodeTypeManager for it and if there is a 
way, how can we archive this?

Mit freundlichen Grüßen / Kind regards
Philipp Koetz

Re: Slow performance in AbstractNodeState.equals

[Angela Schreiber]

Hi Alexander

Thanks for the detailed report and analysis.
May I suggest that you create a ticket at 
https://issues.apache.org/jira/projects/OAK/issues with component documentmk 
providing all the details and attaching the patch? I think that's the best way 
to move forward.

Unfortunately, I am not sufficiently familiar with that area of Oak to review 
the proposed modification, but Marcel Reutegger and Julian Reschke will for 
sure be able to provide you with feedback and suggestions and I would suggest 
you ping them directly in the Jira ticket.

Kind regards
Angela



From: Alexander Lüders 
Sent: Friday, July 24, 2020 3:19 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Slow performance in AbstractNodeState.equals

Hi again,

digging deeper I derived following patch which solved the performance issue:

Index: 
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- 
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
(revision 17ea60b0bfb0ca3670c99208170a774a6c99fdfc)
+++ 
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java
(date 1595575140063)
@@ -83,7 +83,11 @@
 // revision does not match: might still be equals
 } else if (that instanceof ModifiedNodeState) {
 ModifiedNodeState modified = (ModifiedNodeState) that;
-if (modified.getBaseState() == this) {
+NodeState baseState = modified.getBaseState();
+if (baseState instanceof ModifiedDocumentNodeState) {
+baseState = ((ModifiedDocumentNodeState) 
baseState).getBaseState();
+}
+if (baseState == this) {
 return EqualsDiff.equals(this, modified);
 }
 }

I am not entirely sure that this is correct but comparing with the 
ModifiedDocumentNodeState#equals method, I assume it to be.
The latter method compares the passed object with its baseState not the 
ModifiedDocumentNodeState instance itself. This is the prime difference when 
comparing the differences of ModifiedDocumentNodeState#equals and 
AbstractNodeDocumentState#equals.
The patch above transfers that logic to AbstractNodeDocumentState#equals.

What do you think?

Many thanks for your help.
Best regards,
Alexander Lüders

Am 23.07.2020 um 17:26 schrieb Alexander Lüders:
Dear Jackrabbit Oak developers,

we are currently trying to hunt down a performance issue we are facing at a 
customer site.
We strongly need your help on this so any comments would be greatly appreciated.

We have a MongoDB as a backend of a Oak repository where we see hundreds of 
expensive queries being executed during a rather simple operation.
It happens when we are saving a session in which we added a child node to a 
node already containing a very large number of children.
This has not been the case with Jackrabbit Oak 1.4.8 and 1.4.26 but it is an 
issue with 1.10.8 and 1.22.3.
Newer versions have not been tested yet but looking at the source we believe 
that they will show that performance issue too.

What we know so far:

* The queries against the MongoDocumentStore are triggered via 
AbstractNodeState.equals (see stacktrace below)
* A TODO "inefficient unless there are very few child nodes" in that method 
indicates poor performance but this has been there since a long time and cannot 
explain the issue
* OAK-7401 introduced the class ModifiedDocumentNodeState class which is not 
inheriting ModifiedNodeState or AbstractDocumentNodeState (see class 
inheritance diagram)
* AbstractDocumentNodeState#equals is checking against instances of 
ModifiedNodeState and AbstractDocumentNodeState but not 
ModifiedDocumentNodeState.
* AbstractDocumentNodeState#equals triggers the "slow" AbstractNodeState#equals 
as a last resort

We definitely do not see the full picture yet but guessing from a high-level 
perspective it looks like the introduction of ModifiedDocumentNodeState broke 
the equals logic in class AbstractDocumentNodeState.

Would you agree with that conclusion?
Is there anything further I can provide?

Stacktrace:
MongoDocumentStore.query(Collection, String, String, String, long, int) 
line: 609
MongoDocumentStore.query(Collection, String, String, int) line: 598
DocumentNodeStore.readChildDocs(String, String, int) line: 1293
DocumentNodeStore.readChildren(AbstractDocumentNodeState, String, int) line: 
1233
DocumentNodeStore$7.call() line: 1185
DocumentNodeStore$7.call() line: 1182
LocalCache$LocalManualCache$1.load(Object) line: 4724
LocalCache$LoadingValueReference.loadFuture(K, CacheLoader) 
line: 3522
LocalCache$Segment.loadSync(K, int, LoadingValueReference, 
CacheLoader) line: 2315

Re: Multiple property definition for same property

[Angela Schreiber]

Hi Jorge

I am glad, that you were able to clean it up without using special workarounds.
That's good to know.

Kind regards
Angela

From: jorgeeflorez . 
Sent: Tuesday, June 23, 2020 5:07 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Multiple property definition for same property

Hi Angela,

I am not too familiar with the node type registration but I would assume
> that the nodes storing node type definitions are protected and you won't be
> able to remove them using JCR API calls. So, you probably need to resort to
> some low level operations like e.g. the tools in oak-run.
>

well, I used the following code (I simplified it a little bit) and it seems
I could delete all the duplicates.
NodeTypeManager nodeTypeManager =
session.getWorkspace().getNodeTypeManager();
String duplicateDefinitionName = "testProperty";
NodeType repositoryType = nodeTypeManager.getNodeType("oak8961");
NodeTypeTemplate repositoryTypeTemplate =
nodeTypeManager.createNodeTypeTemplate(repositoryType);
boolean definitionFound = false;
List duplicates = new ArrayList<>();
for(Object obj :
repositoryTypeTemplate.getPropertyDefinitionTemplates()){
PropertyDefinitionTemplate definitionTemplate =
(PropertyDefinitionTemplate) obj;


if(definitionTemplate.getName().equals(duplicateDefinitionName)){
if(!definitionFound){
definitionFound = true;
}
else{
duplicates.add(obj);
}
}
}

for(Object obj : duplicates){

repositoryTypeTemplate.getPropertyDefinitionTemplates().remove(obj);
}

nodeTypeManager.registerNodeType(repositoryTypeTemplate, true);
session.save();

Is there any chance you could provide a patch to fix the bug you reported?
> That might help getting it addressed.
>

I will try to look at the source code, in case I find a solution I will let
you know.

Regards.

Jorge

El mar., 23 jun. 2020 a las 1:43, Angela Schreiber
() escribió:

> Hi Jorge
>
> I am not too familiar with the node type registration but I would assume
> that the nodes storing node type definitions are protected and you won't be
> able to remove them using JCR API calls. So, you probably need to resort to
> some low level operations like e.g. the tools in oak-run.
>
> Is there any chance you could provide a patch to fix the bug you reported?
> That might help getting it addressed.
>
> wdyt?
>
> Kind regards
> Angela
> 
> From: jorgeeflorez . 
> Sent: Friday, June 19, 2020 2:30 AM
> To: oak-dev@jackrabbit.apache.org 
> Subject: Re: Multiple property definition for same property
>
> Hi all,
> I just created a maven project, used Oak version 1.30.0 and tested the
> problem I reported on OAK-8961
> <https://issues.apache.org/jira/browse/OAK-8961>. It still happens. I will
> see if I am able to delete the duplicate jcr:propertyDefinition nodes, any
> ideas are welcome :)
>
> Regards.
>
> Jorge
>
> El mié., 18 mar. 2020 a las 11:19, jorgeeflorez . (<
> jorgeeduardoflo...@gmail.com>) escribió:
>
> > Hi Angela,
> > thank you for your help. I created
> > https://issues.apache.org/jira/browse/OAK-8961.
> >
> > Regards.
> >
> > Jorge
> >
> > El mié., 18 mar. 2020 a las 10:09, Angela Schreiber
> > () escribió:
> >
> >> Hi Jorge
> >>
> >> That sounds like a bug to me... after all you will not be able to set
> >> multiple properties that have exactly the same PropertyDefinition and as
> >> far as I remember it should not even be possible to create multiple
> >> properties with the same name.
> >>
> >> Can you create a bug for this in JIRA? As usual detailed steps to
> >> reproduce, test cases or even a patch are very much welcome.
> >>
> >> Kind regards
> >> Angela
> >> 
> >> From: jorgeeflorez . 
> >> Sent: Wednesday, March 18, 2020 3:57 PM
> >> To: oak-dev@jackrabbit.apache.org 
> >> Subject: Multiple property definition for same property
> >>
> >> Hi all,
> >> using the following code, I am able to update an existing node type by
> >> inserting a new property:
> >>
> >> NodeTypeManager nodeTypeManager =
> >> session.getWorkspace().getNodeTypeManager();
> >>
> >> NodeType repositoryType = nodeTypeManager.getNodeType("testType");
> >> NodeTypeTemplate repositoryTypeTemplate =
> >> nodeTypeManager.createNodeTypeTemplate(repositoryType);
> >> PropertyDefinitionTemplate test

Re: Multiple property definition for same property

[Angela Schreiber]

Hi Jorge

I am not too familiar with the node type registration but I would assume that 
the nodes storing node type definitions are protected and you won't be able to 
remove them using JCR API calls. So, you probably need to resort to some low 
level operations like e.g. the tools in oak-run.

Is there any chance you could provide a patch to fix the bug you reported? That 
might help getting it addressed.

wdyt?

Kind regards
Angela

From: jorgeeflorez . 
Sent: Friday, June 19, 2020 2:30 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Multiple property definition for same property

Hi all,
I just created a maven project, used Oak version 1.30.0 and tested the
problem I reported on OAK-8961
<https://issues.apache.org/jira/browse/OAK-8961>. It still happens. I will
see if I am able to delete the duplicate jcr:propertyDefinition nodes, any
ideas are welcome :)

Regards.

Jorge

El mié., 18 mar. 2020 a las 11:19, jorgeeflorez . (<
jorgeeduardoflo...@gmail.com>) escribió:

> Hi Angela,
> thank you for your help. I created
> https://issues.apache.org/jira/browse/OAK-8961.
>
> Regards.
>
> Jorge
>
> El mié., 18 mar. 2020 a las 10:09, Angela Schreiber
> () escribió:
>
>> Hi Jorge
>>
>> That sounds like a bug to me... after all you will not be able to set
>> multiple properties that have exactly the same PropertyDefinition and as
>> far as I remember it should not even be possible to create multiple
>> properties with the same name.
>>
>> Can you create a bug for this in JIRA? As usual detailed steps to
>> reproduce, test cases or even a patch are very much welcome.
>>
>> Kind regards
>> Angela
>> 
>> From: jorgeeflorez . 
>> Sent: Wednesday, March 18, 2020 3:57 PM
>> To: oak-dev@jackrabbit.apache.org 
>> Subject: Multiple property definition for same property
>>
>> Hi all,
>> using the following code, I am able to update an existing node type by
>> inserting a new property:
>>
>> NodeTypeManager nodeTypeManager =
>> session.getWorkspace().getNodeTypeManager();
>>
>> NodeType repositoryType = nodeTypeManager.getNodeType("testType");
>> NodeTypeTemplate repositoryTypeTemplate =
>> nodeTypeManager.createNodeTypeTemplate(repositoryType);
>> PropertyDefinitionTemplate testProperty =
>> nodeTypeManager.createPropertyDefinitionTemplate();
>> testProperty.setName("testProperty");
>> testProperty.setRequiredType(PropertyType.STRING);
>> testProperty.setMandatory(false);
>> testProperty.setMultiple(false);
>> testProperty.setDefaultValues(new Value[0]);
>> testProperty.setValueConstraints(new String[0]);
>> repositoryTypeTemplate.getPropertyDefinitionTemplates().add(testProperty);
>>
>> nodeTypeManager.registerNodeType(repositoryTypeTemplate, true);
>> session.save();
>>
>> I prefer this way, instead using CND
>> <https://jackrabbit.apache.org/jcr/node-type-notation.html> because I
>> understand it better and is cleaner, compared to having everything inside
>> a
>> String (am I doing it correctly?).
>>
>> Because of a bug I was tracking, I found out that, if you invoke this code
>> several times, it will insert a new property definition each time, so in
>> the repository you could end up with this (I removed a lot of stuff to
>> keep
>> it small):
>> {
>> "node": "testType",
>> "path": "/jcr:system/jcr:nodeTypes/testType",
>> "children": [
>> {
>> "node": "jcr:propertyDefinition",
>> "path":
>> "/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition",
>> "properties": [
>> *"jcr:name = testProperty"*
>> ]
>> },
>> {
>> "node": "jcr:propertyDefinition[10]",
>> "path":
>> "/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[10]",
>> "mixins": [],
>> "children": [],
>> "properties": [
>> *"jcr:name = testProperty"*
>> ]
>> },
>> {
>> "node": "jcr:propertyDefinition[2]",
>> "path":
>> "/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[2]",
>> "mixins": [],
>> "children": [],
>> 

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.22

[Angela Schreiber]

hi nitin

the checks were all ok when running checkout from 
https://dist.apache.org/repos/dist/dev/jackrabbit
however, i noticed that the verification of previous releases were executed 
from  https://dist.apache.org/repos/dist/release/jackrabbit.

is there a particular reason for cutting this one from the 'dev' and not from 
the 'release'?
and if not: does it have an implication?

kind regards
angela

From: Nitin Gupta 
Sent: Tuesday, May 19, 2020 11:46 AM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.8.22

A candidate for the Jackrabbit Oak 1.8.22 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.22/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.22/

The SHA1 checksum of the archive is
482328ad73876b5ee1db0af5b885b0b17463986b.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.8.22
482328ad73876b5ee1db0af5b885b0b17463986b

Please vote on releasing this package as Apache Jackrabbit Oak 1.8.22.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.8.22
[ ] -1 Do not release this package because...

Regards,
Nitin

Re: backport OAK-9059 to 1.10 and 1.22

[Angela Schreiber]

hi julian

that's perfect. i wasn't entirely sure about 1.10 but if it's retired i will 
avoid the extra work.
thanks for the information, very much appreciated.

angela



From: Julian Reschke 
Sent: Thursday, May 14, 2020 1:36 PM
To: oak-dev@jackrabbit.apache.org 
Cc: Angela Schreiber 
Subject: Re: backport OAK-9059 to 1.10 and 1.22

On 14.05.2020 13:13, Angela Schreiber wrote:
> hi
>
> i intend to backport the fix for OAK-9059 to the 1.10 and 1.22 branches. the 
> risk should be very limited as it only requires modifications to 
> o.a.j.oak.spi.security.authorization.cug.impl.NestedCugHook.
>
> let me know i you have any concerns.
> ...

+1 for 1.22 - but there's no need to touch the 1.10 branch: it is retired.

Best regards, Julian

backport OAK-9059 to 1.10 and 1.22

[Angela Schreiber]

hi

i intend to backport the fix for OAK-9059 to the 1.10 and 1.22 branches. the 
risk should be very limited as it only requires modifications to 
o.a.j.oak.spi.security.authorization.cug.impl.NestedCugHook.

let me know i you have any concerns.

kind regards
angela

https://issues.apache.org/jira/browse/OAK-9059

Re: Edit group

[Angela Schreiber]

Hi Jorge

I am glad that you found the answer, which is pretty much exactly what I would 
have written in reply to your original question had I seen it. Please apologize 
that it was totally missed.

Maybe I can also point you to the oak-exercise module, which contains 
additional training material wrt Oak security. It's not complete and doesn't 
cover every single feature but the basics are there and may provide additional 
insight.

Kind regards
Angela


From: jorgeeflorez . 
Sent: Wednesday, May 13, 2020 9:00 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Edit group

Hi,
to answer my own question (and "for the record"). The user id or group id
cannot be changed once it is created (see
https://jackrabbit.apache.org/oak/docs/security/user/default.html ).
However, it is possible to set a value for a property with the name you
want to the Authorizable (user or group) and use that property as you see
fit. For example:

UserManager um = session.getUserManager();
Group myGroup = um.createGroup("myAwesomeGroup");
myGroup.setProperty("color" new StringValue("yellow"));

To get the value after you retrieved an authorizable you can use:
UserManager um = session.getUserManager();
Authorizable authorizable = um.getAuthorizable(group.getId());
Value[] propertyValues = authorizable.getProperty("color");
String color = null;
if (propertyValues != null) {
color = propertyValues[0].getString();
}

Jorge

El jue., 7 may. 2020 a las 12:50, jorgeeflorez . (<
jorgeeduardoflo...@gmail.com>) escribió:

> Hi all,
> I was wondering, is it possible to change the name of a group?
> I am not sure about it and I want to confirm it, please.
>
> Thanks.
>
> Best Regards.
>
> Jorge
>

Re: Multiple property definition for same property

[Angela Schreiber]

Hi Jorge

That sounds like a bug to me... after all you will not be able to set multiple 
properties that have exactly the same PropertyDefinition and as far as I 
remember it should not even be possible to create multiple properties with the 
same name.

Can you create a bug for this in JIRA? As usual detailed steps to reproduce, 
test cases or even a patch are very much welcome.

Kind regards
Angela

From: jorgeeflorez . 
Sent: Wednesday, March 18, 2020 3:57 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Multiple property definition for same property

Hi all,
using the following code, I am able to update an existing node type by
inserting a new property:

NodeTypeManager nodeTypeManager =
session.getWorkspace().getNodeTypeManager();

NodeType repositoryType = nodeTypeManager.getNodeType("testType");
NodeTypeTemplate repositoryTypeTemplate =
nodeTypeManager.createNodeTypeTemplate(repositoryType);
PropertyDefinitionTemplate testProperty =
nodeTypeManager.createPropertyDefinitionTemplate();
testProperty.setName("testProperty");
testProperty.setRequiredType(PropertyType.STRING);
testProperty.setMandatory(false);
testProperty.setMultiple(false);
testProperty.setDefaultValues(new Value[0]);
testProperty.setValueConstraints(new String[0]);
repositoryTypeTemplate.getPropertyDefinitionTemplates().add(testProperty);

nodeTypeManager.registerNodeType(repositoryTypeTemplate, true);
session.save();

I prefer this way, instead using CND
 because I
understand it better and is cleaner, compared to having everything inside a
String (am I doing it correctly?).

Because of a bug I was tracking, I found out that, if you invoke this code
several times, it will insert a new property definition each time, so in
the repository you could end up with this (I removed a lot of stuff to keep
it small):
{
"node": "testType",
"path": "/jcr:system/jcr:nodeTypes/testType",
"children": [
{
"node": "jcr:propertyDefinition",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition",
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[10]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[10]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[2]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[2]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[3]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[3]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[4]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[4]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[5]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[5]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[6]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[6]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[7]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[7]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[8]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[8]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "jcr:propertyDefinition[9]",
"path":
"/jcr:system/jcr:nodeTypes/testType/jcr:propertyDefinition[9]",
"mixins": [],
"children": [],
"properties": [
*"jcr:name = testProperty"*
]
},
{
"node": "rep:namedPropertyDefinitions",
"path":

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.21

[Angela Schreiber]

Hi Julian

I got the following error during step 6:

[INFO] 6. Build the release candidate
[INFO]
[INFO]Running the Maven build: mvn clean verify -Ppedantic
[INFO]
[ERROR]   NOT OK: mvn clean verify -Ppedantic
[ERROR]
[ERROR] See ./target/jackrabbit-oak-1.8.21.log for full details.

and from the log file:

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.014 s 
<<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
[ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest)  Time 
elapsed: 3.014 s  <<< ERROR!
com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to 
connect. Client view of cluster state is {type=UNKNOWN, 
servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING, 
exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, 
caused by {java.net.ConnectException: Connection refused (Connection refused)}}]
at org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)

[INFO] Running org.apache.jackrabbit.oak.run.DataStoreCheckTest
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.996 s 
- in org.apache.jackrabbit.oak.run.DataStoreCheckTest
[INFO] Running org.apache.jackrabbit.oak.run.JsonIndexTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.71 s - 
in org.apache.jackrabbit.oak.run.JsonIndexTest
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   UtilsTest.validateMongoUri:38 » MongoTimeout Timed out after 3000 ms 
while wai...
[INFO]

shall i run it again or is this already a blocker for the release?

kind regards
angela




From: Julian Reschke 
Sent: Wednesday, March 18, 2020 8:19 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.8.21

On 18.03.2020 08:16, Julian Reschke wrote:
> ...

[X] +1 Release this package as Apache Jackrabbit Oak 1.8.21

...where...

> [INFO] Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T20:33:14+02:00)
> [INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: 
> "windows"
> [INFO] Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: 
> C:\usr\local\jdk18\jre
> [INFO] MAVEN_OPTS: -Xmx2g

Best regards, Julian

Re: Using Oak External User Sync for a SAML2 Use Case?

[Angela Schreiber]

Hi Cris

I think you have 2 options:

  *   either you synchronize the users/groups in the authentication handler
  *   or you delegate the user/group synchronization to the sync-handler

At Adobe we initially used the first option and moved away from it in favor of 
the second option, because the default sync-handler essentially provides all 
the functionality needed and additionally comes with a couple of optimization 
most notably the dynamic membership option that no longer synchronizes groups 
into the user management but instead just synchronizes the information that is 
needed to properly populate the Subject with principals upon login. The main 
rational behind this: users are managed outside of the repository and therefore 
the repository user management just adds extra complexity, which is not needed 
for the authorization part, which only deals with principals.

For that second option you would the following rough steps as far as I know:

  *   write a custom ExternalIdentityProvider, that is able to authenticate 
your custom crednetials and extract information from it in order to complete 
the sync-step
  *   let Sling Authentication handler pass the information to the repository
  *   register the default (or a custom) SyncHandler
  *   register your ExternalIdentityProvider
  *   configure an ExternalLoginModule entry that uses your 
ExternalIdentityProvider and the SyncHandler you chose to use.

That should do the trick if I am not mistaken. In particular the 
ExternalPrincipalConfiguration will be enabled if you use the default 
SyncHandler with the dynamic membership option enabled.

Hope that helps... maybe there are other means to achieve this, but this is 
more or less what we did at Adobe.

Kind regards
Angela




From: Cris Rockwell 
Sent: Tuesday, March 17, 2020 9:34 PM
To: oak-dev@jackrabbit.apache.org ; 
us...@sling.apache.org 
Subject: Using Oak External User Sync for a SAML2 Use Case?

Hi Oak and Sling Devs

I am working to make a SAML2 Sling Authentication Handler.  This is my project: 
https://github.com/cmrockwell/sling-whiteboard-saml/tree/sling-saml2-service-provider/saml-handler
 

 It has a demo IDP which returns the SAML Security Assertion via a SOAP 
binding. The SAML assertion contains username, attributes and groups. I am 
trying to decide the best way to ...
a) get or create the user
b) add/remove the user to the groups
c) add, change or remove synchronized users attributes.

I am reviewing the Oak External Login Module to see whether it can help with 
this...
https://jackrabbit.apache.org/oak/docs/security/authentication/externalloginmodule.html
 


It says…
 “The external login module has 2 main tasks. One is to authenticate 
credentials against a 3rd party system, the other is to coordinate syncing of 
the respective users and groups with the JCR repository (via the UserManager)."

and
“The synchronization of users and groups is triggered by the external login 
module, after a user is successfully authenticated against the IDP or if it’s 
no longer present on the IDP.”

In LDAP Auth, user credentials are passed from the user to the Oak-based 
application to the External LDAP IDP via External Login Module, which then 
triggers User Sync. In SAML2, authentication happens entirely at the External 
Identify provider (e.g. Shibboleth), and there is no handling of the users 
credentials at the Service Provider (Oak-based application) level. Instead, 
SAML2 Security Assertions are handed to the Sling Authentication Handler / 
Service Provider after authentication when the user is redirected back to the 
Assertion Consumer Servlet (ACS). Which is where my project is stalled a little 
bit.

My Questions..
1. Once my ACS receives the user's SAML2 Assertion (either via SOAP or POST 
bindings), does it make sense to try using Oak’s User and Group 
Synchronization? If so, how would one configure or trigger it? Or should write 
my own user management code?

2. Given my use case, which if any of the Oak External Components should I 
configure?
ExternalLoginModuleFactory
DefaultSyncHandler
ExternalIDPManagerImpl
SyncManagerImpl
ExternalPrincipalConfiguration

Thank you!
Cris Rockwell
Applications Architect Sr
College of Literature, Science, and the Arts | University of Michigan
LSA Technology Services | Suite 505 | 301 E. Libery | Ann Arbor, MI I 48109

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.2

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.22.2

all checks ok

kind regards
angela

From: Nitin Gupta 
Sent: Wednesday, March 11, 2020 9:25 AM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.2

A candidate for the Jackrabbit Oak 1.22.2 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.2/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.2/

The SHA1 checksum of the archive is
c619e7c8eb6f20d2bc71cc4ecb0d7b3a4e619859.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
$ sh check-release.sh oak 1.22.2
c619e7c8eb6f20d2bc71cc4ecb0d7b3a4e619859

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.2.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.22.2
[ ] -1 Do not release this package because...


Regards,
Nitin

Re: custom authentication module

[Angela Schreiber]

Hi Marco

Probably not but I am not aware of another solution from the top of my 
head. If you find one please let me know.

Kind regards
Angela

From: Marco Piovesana 
Sent: Tuesday, March 10, 2020 9:40 AM
To: Angela Schreiber 
Cc: oak-dev@jackrabbit.apache.org 
Subject: Re: custom authentication module

I tried this and it seems to be working:

Configuration currentConfiguration = Configuration.getConfiguration();
Configuration.setConfiguration(new Configuration() {
@Override
public AppConfigurationEntry[] getAppConfigurationEntry(String 
applicationName) {
if 
(AuthenticationConfiguration.DEFAULT_APP_NAME.equals(applicationName)) {
return new AppConfigurationEntry[] {
new 
AppConfigurationEntry(CustomLoginModule.class.getName(), 
LoginModuleControlFlag.SUFFICIENT, new HashMap<>())
};
} else {
return 
currentConfiguration.getAppConfigurationEntry(applicationName);
}
}
});

I guess it's not ideal though. Do you know if there's a way to pass the 
configuration to oak without having to use the static method 
Configuration.setConfiguration?

Marco.

On Tue, Mar 10, 2020 at 8:37 AM Angela Schreiber 
mailto:anch...@adobe.com>> wrote:
Hi Marco

I never had to do that but I would first try to compose the new configuration 
from the existing non-oak entries with additional oak-entries. In other words 
aggregating the result of getConfiguration() with the custom 
AppConfigurationEntry.

Kind regards
Angela

From: Marco Piovesana mailto:pioves...@esteco.com>>
Sent: Monday, March 9, 2020 3:23 PM
To: oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org> 
mailto:oak-dev@jackrabbit.apache.org>>
Subject: Re: custom authentication module

Hi Angela,
I defined a custom configuration as you suggested by doing:

Configuration.setConfiguration(new Configuration() {
@Override
public AppConfigurationEntry[] getAppConfigurationEntry(String
applicationName) {
return new AppConfigurationEntry[] {
new
AppConfigurationEntry(CustomLoginModule.class.getName(),
LoginModuleControlFlag.SUFFICIENT, new HashMap<>())
};
}
});

This works fine when oak is executed standalone, but I have a problem when
I embed it within a JavaEE application. In this case there's already a
configuration for other resources (e.g. jms) and this solution overrides
that configuration.
How can define the login modules for a specific application (in my case
"jackrabbit.oak") without having to redefine the whole Configuration?

Marco.

On Thu, Feb 27, 2020 at 1:49 PM Marco Piovesana 
mailto:pioves...@esteco.com>>
wrote:

> Hi Angela,
> thanks for the clarification! I did see that in L4_userIDTest but I wasn't
> sure it was meant to be used also in production. I've created OAK-8929 for
> the documentation update.
>
> Marco.
>
>
> On Thu, Feb 27, 2020 at 6:50 PM Angela Schreiber 
> wrote:
>
>> Hi Marco
>>
>> The section you are referring to talks about replacing the authentication
>> setup altogether... so replacing all parts of it.
>>
>> However, if your task is 'just' to configure an additional LoginModule or
>> replacing an existing one (but otherwise leaving the broader authentication
>> setup in place), that doesn't require replacing the
>> AuthenticationConfiguration. Instead that should be straight forward by
>> calling
>>
>>
>> javax.security.auth.login.Configuration.setConfiguration(yourCustomConfiguration)
>>
>> yourCustomConfiguration would define which LoginModules are being used
>> for your authentication, their order and a LoginModuleControlFlag for each
>> of them.
>>
>> Since the documentation is apparently not clear about this: may I ask you
>> to create a documentation issue such that we can fix that? Thanks.
>>
>> You can see an example on how this is done in a non-OSGi setup in
>> org.apache.jackrabbit.oak.AbstractSecurityTest that is located in oak-core.
>> From there yo can also find those derived tests that in fact defined a
>> different configuration... there should a few of those floating around in
>> Oak.
>>
>> Hope that helps
>> Angela
>>
>> 
>> From: Marco Piovesana mailto:pioves...@esteco.com>>
>> Sent: Thursday, February 27, 2020 11:00 AM
>> To: oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org> 
>> mailto:oak-dev@jackrabbit.apache.org>>
>> Subject: custom authentication module
>>
>> Hi all,
>> I'm trying to define a custom LoginModule that extends the
>> AbstractLoginModule in a NON-OSGi setup. Reading the documentation here

Re: add ACE containing restrictions throws exception

[Angela Schreiber]

Hi Marco

Yes, that's wired I just had a look at the VersionEditor that throws this 
exception: If OPV is IGNORE the exception will not be raised. And looking at 
the node type definition the rep:restrictions child node definition doesn't 
mark it to be IGNORED (even if the parent ACE node definition is).

So, this probably is a bug in the node type definition. Can you create an issue 
for this?
the rep:restriction child node def should also have OPV IGNORED and then it 
should not raise the exception.

Kind regards
Angela

From: Marco Piovesana 
Sent: Tuesday, March 10, 2020 9:34 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: add ACE containing restrictions throws exception

Hi Angela,
thanks for the reply. It feels a bit weird that I have to check-out a node
to modify something that doesn't affect the versions, but if is mandatory
then ok.

Marco.

On Tue, Mar 10, 2020 at 8:16 AM Angela Schreiber 
wrote:

> Hi Marco
>
> I vaguely remember that the verification for the read-only status of a
> checked-in versionable node does not include the built-in access control
> content. But I don't recall if that because the specification mandates this
> or if it's a bug.
>
> But the error you get is expected: a checked-in node should be immutable.
> So, you first need to call checkout in order to modify it.
>
> Kind regards
> Angela
> 
> From: Marco Piovesana 
> Sent: Thursday, March 5, 2020 12:38 PM
> To: oak-dev@jackrabbit.apache.org 
> Subject: add ACE containing restrictions throws exception
>
> Hi all,
> I'm trying to add an ACE with a custom restriction to a versioned node, but
> when I save the session I get the error:
> *OakVersion0001: Cannot add property jcr:primaryType on checked in node*
>
> If I add the same ACE without the restriction I don't get any error. Is it
> a bug or there is something that I don't understand?
>
> Marco.
>

Re: custom authentication module

[Angela Schreiber]

Hi Marco

I never had to do that but I would first try to compose the new configuration 
from the existing non-oak entries with additional oak-entries. In other words 
aggregating the result of getConfiguration() with the custom 
AppConfigurationEntry.

Kind regards
Angela

From: Marco Piovesana 
Sent: Monday, March 9, 2020 3:23 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: custom authentication module

Hi Angela,
I defined a custom configuration as you suggested by doing:

Configuration.setConfiguration(new Configuration() {
@Override
public AppConfigurationEntry[] getAppConfigurationEntry(String
applicationName) {
return new AppConfigurationEntry[] {
new
AppConfigurationEntry(CustomLoginModule.class.getName(),
LoginModuleControlFlag.SUFFICIENT, new HashMap<>())
};
}
});

This works fine when oak is executed standalone, but I have a problem when
I embed it within a JavaEE application. In this case there's already a
configuration for other resources (e.g. jms) and this solution overrides
that configuration.
How can define the login modules for a specific application (in my case
"jackrabbit.oak") without having to redefine the whole Configuration?

Marco.

On Thu, Feb 27, 2020 at 1:49 PM Marco Piovesana 
wrote:

> Hi Angela,
> thanks for the clarification! I did see that in L4_userIDTest but I wasn't
> sure it was meant to be used also in production. I've created OAK-8929 for
> the documentation update.
>
> Marco.
>
>
> On Thu, Feb 27, 2020 at 6:50 PM Angela Schreiber 
> wrote:
>
>> Hi Marco
>>
>> The section you are referring to talks about replacing the authentication
>> setup altogether... so replacing all parts of it.
>>
>> However, if your task is 'just' to configure an additional LoginModule or
>> replacing an existing one (but otherwise leaving the broader authentication
>> setup in place), that doesn't require replacing the
>> AuthenticationConfiguration. Instead that should be straight forward by
>> calling
>>
>>
>> javax.security.auth.login.Configuration.setConfiguration(yourCustomConfiguration)
>>
>> yourCustomConfiguration would define which LoginModules are being used
>> for your authentication, their order and a LoginModuleControlFlag for each
>> of them.
>>
>> Since the documentation is apparently not clear about this: may I ask you
>> to create a documentation issue such that we can fix that? Thanks.
>>
>> You can see an example on how this is done in a non-OSGi setup in
>> org.apache.jackrabbit.oak.AbstractSecurityTest that is located in oak-core.
>> From there yo can also find those derived tests that in fact defined a
>> different configuration... there should a few of those floating around in
>> Oak.
>>
>> Hope that helps
>> Angela
>>
>> 
>> From: Marco Piovesana 
>> Sent: Thursday, February 27, 2020 11:00 AM
>> To: oak-dev@jackrabbit.apache.org 
>> Subject: custom authentication module
>>
>> Hi all,
>> I'm trying to define a custom LoginModule that extends the
>> AbstractLoginModule in a NON-OSGi setup. Reading the documentation here
>> <https://jackrabbit.apache.org/oak/docs/security/authentication.html> at
>> the section "Pluggability" I think I understood that I have to options to
>> do it: defining my own SecurityProvider or using a JAAS configuration.
>> I tried to look at the source code and the examples but I'm having a hard
>> time understanding exactly how to do it. Is there anyone that can help me
>> out?
>>
>> Marco.
>>
>
>
>

--

marco piovesanA
Enterprise Application



*ESTECO* | EXPLORE DESIGN PERFECTION

AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549
[Website] <http://www.esteco.com> | [Twitter]
<https://twitter.com/esteco_mF> | [Facebook]
<https://www.facebook.com/esteco.spa> | [Linkedin]
<https://www.linkedin.com/company/748217>
Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you. Please consider the
environment before printing this email.

Re: add ACE containing restrictions throws exception

[Angela Schreiber]

Hi Marco

I vaguely remember that the verification for the read-only status of a 
checked-in versionable node does not include the built-in access control 
content. But I don't recall if that because the specification mandates this or 
if it's a bug.

But the error you get is expected: a checked-in node should be immutable. So, 
you first need to call checkout in order to modify it.

Kind regards
Angela

From: Marco Piovesana 
Sent: Thursday, March 5, 2020 12:38 PM
To: oak-dev@jackrabbit.apache.org 
Subject: add ACE containing restrictions throws exception

Hi all,
I'm trying to add an ACE with a custom restriction to a versioned node, but
when I save the session I get the error:
*OakVersion0001: Cannot add property jcr:primaryType on checked in node*

If I add the same ACE without the restriction I don't get any error. Is it
a bug or there is something that I don't understand?

Marco.

Re: custom authentication module

[Angela Schreiber]

Hi Marco

The section you are referring to talks about replacing the authentication setup 
altogether... so replacing all parts of it.

However, if your task is 'just' to configure an additional LoginModule or 
replacing an existing one (but otherwise leaving the broader authentication 
setup in place), that doesn't require replacing the 
AuthenticationConfiguration. Instead that should be straight forward by calling

javax.security.auth.login.Configuration.setConfiguration(yourCustomConfiguration)

yourCustomConfiguration would define which LoginModules are being used for your 
authentication, their order and a LoginModuleControlFlag for each of them.

Since the documentation is apparently not clear about this: may I ask you to 
create a documentation issue such that we can fix that? Thanks.

You can see an example on how this is done in a non-OSGi setup in 
org.apache.jackrabbit.oak.AbstractSecurityTest that is located in oak-core. 
From there yo can also find those derived tests that in fact defined a 
different configuration... there should a few of those floating around in Oak.

Hope that helps
Angela


From: Marco Piovesana 
Sent: Thursday, February 27, 2020 11:00 AM
To: oak-dev@jackrabbit.apache.org 
Subject: custom authentication module

Hi all,
I'm trying to define a custom LoginModule that extends the
AbstractLoginModule in a NON-OSGi setup. Reading the documentation here
 at
the section "Pluggability" I think I understood that I have to options to
do it: defining my own SecurityProvider or using a JAAS configuration.
I tried to look at the source code and the examples but I'm having a hard
time understanding exactly how to do it. Is there anyone that can help me
out?

Marco.

Re: custom restrictions on ACEs

[Angela Schreiber]

Hi Marco

Yes, the extra note regarding performance was intended to remind people that 
expensive calculations may have a negative effect on overall permission 
evaluation performance. If the restriction check is fast, the impact is most 
likely insignificant. But take for example the node type name restriction: if 
one would change this to calculate the effective JCR nodetype with all the 
inheritance and mixins it might be quite slow compare to a simple string 
comparison.

It's just a extra word of caution because I regretted more than once for not 
being explicit in the documentation and assuming what I considered common 
sense. Then realized later on that my understanding of common sense in Oak is 
based on a bit of extra insight. Others may not necessarily have that insight 
such as I am likely shortsighted or ignorant in other areas 

Hope that helps
Angela

From: Marco Piovesana 
Sent: Wednesday, February 26, 2020 11:51 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: custom restrictions on ACEs

hi Angela,
what I want is basically being able, when reading an ACE, to know if it was
created because of a user request or not. So having a property that I can
set when creating the ACE would have been sufficient.
I think that the default authorization process works fine for what I need,
so maybe implementing a custom one
might be an overkill, but thanks for the tip, I didn't know about the
examples.
I have one more question, the documentation says that: "restrictions are
part of the overall permission evaluation and thus may heavily impact
overall read/write performance", that depends on how much work is required
to validate the restriction right? if the validation itself is fast, then
the impact on the performance is very limited, or there are other things
that might decrease the performances?


On Wed, Feb 26, 2020, 5:25 PM Angela Schreiber 
wrote:

> Hi Marco
>
> Depending on what you wish to achieve the restrictions may help. I am not
> sure if fully understood what you are aiming for so it's a bit hard to tell
> if restrictions will really do the trick.
>
> Depending on the actual needs and how well your access control
> requirements fit into the default authorization model, it might be worth
> exploring the ability to provide a custom authorization setup. If you find
> yourself struggling to map your needs to a setup using the default
> authorization, exploring a custom implementation might be worth the effort
> and might also end up being more efficient in terms of maintaining the
> setup and evaluation performance... but it really depends on the details.
> In case you wish to explore that option, you will find some simplistic
> examples/exercises in the oak-exercise module.
>
> The same exercise module also provides a few exercise lessons for
> restrictions and how to write a custom restriction provider. Obviously
> that's a lot easier that writing a custom authorization model.
>
> Hope that helps
> Angela
> 
> From: Marco Piovesana 
> Sent: Wednesday, February 26, 2020 9:13 AM
> To: oak-dev@jackrabbit.apache.org 
> Subject: custom restrictions on ACEs
>
> Hi all,
> I have an application where the ACEs (Access Control Entries) are applied
> to a node by users and by the system itself. By the user when she/he wants
> to share the node with some other users, by the system when the node has to
> be available to some users in automatic, under specific conditions. The
> user should not be able to modify an ACE added by the system.
> Right now, when I read the ACL, I can't tell what ACE has been created by
> the user and what has been created by the system. Reading the documentation
> I saw that one possible solution might be using custom restrictions
> <
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html
> >
> when creating the ACE, but I'm not sure this is one of the intended usage
> for the restrictions. Is there a better solution for this problem?
>
> Marco.
>

Re: custom restrictions on ACEs

[Angela Schreiber]

Hi Marco

Depending on what you wish to achieve the restrictions may help. I am not sure 
if fully understood what you are aiming for so it's a bit hard to tell if 
restrictions will really do the trick.

Depending on the actual needs and how well your access control requirements fit 
into the default authorization model, it might be worth exploring the ability 
to provide a custom authorization setup. If you find yourself struggling to map 
your needs to a setup using the default authorization, exploring a custom 
implementation might be worth the effort and might also end up being more 
efficient in terms of maintaining the setup and evaluation performance... but 
it really depends on the details. In case you wish to explore that option, you 
will find some simplistic examples/exercises in the oak-exercise module.

The same exercise module also provides a few exercise lessons for restrictions 
and how to write a custom restriction provider. Obviously that's a lot easier 
that writing a custom authorization model.

Hope that helps
Angela

From: Marco Piovesana 
Sent: Wednesday, February 26, 2020 9:13 AM
To: oak-dev@jackrabbit.apache.org 
Subject: custom restrictions on ACEs

Hi all,
I have an application where the ACEs (Access Control Entries) are applied
to a node by users and by the system itself. By the user when she/he wants
to share the node with some other users, by the system when the node has to
be available to some users in automatic, under specific conditions. The
user should not be able to modify an ACE added by the system.
Right now, when I read the ACL, I can't tell what ACE has been created by
the user and what has been created by the system. Reading the documentation
I saw that one possible solution might be using custom restrictions

when creating the ACE, but I'm not sure this is one of the intended usage
for the restrictions. Is there a better solution for this problem?

Marco.

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.26

[Angela Schreiber]

[x] +1 Release this package as Apache Jackrabbit Oak 1.4.26

all checks ok

regards
angela

From: Julian Reschke 
Sent: Monday, February 17, 2020 3:00 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.4.26

A candidate for the Jackrabbit Oak 1.4.26 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.26/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.26/

The SHA1 checksum of the archive is
6ec25ff9cf35744f994fdc5565f06f22e7635fb3.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.4.26
6ec25ff9cf35744f994fdc5565f06f22e7635fb3

Please vote on releasing this package as Apache Jackrabbit Oak 1.4.26.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.4.26
 [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.1

[Angela Schreiber]

[x] +1 Release this package as Apache Jackrabbit Oak 1.22.1

all checks ok

angela

From: Julian Reschke 
Sent: Saturday, February 8, 2020 6:29 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.22.1

A candidate for the Jackrabbit Oak 1.22.1 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.1/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.1/

The SHA1 checksum of the archive is
922019a9ac223c0992269f7e6b5c0e7d37f9dedf.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.22.1
922019a9ac223c0992269f7e6b5c0e7d37f9dedf

Please vote on releasing this package as Apache Jackrabbit Oak 1.22.1.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.22.1
 [ ] -1 Do not release this package because...

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.20

[Angela Schreiber]

[x] +1 Release this package as Apache Jackrabbit Oak 1.6.20

all checks ok

angela

From: Julian Reschke 
Sent: Friday, January 31, 2020 10:54 AM
To: oak-dev@jackrabbit.apache.org 
Subject: [VOTE] Release Apache Jackrabbit Oak 1.6.20

A candidate for the Jackrabbit Oak 1.6.20 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.20/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.6.20/

The SHA1 checksum of the archive is
add478a770af02b8ec3eda49e10ed340123452b5.

A staged Maven repository is available for review at:

 https://repository.apache.org/

The command for running automated checks against this release candidate is:

 # run in SVN checkout of
https://dist.apache.org/repos/dist/dev/jackrabbit
 $ sh check-release.sh oak 1.6.20
add478a770af02b8ec3eda49e10ed340123452b5

Please vote on releasing this package as Apache Jackrabbit Oak 1.6.20.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit Oak 1.6.20
 [ ] -1 Do not release this package because...

intend to backport OAK-8855

[Angela Schreiber]

hi

i would like to back port the fix for 
OAK-8855.
let me know if you have any concerns.

kind regards
angela

Re: [PROPOSAL] Branch 1.22.0

[Angela Schreiber]

Hi Julian

Given the fact that with the CVE announced yesterday, we encouraged everyone 
using 1.12.0 - 1.22.0 to upgrade to 1.24.0, your second variant (releasing 
1.26.0 shortly and branching 1.24.0 instead) would feel a bit better to me... 
for the sake of communication consistency.

That's as far as the security area is concerned the only significant diff 
between 1.22 and 1.24.

Kind regards
Angela


From: Julian Reschke 
Sent: Wednesday, January 29, 2020 4:44 PM
To: oak-dev@jackrabbit.apache.org ; Angela 
Schreiber 
Subject: Re: [PROPOSAL] Branch 1.22.0

On 29.01.2020 16:25, Angela Schreiber wrote:
> Hi Julian
>
> Not sure I got the explanation regarding 'why not branching 1.24.0' in 
> relation to the required changes regarding OAK-7947. According to jira that 
> issue got fix in 
> 1.12.0<https://issues.apache.org/jira/issues/?jql=project+%3D+OAK+AND+fixVersion+%3D+1.12.0>,
>  right? So isn't the same 'flip lazy loading of lucene index' needed 
> irrespective of whether we branch 1.22.0 or 1.24.0? And wouldn't the same 
> 'newer' question you explained below also apply when branching 1.22.0?
>
> I guess I am missing one piece in that reasoning... otherwise I don't have a 
> strong preference and would be find with the proposal.
>
> Angela

The default would need to be flipped in any case, right.

The only difference is that if we released 1.24.1 instead if 1.22.1,
users of 1.24.0 might incorrectly assume that this is a release they
should upgrade to.

That of course could be addressed by quickly releasing 1.26.0 as well,
but as we just released 1.24.0 yesterday...

Best regards, Julian

Re: [PROPOSAL] Branch 1.22.0

[Angela Schreiber]

Hi Julian

Not sure I got the explanation regarding 'why not branching 1.24.0' in relation 
to the required changes regarding OAK-7947. According to jira that issue got 
fix in 
1.12.0,
 right? So isn't the same 'flip lazy loading of lucene index' needed 
irrespective of whether we branch 1.22.0 or 1.24.0? And wouldn't the same 
'newer' question you explained below also apply when branching 1.22.0?

I guess I am missing one piece in that reasoning... otherwise I don't have a 
strong preference and would be find with the proposal.

Angela

From: Julian Reschke 
Sent: Wednesday, January 29, 2020 3:03 PM
To: oak-dev@jackrabbit.apache.org 
Subject: [PROPOSAL] Branch 1.22.0

Hello team.

When we introduced the new release/branching strategy last March, it was
clear that we might have to create branches once incompatible changes
happen.

Now is the time. (Well, soon).

 will make incompatible
changes (so that we can compile & run on Java 14). I therefore propose
to create a branch, from which we can continue to cut releases that are
fully compatible with 1.22.0.

The good news is that we have confirmed that 1.22.* can be used as
drop-in replacement for 1.10.*, thus at the same time (or close to it)
we could retire 1.10.

The only issue we found was due to slightly changed system behaviour
when lazy loading of Lucene index files is in effect. I would therefore
propose to disable that feature in the first release from that branch
(see , there's a system
property for this, we would just have to flip the default value).

(And yes, this proposal is equivalent to just replay *any* change made
in trunk to 1.10.*)

The concrete steps would be:

- create the branch based on the tag 1.22.0
- flip the default for lazy loading of Lucene index files
- backport selected changes from trunk (such as related to yesterday's CVE)
- release 1.22.1
- (later on) retire 1.10.*

As to why not to branch based on 1.24.0: I'd like to avoid any confusion
about what is "newer". If we released 1.24.1 people might think this is
something to upgrade from 1.24.0 from (and that would be incorrect due
to the change related to OAK-7947).


Feedback appreciated,

Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.20

[Angela Schreiber]

[X] +1 Release this package as Apache Jackrabbit Oak 1.8.20

all checks were ok.

kind regards
angela

From: Woonsan Ko 
Sent: Tuesday, January 28, 2020 11:07 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: [VOTE] Release Apache Jackrabbit Oak 1.8.20

[X] +1 Release this package as Apache Jackrabbit Oak 1.8.20

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.15.2", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Tue, Jan 28, 2020 at 2:33 PM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit Oak 1.8.20 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.20/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.20/
>
> The SHA1 checksum of the archive is
> 8a5f0ed4cd1351bee9a244e410957dfd5425aa80.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
>  $ sh check-release.sh oak 1.8.20
> 8a5f0ed4cd1351bee9a244e410957dfd5425aa80
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.20.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.20
>  [ ] -1 Do not release this package because...

Intent to backport OAK-8870

[Angela Schreiber]

Hi

I'd like to backport OAK-8870 [1] to the maintenance branches. The fix is 
simple and I consider the risk associated with the backport as low. Let me know 
if you have any concerns.

Kind regards
Angela

[1] https://issues.apache.org/jira/browse/OAK-8870

Re: Deprecating API signatures referring to Guava in 1.10

[Angela Schreiber]

Hi Marcel

That sounds reasonable to me.

Kind regards
Angela

From: Marcel Reutegger 
Sent: Monday, December 9, 2019 2:15 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Deprecating API signatures referring to Guava in 1.10

Hi,

On 06.12.19, 14:07, "Julian Reschke"  wrote:
> once we do a stable release from trunk with the removal (say, 1.26),
> there would be no officially supported Oak release which deprecates the
> API. That is, 1.10.* (and earlier) would contain the old API (and not
> deprecate it), 1.26.0 (and later) would only contain the new API.

I agree that it would be good to have a smooth migration path between
supported releases. But then, backporting changes to a maintenance branch
that are rather enhancements also looks a bit odd to me.

Alternatively, we could declare 1.24 a long term support release and
create a branch at that point. Given our previous discussion around
when to branch, it is something we should consider anyway.

https://jackrabbit.apache.org/oak/docs/release-schedule.html#Branching

Applications on 1.10 using deprecated API would then upgrade to 1.24
first, change the application to use the new API and then finally upgrade
to 1.26 (or whatever more recent that is compatible).

Regards
 Marcel

Re: Deprecating API signatures referring to Guava in 1.10

[Angela Schreiber]

Hi Julian


From: Julian Reschke 
Sent: Thursday, December 5, 2019 5:39 PM
To: Angela Schreiber ; oak-dev@jackrabbit.apache.org 

Subject: Re: Deprecating API signatures referring to Guava in 1.10

On 05.12.2019 16:49, Angela Schreiber wrote:
> Hi Julian
>
> I can't speak for Adobe AEM product management (the product you are
> referring to) and their release planning for the near future. But I
> would be surprised if there wasn't a way forward handling potential
> upgrade issues when it comes to the breaking change in future.

Such as?

Who said that the next release will contain an Oak version with a breaking 
change?
If you have that information or even information about when the next release is 
planned in the first place and based on which version of Oak, I am happy to 
hear that.

> The implications of the java.security.acl.Group deprecation (and
> ultimate removal in java 14) were pretty limited within Adobe AEM and we
> might want to get an idea how big the impact on custom code for the
> Guava story actually is. Wdyt?

Yes, and that will happen. But it's a distinct question, no?

​I don't think so, no
> ...

Best regards, Julian

Kind regards
Angela

Re: Deprecating API signatures referring to Guava in 1.10

[Angela Schreiber]

Hi Julian

I can't speak for Adobe AEM product management (the product you are referring 
to) and their release planning for the near future. But I would be surprised if 
there wasn't a way forward handling potential upgrade issues when it comes to 
the breaking change in future.

The implications of the java.security.acl.Group deprecation (and ultimate 
removal in java 14) were pretty limited within Adobe AEM and we might want to 
get an idea how big the impact on custom code for the Guava story actually is. 
Wdyt?

I remember a few breaking changes with Oak in the past and I don't recall this 
causing huge disruptions with the AEM code base or with customers code. So, if 
we can get an assessment regarding the changes at hand, that would for sure 
also help with the discussion here and with product management.

Kind regards
Angela




From: Julian Reschke 
Sent: Thursday, December 5, 2019 4:12 PM
To: Angela Schreiber ; oak-dev@jackrabbit.apache.org 

Subject: Re: Deprecating API signatures referring to Guava in 1.10

On 05.12.2019 16:00, Angela Schreiber wrote:
> Hi Julian
>
> Sorry, but I still don't get why we have to back port the deprecation
> plus replacements to 1.10. If we remove the API in Oak 1.26 there are at
> a whole bunch of official releases between the deprecation/replacement
> and the release where the breaking change occurs.

Yes, but as you know, products based on Oak frequently are based on the
latest maintenance branch, not the now quickly moving releases from
trunk. People on 1.10.* will not be aware of the deprecation, nor will
they have a replacement API to use.

(The alternative would be to deprecate but not to include the
replacement API; but I would consider that really lame)

> I don't recall at which specific version the Guava replacement was
> introduced, but for the similar java.security.acl.Group issue Alex
> Deparvu introduced the replacement almost 2 years ago to give consumers
> an early heads up (back in time when we only had an official release
> every year).

Yes, that's a related but different issue. We deprecated these APIs in
1.10, so we're good.

> Wouldn't it be better to push for updating upstream applications to use
> a more recent stable release of Oak? That would already give them the

If we can do that, great. Do you have a concrete idea how to achieve
that for the product we're both concerned with?

> chance to make use of the replacement without us going through the
> trouble of backporting all those changes? I just see a real risk that we
> end up with semantic version number in different branches that don't
> exactly match.
> ...

That would be bad. But it's something that can work when done carefully
(which is my intent).

Best regards, Julian

Re: Intent to backport to 1.10: OAK-8018

[Angela Schreiber]

Hi Julian

But why do we have to align Oak 1.10 with trunk now that we have stable release 
on regular basis instead of releasing only once a year?

IMO it would be better and a lot less risky to push for updating to a more 
recent version of Oak that already includes the reeplacements than back porting 
the huge number of API changes we made over the last couple of years.

Kind regards
Angela



From: Julian Reschke 
Sent: Thursday, December 5, 2019 2:38 PM
To: oak-dev@jackrabbit.apache.org ; Angela 
Schreiber 
Subject: Re: Intent to backport to 1.10: OAK-8018

On 05.12.2019 13:51, Angela Schreiber wrote:
> Hi Julian
>
> This changes with OAK-8018 modified public API as far as I can see and I 
> vaguely remember that we concluded in the past that we want to avoid back 
> porting anything that is not a critical bug and be particularly careful not 
> to back port API changes.

Backporting the API change is the whole point here; it's a prerequisite
to align 1.10's API with the one in trunk.

I recall that we discussed backports a few years ago, but I actually do
not recall the concrete conclusion (do you have a pointer?).

In this case, it's obviously a conflict between backporting minor
changes and being able to backport something that (IMHO) is needed in
1.10. We can't do the latter without doing the former.

We *did* actually discuss backporting API changes in the past, and the
conclusion IMHO was: do it only if you understand the consequences with
respect to public package version numbers. That's what I'm trying to do
here. See also
<http://jackrabbit.apache.org/jcr/creating-releases.html#Appendix_E:_Version_Changes>.

> I would appreciate if you could wait with that back port until we reached a 
> consensus on the broader goal as you announced in the previous thread 
> "Deprecating API signatures referring to Guava in 1.10".

Looking forward to your feedback on that one.

Best regards, Julian

Re: Deprecating API signatures referring to Guava in 1.10

[Angela Schreiber]

Hi Julian

Sorry, but I still don't get why we have to back port the deprecation plus 
replacements to 1.10. If we remove the API in Oak 1.26 there are at a whole 
bunch of official releases between the deprecation/replacement and the release 
where the breaking change occurs.

I don't recall at which specific version the Guava replacement was introduced, 
but for the similar java.security.acl.Group issue Alex Deparvu introduced the 
replacement almost 2 years ago to give consumers an early heads up (back in 
time when we only had an official release every year).

Wouldn't it be better to push for updating upstream applications to use a more 
recent stable release of Oak? That would already give them the chance to make 
use of the replacement without us going through the trouble of backporting all 
those changes? I just see a real risk that we end up with semantic version 
number in different branches that don't exactly match.

Kind regards
Angela

From: Julian Reschke 
Sent: Thursday, December 5, 2019 2:55 PM
To: oak-dev@jackrabbit.apache.org ; Angela 
Schreiber 
Subject: Re: Deprecating API signatures referring to Guava in 1.10

On 05.12.2019 13:41, Angela Schreiber wrote:
> Hi Julian
>
> Maybe you could elaborate a bit more about the reasoning of backporting the 
> deprecated API signatures using Guava 1.10? The reason for the deprecation 
> was the fact that we want to make breaking changes, right? And this is the 
> kind of change I would feel quite uncomfortable with when it comes to back 
> port... when it's just about the deprecation, I am not sure I understand the 
> bigger benefit of the back port... or do I misunderstand the overall goal 
> behind this?
> ...

What I intend to backport are the changes that (a) deprecate the
existing API (that uses Guava) *and* (b) introduce replacements. Part
(b) is the one that will actually change the API (but in a
backward-compatible manner -> minor version change).

The reason for backporting to 1.10 is that this is the newest
maintenance branch we have. If we actually remove the Guava-based API in
a future trunk release (say 1.26.0), people migrating from 1.10.* to
that version would be very surprised (and have no supported version to
move to first which contains the replacement APIs).

Hopefully this clarifies things...

Best regards, Julian

Re: Intent to backport to 1.10: OAK-8018

[Angela Schreiber]

Hi Julian

This changes with OAK-8018 modified public API as far as I can see and I 
vaguely remember that we concluded in the past that we want to avoid back 
porting anything that is not a critical bug and be particularly careful not to 
back port API changes.

I would appreciate if you could wait with that back port until we reached a 
consensus on the broader goal as you announced in the previous thread 
"Deprecating API signatures referring to Guava in 1.10".

Thanks and kind regards
Angela

From: Julian Reschke 
Sent: Thursday, December 5, 2019 1:34 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Intent to backport to 1.10: OAK-8018

: "Move LazyValue from
oak-core to oak-commons"

See also previous message "Deprecating API signatures referring to Guava
in 1.10"
().

Best regards, Julian

Re: Deprecating API signatures referring to Guava in 1.10

[Angela Schreiber]

Hi Julian

Maybe you could elaborate a bit more about the reasoning of backporting the 
deprecated API signatures using Guava 1.10? The reason for the deprecation was 
the fact that we want to make breaking changes, right? And this is the kind of 
change I would feel quite uncomfortable with when it comes to back port... when 
it's just about the deprecation, I am not sure I understand the bigger benefit 
of the back port... or do I misunderstand the overall goal behind this?

Kind regards
Angela

From: Julian Reschke 
Sent: Thursday, December 5, 2019 1:30 PM
To: oak-dev@jackrabbit.apache.org 
Subject: Deprecating API signatures referring to Guava in 1.10

Hi there,

see .

In trunk, we now have deprecated all API signatures that used Guava
objects. I'd like to gradually backport these changes to 1.10, but this
will be tricky due to the semantic versioning of the APIs.

For instance, changes in oak-commons will require backporting all
interim changes that went into trunk since we branched 1.10. The first
one would be OAK-8018.

This is not high priority, but then, if we want to make a breaking
change in trunk, we should actually have deprecations and replacements
in place in 1.10.

I'll post "Intent to backport" messages for the individual changes as I
get to them.

Feedback appreciated,

Julian

Re: Build failed in Jenkins: Jackrabbit-Oak-Windows #1270

[Angela Schreiber]

hi julian

the jackrabbit-oak-windows build keeps failing for quite some time now. i don't 
think it is related to my changes that are limited to oak-auth-external. in 
particular since error seem to indicate some issue with the azure dependency, 
which afaik is not relevant for the external auth (and nor should the latter be 
relevant for the azure-blob-store:

> Failed to transfer Could not find metadata 
> org.apache.jackrabbit:oak-parent:1.20-SNAPSHOT/maven-metadata.xml in 
> apache-snapshots (http://repository.apache.org/snapshots/)
> ERROR: Failed to parse POMs
> hudson.remoting.ProxyException: 
> hudson.maven.MavenModuleSetBuild$MavenExecutionException: 
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-storage:jar is missing. @ 
> org.apache.jackrabbit:oak-blob-cloud-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-blob-cloud-azure\pom.xml,
>  line 121, column 21
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-keyvault-core:jar is missing. @ 
> org.apache.jackrabbit:oak-blob-cloud-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-blob-cloud-azure\pom.xml,
>  line 125, column 21
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-storage:jar is missing. @ 
> org.apache.jackrabbit:oak-segment-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-segment-azure\pom.xml,
>  line 143, column 21
[...]

wdyt?
angela


From: Julian Reschke 
Sent: Tuesday, November 5, 2019 10:56 AM
To: oak-dev@jackrabbit.apache.org 
Subject: Re: Build failed in Jenkins: Jackrabbit-Oak-Windows #1270

On 05.11.2019 10:10, Apache Jenkins Server wrote:
> See 
> 
>
> Changes:
>
> [angela] OAK-8725 : Improve tests for oak-external-auth (wip)
>
> [angela] OAK-8739 : Simplify ExternalLoginModule
>
>
> --
> Started by an SCM change
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on jenkins-win-he-de-5 (Windows) in workspace 
> 
> Cleaning up 
> Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision 
> '2019-11-05T01:10:08.908 -0800'
> U oak-auth-external\src\test\resources\logback-test.xml
> U 
> oak-auth-external\src\main\java\org\apache\jackrabbit\oak\spi\security\authentication\external\impl\ExternalLoginModule.java
> At revision 1869389
>
> Parsing POMs
> Failed to transfer Could not find metadata 
> org.apache.jackrabbit:oak-parent:1.20-SNAPSHOT/maven-metadata.xml in 
> apache-snapshots (http://repository.apache.org/snapshots/)
> ERROR: Failed to parse POMs
> hudson.remoting.ProxyException: 
> hudson.maven.MavenModuleSetBuild$MavenExecutionException: 
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-storage:jar is missing. @ 
> org.apache.jackrabbit:oak-blob-cloud-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-blob-cloud-azure\pom.xml,
>  line 121, column 21
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-keyvault-core:jar is missing. @ 
> org.apache.jackrabbit:oak-blob-cloud-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-blob-cloud-azure\pom.xml,
>  line 125, column 21
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-storage:jar is missing. @ 
> org.apache.jackrabbit:oak-segment-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-segment-azure\pom.xml,
>  line 143, column 21
> [ERROR] 'dependencies.dependency.version' for 
> com.microsoft.azure:azure-keyvault-core:jar is missing. @ 
> org.apache.jackrabbit:oak-segment-azure:[unknown-version], 
> F:\jenkins\jenkins-slave\workspace\Jackrabbit-Oak-Windows\oak-segment-azure\pom.xml,
>  line 147, column 21
>
>at 
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1390)
>at 
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1126)
>at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3052)
>at hudson.remoting.UserRequest.perform(UserRequest.java:212)
>at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>at hudson.remoting.Request$2.run(Request.java:369)
>at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>at 

Re: Versioning and restoring

[Angela Schreiber]

Hi Richard

Version with Oak should work according to the specification which you find at 
https://docs.adobe.com/docs/en/spec/jcr/2.0/15_Versioning.html

This includes all the details regarding OPV behavior upon restore. However, I 
quickly checked the implementation in oak-jcr and restore by label is indeed 
not supported today. I am sure Marcel Reutegger, who is the author of the 
version mgt in Oak can provider more insight on this.

Hope that helps
Angela

From: Richard Groote 
Sent: Tuesday, June 25, 2019 3:02 PM
To: oak-dev@jackrabbit.apache.org
Subject: Versioning and restoring

Hello,

Currently we’re trying to integrate Apache OAK within our project.
We using a hierarchy of nodes and a node can have different kind of properties 
(that’s why we’re using node type nt:unstructured)

Some simple example structure:

  *   Music (nt:unstructured, no actual properties)
 *   Rock (nt:unstructured, no actual properties)
*   Metallica (nt:unstructured, with a lot of properties, including 
binaries)
*   U2 (nt:unstructured, with a lot of properties, including binaries)



Some scenario’s

  *   Editing the node U2 and adding / updating some properties (should result 
in a new version)
  *   Move the node U2 to a different hierarchy (Should be able restore it)
  *   Remove some of the node
  *   Versioning the complete music tree with my own label (used 
versionhistory.addVersionLabel())
  *   Restore a complete or part of the tree
  *   Restore a node to a specific version

Now I’ve some questions about versioning and restoring:

  *   Is the nt:unstructured the best node type or should I use another one for 
instance nt:folder, nt:file (may be create my own)
  *   Nt:unstructured used OPV version. When I use 
versionhistory.getVersionByLabel() than the child information contains 
‘jcr:childVersionHistory’. This child information points to a node. But in my 
case this node is no longer retrieval because it has been deleted. Is in this 
case better to use a node type with OPV Copy
  *   Restore by label is currently not implemented by OAK. Does anyone know 
about some example of restoring (part of) tree based on a label.

Thanx, for all information. May be I missed some documentation

Richard

Re: ldap user permission

[Angela Schreiber]

Hi Jorge

If you are not using OSGi, you have to make sure you setup the Oak repository 
with a SecurityProvider that is configured such that the 
{{DefaultAuthorizableActionProvider}} comes with the corresponding actions 
setup the way you need it.

That should be doable... at least it works for the our tests, which mostly use 
non-OSGi based setup.
org.apache.jackrabbit.oak.security.internal.SecurityProviderBuilder might turn 
out to be useful.

Hope that helps
Angela

From: jorgeeflorez . 
Sent: Wednesday, June 5, 2019 2:19 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: ldap user permission

Hi Angela,
thank you for your reply.
I think it is awesome all the things you guys made with Oak.

Unfortunately we are not using OSGi. Anyway, I will make it work as you say
and see what happens.

Thanks again.

Jorge

El lun., 3 jun. 2019 a las 1:24, Angela Schreiber
() escribió:

> hi jorge
>
> that should be easy to do by configuring your system to trigger the
> 'AccessControlAction' upon user/group creation. this action is part of the
> default action provider implementation and you can configure the desired
> privileges granted for users and group, respectively.
>
> in the OSGi console the provider is labeled "Apache Jackrabbit Oak
> AuthorizableActionProvider" and the corresponding configuration option
> "Configure AccessControlAction: User Privileges".
>
> the documentation for the actions is located at
> http://jackrabbit.apache.org/oak/docs/security/user/authorizableaction.html
>
> there should be tests available in oak-core that illustrate the behavior
> if you wanted to see it in action.
>
> hope that helps
> angela
>
> 
> From: jorgeeflorez . 
> Sent: Friday, May 31, 2019 2:34 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: ldap user permission
>
> Hello,
>
> I am currently implementing user login using a ldap server. So far so good.
> I am able enter to the repositories and when the user that is logging in
> doesn't exist in the repository, it is automatically created.
>
> I am seeing that the created users have no privileges (which makes sense).
> Unfortunately, I am using a property from the authorizable to get the
> modules the user can see in the application. And when a new user logs in,
> he is not able to get its own authorizable and I cannot read the property.
> Is there an "easy" way to assign, to the user that is created
> automatically, jcr:read to it's own authorizable's path?
>
> If there is not I think I will go with the alternative. Just check if he
> has the permission, if not, grant it before getting its own authorizable...
>
> Thanks.
>
> Jorge Eduardo Flórez
>

Re: ldap user permission

[Angela Schreiber]

hi jorge

that should be easy to do by configuring your system to trigger the 
'AccessControlAction' upon user/group creation. this action is part of the 
default action provider implementation and you can configure the desired 
privileges granted for users and group, respectively.

in the OSGi console the provider is labeled "Apache Jackrabbit Oak 
AuthorizableActionProvider" and the corresponding configuration option 
"Configure AccessControlAction: User Privileges".

the documentation for the actions is located at 
http://jackrabbit.apache.org/oak/docs/security/user/authorizableaction.html

there should be tests available in oak-core that illustrate the behavior if you 
wanted to see it in action.

hope that helps
angela


From: jorgeeflorez . 
Sent: Friday, May 31, 2019 2:34 PM
To: oak-dev@jackrabbit.apache.org
Subject: ldap user permission

Hello,

I am currently implementing user login using a ldap server. So far so good.
I am able enter to the repositories and when the user that is logging in
doesn't exist in the repository, it is automatically created.

I am seeing that the created users have no privileges (which makes sense).
Unfortunately, I am using a property from the authorizable to get the
modules the user can see in the application. And when a new user logs in,
he is not able to get its own authorizable and I cannot read the property.
Is there an "easy" way to assign, to the user that is created
automatically, jcr:read to it's own authorizable's path?

If there is not I think I will go with the alternative. Just check if he
has the permission, if not, grant it before getting its own authorizable...

Thanks.

Jorge Eduardo Flórez

Re: Users, groups and permissions

[Angela Schreiber]

Hi Jorge

If you are not using the default setup, the general notes should still apply... 
that is:
What goes into the Subject upon authentication (or comes with the Subject in 
case of pre-authenticated login) is used for the permission evaluation. So, in 
other words: the relevant piece is the set of principals that is passed to the 
PermissionProvider and how the configured permission provider(s) (default 
implemenation or custom, single provider or composition of many) evaluate the 
effective permissions for these principals.

If you are interested in the inner workings of Oak, you may start your 
investigation at MutableRoot line 127. There you can see how the 
PermissionProvider is constructed based on the principal set associated with 
the Subject, which in turn has been passed to the Root object upon construction 
in ContentSessionImpl line 105.

How permissions are evaluation in a custom security setup obviously depends 
both on the authentication setup and how the set of principals is computed 
therein and the authorization mechanism i.e. how permissions for these 
principals are collected/weighted/ordered/evaluated.

Hope that helps
Angela


From: jorgeeflorez . 
Sent: Friday, May 24, 2019 2:25 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: Users, groups and permissions

Hello Angela,

thank you for taking your time and writing this awesome reply. You saved my
life :)
It is clear to me now how it works by default. It seems that we are not
using the default security setup for Oak. I will have to look into it.

Best regards.

Jorge Flórez

El vie., 24 may. 2019 a las 2:03, Angela Schreiber
() escribió:

> Hi Jorge
>
> The https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html
> are not directly related to permission evaluation. This is just an optional
> add on to perform specific verification or action upon modification of the
> set of members of a given group e.g. write a log message.
>
> When it comes to permissions it all boils down to the set of principals
> contained in the Subject after the Repository login and whether that set of
> principals is granted permission to perform a given read/write action.
>
> So, for simplicity let's look at the default setup as present with Oak out
> of the box:
> - the default authentication will
>   > verify the passed Credentials object,
>   > lookup the user associated with the Credentials and get it's principal
>   > resolve the declared and inherited group membership for that user and
> get the group principals
>   > update the subject with the complete set of principals both for the
> user and it's groups
> - the default authorization will
>   > look at the permission entries for the set of principals and the
> target path and all it's ancestors
>   > verify if a given action is granted (or denied) for any of the user
> principals or any of the group principals
>   > if it is neither granted or explicitly denied, permission is not
> granted
>   see https://jackrabbit.apache.org/oak/docs/security/permission.html and
>
> https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
> for details and examples.
>
> So, back to your initial question:
> If you take the default security setup of Oak, assign permissions to a
> group principal  at /test/path and assign your user to that group will
> result in your user inheriting the permissions of the group. if you remove
> the user from the group again, the subject upon login will no longer be
> populated with the group principal and therefore the user no longer
> inherits the permissions granted/denied to that group.
> similarly, if you remove that permission entry again and persist the
> change, the test group and all of it's members will no longer get that
> permission granted/denied (assuming there is no other entry that has the
> same effect).
>
> Kind regards
> Angela
>
> 
> From: jorgeeflorez . 
> Sent: Thursday, May 23, 2019 8:03 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: Users, groups and permissions
>
> Hello,
>
> I have been reading regarding Jackrabbit and Oak security and I think I
> understand. but I would like to confirm before implementing something...
> When I create a group and assign a permission (e.g. rep:write) to that
> group over a node path.
> If I assign an user to that group then the user will have the permission
> that I gave to that group over that node?
> If I remove that user from the group the permission will be removed?
>
> From what I understand from here
> https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
> will not happen, and I will have to make it happen, am I right?
>
> Thanks.
>

Re: Users, groups and permissions

[Angela Schreiber]

Hi Jorge

The https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html are 
not directly related to permission evaluation. This is just an optional add on 
to perform specific verification or action upon modification of the set of 
members of a given group e.g. write a log message.

When it comes to permissions it all boils down to the set of principals 
contained in the Subject after the Repository login and whether that set of 
principals is granted permission to perform a given read/write action.

So, for simplicity let's look at the default setup as present with Oak out of 
the box:
- the default authentication will 
  > verify the passed Credentials object, 
  > lookup the user associated with the Credentials and get it's principal
  > resolve the declared and inherited group membership for that user and get 
the group principals
  > update the subject with the complete set of principals both for the user 
and it's groups
- the default authorization will
  > look at the permission entries for the set of principals and the target 
path and all it's ancestors
  > verify if a given action is granted (or denied) for any of the user 
principals or any of the group principals
  > if it is neither granted or explicitly denied, permission is not granted
  see https://jackrabbit.apache.org/oak/docs/security/permission.html and 
  https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html 
for details and examples.

So, back to your initial question:
If you take the default security setup of Oak, assign permissions to a group 
principal  at /test/path and assign your user to that group will result in your 
user inheriting the permissions of the group. if you remove the user from the 
group again, the subject upon login will no longer be populated with the group 
principal and therefore the user no longer inherits the permissions 
granted/denied to that group.
similarly, if you remove that permission entry again and persist the change, 
the test group and all of it's members will no longer get that permission 
granted/denied (assuming there is no other entry that has the same effect).

Kind regards
Angela


From: jorgeeflorez . 
Sent: Thursday, May 23, 2019 8:03 PM
To: oak-dev@jackrabbit.apache.org
Subject: Users, groups and permissions

Hello,

I have been reading regarding Jackrabbit and Oak security and I think I
understand. but I would like to confirm before implementing something...
When I create a group and assign a permission (e.g. rep:write) to that
group over a node path.
If I assign an user to that group then the user will have the permission
that I gave to that group over that node?
If I remove that user from the group the permission will be removed?

>From what I understand from here
https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
will not happen, and I will have to make it happen, am I right?

Thanks.

Re: Queries for migrating to jackrabbti oak from jackrabbti 2.18

[Angela Schreiber]

Hi Tuhin

Answers inline below

> 5. Does OAK provide multiple workspaces in one repository ?

No, workspace management is currently not supported in Oak [0].

> I have couple of queries on this migration :
>
> 1. *Oak does not index as much content by default as does Jackrabbit 2.
> Custom indexes need to be created when necessary, much like in traditional
> RDBMSs. If there is no index for a specific query then the repository will
> be traversed. The query will still work but probably will be very slow. *
> *---> How do I address this?*

see http://jackrabbit.apache.org/oak/docs/query/query-troubleshooting.html

> *2. **Sessions in JR always reflects the latest state of the repository,
> whereas sessions in Oak reflects the state of the repository at the time of
> session acquisition.*
> ---> *How do we address this issue ? I mean let's say I have a
> requirement where I have to get latest state from session.*

Session.refresh is what you are looking for.

> 3. *I have to tag some document / artifacts is it possible in OAK ?*

That's for sure possible... likely the same way as you did it in Jackrabbit 
2.x. The node types defined by JSR 283 are still available. In addition Oak 
comes with some improved variants like oak:Resource and oak:Unstructured. The 
details on how to do this depend mainly on the nature of the node types of your 
documents. Lacking insight on your existing/envisioned content structure, I 
would suggest to create a mixin type that you attach to the documents and then 
collect the tags therein. This would make it easier later on to identify these 
nodes/properties as additional tagging information associated with the doc.

> 4. *Security: Does OAK has out of the box token based authentication &
> authorization ?*

Oak has token based authentication very similar to the one present in 
Jackrabbit 2.x [1]. The default authorization has a few differences compared to 
Jackrabbit 2.x [2] but was built to be compatible whenever possible. 

Hope that helps
Angela

[0[ http://jackrabbit.apache.org/oak/docs/differences.html
[1] 
http://jackrabbit.apache.org/oak/docs/security/authentication/tokenmanagement.html
[2] http://jackrabbit.apache.org/oak/docs/security/permission/differences.html

Re: updating pom.xml to latest jackrabbit version

[Angela Schreiber]

hi davide

thanks for the answer. would you mind updating the documentation accordingly? 
regarding backport: we don't backport new features. will need a new stable for 
1.14.

kind regards
angela

From: Davide Giannella 
Sent: Friday, May 3, 2019 1:11 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: updating pom.xml to latest jackrabbit version

On 03/05/2019 10:35, Angela Schreiber wrote:
> hi oak-devs
>
> for my recent work on OAK-8190 i would need the latest jackrabbit-api 
> including the extension added with JCR-4429. looking that summary written by 
> Davide recently (http://markmail.org/message/bndcm5jwfasj4otm) and on the oak 
> documentation i couldn't find if we are still fine to temporarily have a 
> snapshot dependency to jackrabbit during development. i vaguely remember that 
> we discussed this topic but don't recall the final conclusion/decision.
>
> i already create a task reminding us that we need to update the jackrabbit 
> version in the parent pom (https://issues.apache.org/jira/browse/OAK-8295) 
> before cutting 1.14.0 but obviously that's a bit late for the ongoing 
> development.
>

No SNAPSHOT please. Release an unstable JR and include such version oak
trunk. We will then decide whether release a new stable or backport. The
non-snapshot will ease the integration for downstream projects.

Davide

PS: yes we should discuss what we're going to do with JR but in short I
think it makes sense for now to adopt the same model we're using for Oak.

updating pom.xml to latest jackrabbit version

[Angela Schreiber]

hi oak-devs

for my recent work on OAK-8190 i would need the latest jackrabbit-api including 
the extension added with JCR-4429. looking that summary written by Davide 
recently (http://markmail.org/message/bndcm5jwfasj4otm) and on the oak 
documentation i couldn't find if we are still fine to temporarily have a 
snapshot dependency to jackrabbit during development. i vaguely remember that 
we discussed this topic but don't recall the final conclusion/decision.

i already create a task reminding us that we need to update the jackrabbit 
version in the parent pom (https://issues.apache.org/jira/browse/OAK-8295) 
before cutting 1.14.0 but obviously that's a bit late for the ongoing 
development.

kind regards
angela

Re: Retrieving permissions for user

[Angela Schreiber]

Hi Jorge

The code you are describing relies on an implementation detail and you are 
right that it only works for administrative sessions. The reason for this is 
that using a different user to read from the permission store would essentially 
leak information that may not be accessible to that session.

Also you have to keep in mind that this code only read information for one 
particular authorization model. If you Oak repository would for instance use 
more than one model, you would miss the effect the other would have.

What you are probably looking for is

AccessControlPolicy[] getEffectivePolicies(Set principals)

this one would show the effective policies for a given set of principal taking 
the access rights of the editing session into account. so, if a given Session 
would not be allowed to read the access control setup at a given node or for a 
given principal, this information will not leak. 

Hope that helps
Angela




From: jorgeeflorez 
Sent: Thursday, April 25, 2019 4:39 PM
To: oak-dev@jackrabbit.apache.org
Subject: Retrieving permissions for user

Hello all,

I am giving maintenance to an application that uses Jackrabbit and Oak
(1.5.14). In that software someone wrote the following code to get all
permissions given to an user:

List authPaths = new ArrayList<>();
permissionParent = "/jcr:system/rep:permissionStore/default/" +
principalName;

Node parent = session.getNode(permissionParent);

NodeIterator iter = parent.getNodes();
String path;

while (iter.hasNext()) {
Node current = iter.nextNode();

Property prop = current.getProperty("rep:accessControlledPath");

authPaths.add(prop.getString() );
}

this way in the user interface all paths are shown and when one is
selected, the privileges assigned can be shown.

The problem with this code, is that only works when it is executed by the
"admin" user (if I understood well, it is because the restricted access of
"/jcr:system/rep:permissionStore" as explained here
).
I need to display all paths with privileges assigned to an user, and I
think this is not possible using the methods described here
,
because they receive a path as argument (maybe I am wrong). Is there a way
to achieve this (and that works for admin and all users with proper
permissions)?

Thanks in advance.
Best Regards.

Jorge Eduardo Flórez

OAK-8190 : initial commit....

[Angela Schreiber]

hi oak-dev

i am planning to push a initial version of the authorization model for OAK-8190 
[0] later today or early next week. while it is still work in progress and some 
pieces (notably benchmarks and documentation) are still missing, i feel that it 
is stable enough to be committed now. the commit doesn't affect any existing 
modules as all blocking issues have been resolved separately.
while the original driver for that issue was to be able to mount system users 
and their permissions in a separate read-only mount, the approach chosen allows 
to adjust the model for any type of principals with very limited effort... in 
detail documentation on the design, inner working, configuration options and 
limitations will be available with the regular oak security documentation later 
on.

kind regards
angela

[0] https://issues.apache.org/jira/browse/OAK-8190

Re: how to change password for a new system user?

[Angela Schreiber]

hi 

system users are created without a password and the oak implementation doesn't 
allow them to have a password at all. see constraintviolation error codes 0032 
and 0033 in 
http://jackrabbit.apache.org/oak/docs/security/user/default.html#validation 

kind regards
angela

From: 周旭 
Sent: Thursday, March 21, 2019 11:12 AM
To: oak-dev
Subject: how to change password for a new system user?

hello expert!

 i create a system user  named dmadmin succefully,but i donot know how to 
set user password.the code like these:

JackrabbitSession jackrabbitSession = (JackrabbitSession) jcrSession;
UserManager userManager = jackrabbitSession.getUserManager();
User user = userManager.createSystemUser("dmadmin", null);
user.setProperty("description", new StringValue("这是一个超级用户"));
user.setProperty("role", new StringValue("super_user"));
   jackrabbitSession.save();







--
周旭
上海市黄浦区北京东路668号科技京城西楼24层B1
邮编：22
手机：86-21-13472548356电话：86-21-5296 5638
传真：86-21-5296 5638
邮箱：zho...@docworks.cn

backporting OAK-8023

[Angela Schreiber]

hi oak-dev

i would like to backport https://issues.apache.org/jira/browse/OAK-8023 to the 
1.10 branch. unless someone objects, i merge the fix tomorrow as i consider the 
overall risk to be small.

kind regards
angela

Re: oak-http html generator title issue

[Angela Schreiber]

Hi Ruben


Can you create a JIRA ticket at 
https://issues.apache.org/jira/projects/OAK/issues and attach the patch there?

Thanks
Angela


From: Ruben Reusser 
Sent: Monday, February 4, 2019 5:54 PM
To: oak-dev@jackrabbit.apache.org
Subject: oak-http html generator title issue

hi there

there seems to be an issue with oak-http when rendering html. The title
tag is closed without rendering a title. This is due to a depricated
constant in the HTMLRepresentation. Please find attached a patch for
oak-http

Ruben

Re: Request for info on Oak restriction management for JCR-SQL2 queries

[Angela Schreiber]

Hi Søren


Thanks. I will look into it and follow up on the jira issue.


Kind regards

Angela




From: Søren Jensen 
Sent: Monday, January 21, 2019 2:59 PM
To: us...@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: RE: Request for info on Oak restriction management for JCR-SQL2 queries

Hi Angela

Thank you for the response. I've created an issue at 
https://issues.apache.org/jira/browse/OAK-7997 with the test code included.


-Original Message-
From: Angela Schreiber 
Sent: 21. januar 2019 13:25
To: us...@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: Re: Request for info on Oak restriction management for JCR-SQL2 queries

Hi Søren


I would expect the query results to reflect the effective permissions i.e. the 
result set should only return what is accessible to the editing session and the 
results should be consistent with calls to Session.getNode/getProperty/getItem.


Without having a closer look at the code base or your test the described 
behavior looks look a bug to me... but I have to add that I am not too familiar 
with the Oak query engine and how it evaluates permissions. May I ask you to 
create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with 
the description below and the test-code?


If it wasn't a bug but a conscious decision / known limitation of the query, I 
would at least want to update the security documentation to make sure we 
mention (and have an explanation for) the behavior, that looks inconsistent.


Kind regards

Angela







From: Søren Jensen 
Sent: Monday, January 21, 2019 8:54 AM
To: us...@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries

Hi

This is a shortened version of 
https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak

I'm looking for information on Jackrabbit Oak's restriction management w.r.t. 
security. This primarily stems from a specific case below where I receive some 
unexpected results, as I did not expect a query to filter away the results it 
did.

Using the following repository structure below:

/
  node[nt:unstructured]
subnode   [nt:unstructured]

On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' 
(with principal 'user') together with a restriction for rep:glob -> "", such 
that user do not have access to the children - in this case, only 'subnode'.

It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due 
to the restriction.

However, when I execute the following JCR-SQL2 query as 'user':
  SELECT * FROM [nt:unstructured]

I get no results back. Here I would have expected to get /node, as it is 
otherwise available when using session.getNode. Removing the restriction yields 
the expected result of both /node and /node/subnode.

I'm using Oak version 1.10.0.

If anybody is able to provide some insight into why this is not the case, it 
would be greatly appreciated. With that said, I really appreciate the thorough 
documentation on your website.

Thanks in advance,
Søren

Re: Request for info on Oak restriction management for JCR-SQL2 queries

[Angela Schreiber]

Hi Søren


I would expect the query results to reflect the effective permissions i.e. the 
result set should only return what is accessible to the editing session and the 
results should be consistent with calls to Session.getNode/getProperty/getItem.


Without having a closer look at the code base or your test the described 
behavior looks look a bug to me... but I have to add that I am not too familiar 
with the Oak query engine and how it evaluates permissions. May I ask you to 
create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with 
the description below and the test-code?


If it wasn't a bug but a conscious decision / known limitation of the query, I 
would at least want to update the security documentation to make sure we 
mention (and have an explanation for) the behavior, that looks inconsistent.


Kind regards

Angela







From: Søren Jensen 
Sent: Monday, January 21, 2019 8:54 AM
To: us...@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries

Hi

This is a shortened version of 
https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak

I'm looking for information on Jackrabbit Oak's restriction management w.r.t. 
security. This primarily stems from a specific case below where I receive some 
unexpected results, as I did not expect a query to filter away the results it 
did.

Using the following repository structure below:

/
  node[nt:unstructured]
subnode   [nt:unstructured]

On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' 
(with principal 'user') together with a restriction for rep:glob -> "", such 
that user do not have access to the children - in this case, only 'subnode'.

It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due 
to the restriction.

However, when I execute the following JCR-SQL2 query as 'user':
  SELECT * FROM [nt:unstructured]

I get no results back. Here I would have expected to get /node, as it is 
otherwise available when using session.getNode. Removing the restriction yields 
the expected result of both /node and /node/subnode.

I'm using Oak version 1.10.0.

If anybody is able to provide some insight into why this is not the case, it 
would be greatly appreciated. With that said, I really appreciate the thorough 
documentation on your website.

Thanks in advance,
Søren

Re: OAK-7511 (nullability annotations) vs Oak 1.8.*

[Angela Schreiber]

Hi Alex

I don't want to single out OAK-7741 and I know that there are sometimes 
compelling reasons to backport even improvements. Just want to avoid future 
troubles as I experienced it it in the external authentication code base with 
backports of improvements (one time even ending up with totally different 
'states' having the same exported version).

Kind regards
Angela


From: Alex Deparvu 
Sent: Friday, November 2, 2018 4:36 PM
To: Oak devs
Subject: Re: OAK-7511 (nullability annotations) vs Oak 1.8.*

Hi,

I think it's easy to single out OAK-7741 as the source of the issues, when
in fact the question is really about all the classes affected by the
OAK-7511 change.
As it stands now, none of them are backportable to 1.8 due to the exact
same issues as OAK-7741: the annotation change will trigger a minor bump in
the export version making the 2 branches diverge (if applied over other
backports that touched the export version).

I think the decision is if we will _never backport_, in which case all is
well because the above case will never happen. or _probably backport_ in
which case it's a good time as any to begin.

This was in fact an happy occurrence where I could rollback my backport and
skip this release, and I'm happy it provided the opportunity to give the
OAK-7511 backport some more air time.

best,
alex



On Fri, Nov 2, 2018 at 2:35 PM Angela Schreiber 
wrote:

> Hi Julian
>
> On a general note Variant 2) looks better to me.
> However, looking at OAK-7741 I am not all convinced that this one should
> have been backported in the first place, because as far as I remember we
> once decided that we don't backport improvements, didn't we? Specially if
> the improvement affects public API. But if we really had to backport this
> one for a compelling reason, wouldn't it be possible to refactor the
> backport such that it doesn't affect the public API (if i am not mistaken
> it was just a new constant added, right)?
>
> Kind regards
> Angela
> 
> From: Julian Reschke 
> Sent: Friday, November 2, 2018 2:11 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: OAK-7511 (nullability annotations) vs Oak 1.8.*
>
> Hi there,
>
> so we made the switch to the Jetbrains annotations in trunk some time
> ago (July).
>
> Doing so required a micro version update, because the annotations are
> considered part of the API.
>
> We now have an issue with the backport for OAK-7741 in 1.8, which would
> *also* change the version number of an exported package, but the API
> would be not identical to the one in trunk with the same version number.
>
> We discussed this off-list yesterday, and decided to back out the change
> in 1.8 for now (to unblock a release).
>
> Going forward, we need to decide how to proceed. The options seem to be:
>
> 1) Review the issue and decide that the version conflict is harmless
> (and document how we got to that conclusion). This may indeed work, as
> the conflict is with 1.9.* releases, for which we do not really give
> stability guarantees.
>
> 2) Backport the changes for OAK-7511 to OAK 1.8 (which was so far on
> hold because it was not clear whether we need it); then re-apply the
> change.
>
> Feedback appreciated,
>
> Julian
>
> PS: and yes, I volunteer to do the backport of OAK-7511.
>

Re: ACL on versioned node

[Angela Schreiber]

Hi Marco

Regarding your original question I found, that I was actually mistaken :-) See 
OAK-6015 for the reason why IGNORED nodes are treated differently.

Not sure thought I understand your followup question... you don't need to make 
a node versionable or version it in order to place/edit access control 
information on it. But the fact that ac-content is marked with OPV IGNORE is an 
implementation detail. See also 
http://jackrabbit.apache.org/oak/docs/security/permission/differences.html for 
details on how access to the version storage is evaluated.

Kind regards
Angela

From: Marco Piovesana 
Sent: Friday, November 2, 2018 3:23 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: ACL on versioned node

Hi Angela,
thanks for the clarification, I thought the access control content was
versioned alongside the node. If you don't mind me asking I have another
question though (that might be a little off topic): why is required to
version a node to change its access control information if the access
control information is not part of the version information? If I restore a
node to a previous version (that had different permission settings), the
permission on the node are not restored alongside the node state, so why do
I have to version it in the first place? Am I missing something?

Marco.

On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber 
wrote:

> Hi Marco
>
> As far as I remember the access control content is not versioned along
> with the parent node it is attached to in the default implementation. This
> is indeed due to the OPV flag set to IGNORE with the corresponding node
> type definitions. However that cannot be changed and it is somewhat
> unrelated to the issue you are seeing (i.e. the read only status of a
> checked-in node). The OPV defines what happens to an item in the subtree of
> a versionable node upon checkin i.e. the creation of a new version and
> which imformation also makes it in which form to the version storage
> (IGNORE: not copied to version storage at all). It also has an impact on
> restore. You will find all the details in the specification.
>
> Kind regards
> Angela
> 
> From: Marco Piovesana 
> Sent: Wednesday, October 31, 2018 9:53 AM
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: ACL on versioned node
>
> Sure,
> I'll add a JIRA for it with the test case. One more question, if I want to
> separate the versioning of the node from the permission policy on it, can I
> set the OPV to ignore for the relative rep:policy node? Or that just
> doesn't work?
>
> Marco
>
> On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber  >
> wrote:
>
> > Hi Marco
> >
> > Upon checkin of a versionable node (and it's non-versionable subtree)
> > becomes read-only. I think the first behavior is a bug.  Changing
> > permissions of a checked-in node should not be possible. The reason why
> you
> > are seeing it in the second case is due to the fact that a mixin is
> > automatically added to the checked-in node. But also the modification of
> > access control content in the subtree should trigger the exception (which
> > it doesn't apparently)
> >
> > Here a quote from the specification:
> > The node N and its connected non-versionable subtree become read-only.
> N's
> > connected non-versionable subtree is the set of non-versionable
> descendant
> > nodes reachable from N through child links without encountering any
> > versionable nodes. In other words, the read-only status flows down from
> the
> > checked-in node along every child link until either a versionable node is
> > encountered or an item with no children is encountered.
> >
> > Since the policy node and the access controlled content stored therein is
> > not versionable the checkin status of it's versionable parent (or
> ancestor
> > for that matter) should be enforced.
> >
> > May I ask you to create a JIRA ticket for that?
> > Thanks
> > Angela
> >
> > 
> > From: Marco Piovesana 
> > Sent: Tuesday, October 30, 2018 7:05 PM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: ACL on versioned node
> >
> > Hi all,
> > I'm using Oak 1.8.1 and I don't think I fully understand how permissions
> > are handled in versioned nodes.
> >
> > If I create the first version of a node *after* adding an ACE to it,
> then I
> > can add or remove other ACE without having to checkout the node.
> >
> > If I create the first version of the node *before* adding the first ACE,
> > then I get the error (*OakVersion0001: Cannot change property
> > jcr:mixinTypes on checked in node*) whenever i try to modify the node
> > permissions without checking it out first.
> >
> > what is the expected behavior? Checkout should be required or not to
> modify
> > the user's permission on the node?
> >
> > Marco.
>

Re: ACL on versioned node

[Angela Schreiber]

Hi Marco

As far as I remember the access control content is not versioned along with the 
parent node it is attached to in the default implementation. This is indeed due 
to the OPV flag set to IGNORE with the corresponding node type definitions. 
However that cannot be changed and it is somewhat unrelated to the issue you 
are seeing (i.e. the read only status of a checked-in node). The OPV defines 
what happens to an item in the subtree of a versionable node upon checkin i.e. 
the creation of a new version and which imformation also makes it in which form 
to the version storage (IGNORE: not copied to version storage at all). It also 
has an impact on restore. You will find all the details in the specification.

Kind regards
Angela

From: Marco Piovesana 
Sent: Wednesday, October 31, 2018 9:53 AM
To: oak-dev@jackrabbit.apache.org
Subject: Re: ACL on versioned node

Sure,
I'll add a JIRA for it with the test case. One more question, if I want to
separate the versioning of the node from the permission policy on it, can I
set the OPV to ignore for the relative rep:policy node? Or that just
doesn't work?

Marco

On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber 
wrote:

> Hi Marco
>
> Upon checkin of a versionable node (and it's non-versionable subtree)
> becomes read-only. I think the first behavior is a bug.  Changing
> permissions of a checked-in node should not be possible. The reason why you
> are seeing it in the second case is due to the fact that a mixin is
> automatically added to the checked-in node. But also the modification of
> access control content in the subtree should trigger the exception (which
> it doesn't apparently)
>
> Here a quote from the specification:
> The node N and its connected non-versionable subtree become read-only. N's
> connected non-versionable subtree is the set of non-versionable descendant
> nodes reachable from N through child links without encountering any
> versionable nodes. In other words, the read-only status flows down from the
> checked-in node along every child link until either a versionable node is
> encountered or an item with no children is encountered.
>
> Since the policy node and the access controlled content stored therein is
> not versionable the checkin status of it's versionable parent (or ancestor
> for that matter) should be enforced.
>
> May I ask you to create a JIRA ticket for that?
> Thanks
> Angela
>
> 
> From: Marco Piovesana 
> Sent: Tuesday, October 30, 2018 7:05 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: ACL on versioned node
>
> Hi all,
> I'm using Oak 1.8.1 and I don't think I fully understand how permissions
> are handled in versioned nodes.
>
> If I create the first version of a node *after* adding an ACE to it, then I
> can add or remove other ACE without having to checkout the node.
>
> If I create the first version of the node *before* adding the first ACE,
> then I get the error (*OakVersion0001: Cannot change property
> jcr:mixinTypes on checked in node*) whenever i try to modify the node
> permissions without checking it out first.
>
> what is the expected behavior? Checkout should be required or not to modify
> the user's permission on the node?
>
> Marco.

Re: ACL on versioned node

[Angela Schreiber]

Hi Marco

Upon checkin of a versionable node (and it's non-versionable subtree) becomes 
read-only. I think the first behavior is a bug.  Changing permissions of a 
checked-in node should not be possible. The reason why you are seeing it in the 
second case is due to the fact that a mixin is automatically added to the 
checked-in node. But also the modification of access control content in the 
subtree should trigger the exception (which it doesn't apparently)

Here a quote from the specification:
The node N and its connected non-versionable subtree become read-only. N's 
connected non-versionable subtree is the set of non-versionable descendant 
nodes reachable from N through child links without encountering any versionable 
nodes. In other words, the read-only status flows down from the checked-in node 
along every child link until either a versionable node is encountered or an 
item with no children is encountered.

Since the policy node and the access controlled content stored therein is not 
versionable the checkin status of it's versionable parent (or ancestor for that 
matter) should be enforced.

May I ask you to create a JIRA ticket for that? 
Thanks
Angela 


From: Marco Piovesana 
Sent: Tuesday, October 30, 2018 7:05 PM
To: oak-dev@jackrabbit.apache.org
Subject: ACL on versioned node

Hi all,
I'm using Oak 1.8.1 and I don't think I fully understand how permissions
are handled in versioned nodes.

If I create the first version of a node *after* adding an ACE to it, then I
can add or remove other ACE without having to checkout the node.

If I create the first version of the node *before* adding the first ACE,
then I get the error (*OakVersion0001: Cannot change property
jcr:mixinTypes on checked in node*) whenever i try to modify the node
permissions without checking it out first.

what is the expected behavior? Checkout should be required or not to modify
the user's permission on the node?

Marco.