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 <[email protected]> Sent: Thursday, June 1, 2023 15:23 To: [email protected] <[email protected]> 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<JackrabbitAccessControlEntry>). 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 (<[email protected]>) 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 <[email protected]> > Sent: Wednesday, May 31, 2023 18:50 > To: [email protected] <[email protected]> > 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 (< > [email protected]>) > 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 > > (<[email protected]>) escribió: > > > >> Hi Jorge, > >> > >> On 16.05.23, 20:37, "Jorge Flórez" <[email protected]> > 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 > >> > > >
