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 Sun, 04 Feb 2007 20:00:55 GMT

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#a8796602
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message