jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: NodeTypeRegistry.checkForReferencesInContent()
Date Sun, 04 Feb 2007 16:42:17 GMT
hi anton,
as the nodetype registry has access to the "lowlevel' item states, it
can bypass any access control when checking the content. instead of
reassigning nt:base which would render the content invalid, i would
use a nodetype: nt:conflict (extends nt:unstructured), which could
have a property jcr:formerPrimaryType  and jcr:formerMixinTypes

regads, toby

On 2/4/07, anton_slutsky <aslutsky@applevac.com> wrote:
>
> Looks like I spoke without thinking.  SystemSession already implementes its
> own AccessManager!
>
>
> anton_slutsky wrote:
> >
> > I think the issue here is what to do with the already existing nodes
> > rather then the new node creation (like you said, a NodeTypeNotFound can
> > always be thrown).  But if there are nodes out there with the type we are
> > trying to delete, we need to make sure something is done to those orphan
> > nodes.  Personally, I wouldnt reassign them to nt:base.  I'd check for
> > nodes of the given type, and if any are found, I'd throw a
> > RepositoryException of some kind and have people deal with their data
> > before they can drop a type.  But thats just a suggestion.  You guys know
> > this stuff better then I do :)
> >
> > But either way, we'll have to traverse each and every workspace to find
> > those typed nodes.  And here we'll be running into security issues if
> > custom security/access managers are provided.  In theory, we should be
> > able to somehow get a SystemPrincipal session for each workspace and that
> > should work because SystemPrincipal should have access to everything, but
> > having recently implemented a custom security manger, I'm pretty sure
> > people who will be doing the same will forget to account for the
> > SystemPrincipal.  I guess what we could do here is decouple the
> > LoginModule the JAAS interface, provide corresponding template methods for
> > both the LoginModule and AccessManager, create internal instances of
> > javax.security.auth.spi.LoginModule and AccessManager and delegate calls
> > to templates after making sure SystemPrincipal is allowed through
> > (phhuphh!  that was a mouthfull.  hope it makes sense :-) ).  But here,
> > what we'll be doing is basically saying to all the users "nomatter what
> > you do, SystemPrincipal is getting through".  What do you think?
> >
> > Thanks,
> > Anton
> >
> >
> > Sandro Böhme wrote:
> >>
> >> Hello,
> >>
> >> I guess the deep lock is needed to avoid new creation of nodes after
> >> the search for nodes with the node type that has to be unregistered.
> >> If that's the case maybe there is a way to avoid the deep lock.
> >> If a user tries to add a node with a node type that is currently
> >> being unregistered a NodeTypeNotFoundException (or similar) could
> >> already be thrown. This way it's possible to search for all nodes with
> >> this type and change the type to nt:base while the amount of nodes
> >> with this type will not change anymore.
> >> To search for nodes by type the following query should work
> >> "//element(*, nt:nodeType)". Of course this needs to be done for
> >> every workspace.
> >> Do you think that could work?
> >>
> >> Best regards,
> >>
> >> Sandro
> >>
> >> anton_slutsky wrote:
> >>> Hm.  Doesnt look like our implementation will work.  It works for us
> >>> because
> >>> its our application specific, but I doubt it'll work for the project.
> >>> Looks
> >>> like there are a couple of issues here.  1. The deep locks solutions
> >>> wont
> >>> work because it's not always possible to get all workspaces or all root
> >>> nodes given the custom security managers.  2.  The single-user solution
> >>> would work, but once we figure out how to place the repository into a
> >>> single-user mode, we run into the same issue as in #1, i.e., how do we
> >>> inspect nodes if we are not guaranteed to be able to get to them?
> >>>
> >>> Obviously, there is a bunch of possible solutions here.  Figured I'd run
> >>> it
> >>> by you, see what you all think.
> >>>
> >>> 1. Add a concept of a system superuser.  Will work, but kind of ugly and
> >>> adds complexity to authentication
> >>> 2. Develop some sort of a "metadata" storage.  Some sort of a persistent
> >>> structure that will keep track of references for each given type.
> >>> Probably
> >>> the best thing in the long run, but requires things like hidden,system
> >>> stores.  Kind of complicated.
> >>> 3. Add a reference counter on NodeTypeImpl itself.  Probably the
> >>> simplest
> >>> solution.  Modifications will need to be made to the logic of persisting
> >>> new
> >>> and deleting items (as it would have to be in #2), but this way provides
> >>> for
> >>> the cheapest and quickest way to see if there are live nodes of a
> >>> certain
> >>> type
> >>>
> >>>
> >>> Jukka Zitting wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>On 12/26/06, anton_slutsky <aslutsky@applevac.com> wrote:
> >>>>
> >>>>>I'm wondering if anyone's actively working on implementing the
> >>>>>checkForReferencesInContent() method (quoted below).  Because if
not,
> >>>>>we'd
> >>>>>like to contribute source.  unregisterNodeTypes() doesnt work without
> it.
> >>>>>Makes it a bit of a pain to write unit tests as well as some
> application
> >>>>>functionality.  Please let me know if anyone's doing this already
so we
> >>>>>dont
> >>>>>duplicate effort.
> >>>>
> >>>>There's a long-standing feature request JCR-322 about this, but
> >>>>although it's popped up in discussion every now and then, there hasn't
> >>>>yet been much real effort to resolve it. Contributions would be very
> >>>>welcome!
> >>>>
> >>>>Note that implementing the method is somewhat hard, as you'd
> >>>>essentially need to get a global write lock on the entire repository
> >>>>and traverse all the content to find the node type references. This
> >>>>operation might also interfere with any pending transient or
> >>>>transactional changes.
> >>>>
> >>>>BR,
> >>>>
> >>>>Jukka Zitting
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8793775
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message