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