jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anton_slutsky <aslut...@applevac.com>
Subject Re: NodeTypeRegistry.checkForReferencesInContent()
Date Wed, 07 Feb 2007 12:29:01 GMT

So what do you guys think of my implementation?  I really hate to deploy my
apps with customized code.  I'd rather have it out there with an
out-of-the-box jackrabbit.


anton_slutsky wrote:
> 
> yeah, I figured the security thing out.  Took me long enough, but better
> late then never :-).  If you dont mind, could you look at the attached
> patch file?  This implementation just throws an exception if a conflict is
> found.  Naturally, type reassignment can also work, but I'm thinking that
> it could open a door to a bunch of issues with things like child nodes of
> the conflict node, parent node type definitions, and reference properties
> on other node.  
> 
> 
>  http://www.nabble.com/file/6235/nodetyperegistry.patch
> nodetyperegistry.patch 
> 
> 
> Tobias Bocanegra wrote:
>> 
>> 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 >---
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8844504
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message