Hi, > This defeats the original intent of the > separation of NodeImpl and NodeDelegate (OAK-84) > users should not be able to gain access to internals by hacking NodeImpl.
Hm, is this a security problem? Do we want to protect the data from users of the JCR API? Or do we want to protect the data within the Oak implementation (use a better abstraction)? > But precisely this > is now possible when a user put his code into the > org.apache.jackrabbit.oak.jcr package. A attacker could always use reflection (setAccessible(true)). If we want real protection, we would have to enforce using a SecurityManager. Then we could seal the package [1] [1] http://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html Regards, Thomas On 6/7/12 1:07 PM, "Michael Dürig" <[email protected]> wrote: > >Hi, > >I noticed that since revision 1344662 NodeImpl has an (package private) >accessor for NodeDelegate. This defeats the original intent of the >separation of NodeImpl and NodeDelegate (OAK-84): users should not be >able to gain access to internals by hacking NodeImpl. But precisely this >is now possible when a user put his code into the >org.apache.jackrabbit.oak.jcr package. > >Michael > >
