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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. >>> >>> >> >> >> -- >> -----------------------------------------< [EMAIL PROTECTED] >--- >> 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.
