Re: defining a new primary node type on a fly
Well I don't think it is that simple to protect with just ACLs. Unless things have changed, the jackrabbit ACLs are set at the node level, not the property level. If you grant the jcr:modifyProperties privilege to some user on an unstructured node, then that user now has the ability to create additional arbitrary properties on that node. For example, the app may want to allow a user to edit their own comments to a blog post. Then that user could store their mp3 collection on your unstructured node as binary properties by just using the REST apis provided by sling. If you use well defined node types, there is more protection against the above exploit since the set of properties is well known and can have appropriate constraints set on what is allowed to be stored in each property. That's my 2 cents. -Eric On Wed, Oct 17, 2012 at 10:00 AM, Alexander Klimetschek aklim...@adobe.comwrote: On 13.10.2012, at 00:37, Eric Norman eric.d.nor...@gmail.com wrote: I'd agree that using unstructured types can be useful for prototyping when the final structure is changing frequently. But I would be cautious about that approach for a production system. Unstructured node types can be a security hole since anyone with rights to modify properties on an unstructured node can add arbitrary garbage to your repository. Well defined node types provide a nice guard against that since unexpected child nodes and properties can not be added. You should use ACLs for that. Access rights and schema are two different things. Cheers, Alex
Re: defining a new primary node type on a fly
Hi Alex. Yes I know that you were serious. Your question was very relevant. I really have need of the definition of types. For now I just use the nt:unstructured. But from now I have a need of user defined types which then will be managed by filtering and transforming to other structures. Exactly for the filtering needs I should now the type primary type of the nodes. Then these nodes will be transformed to visual component in the Flex based interface. For that I need of object persistence also, but I have not implemented yet, because of asynchronous nature of the Sling CRUD. Actualy I managed to implement the unregistering of the types in runtime by using NodeTypeManager.unregisterNodeType(String). So the newly created runtime NodeTypes cannot be updated. I just unregister them and import back again. Everything is putted in SlingPostOperation with the operation property :operation=define. The biggest problem that took me the most time was the build configuration. It turns out that the interface NodeTypeManager is included from the couple maven artifacts. The apache-incubator-2.0.2 includes the package javax.jcr.nodetype and the native javax.jcr version 2.0 also includes the same package. In the NodeTypeManager Interface provided by apache-incubator-2.0.2 does not have unregisterNodeType method so the my solution that I found is to put the dependency definition of: dependency groupIdjavax.jcr/groupId artifactIdjcr/artifactId version2.0/version /dependency in the start of the dependancies / definitions node in the pom. Thus the build becomes successful, because the generated class path first includes the JAR file from this artifact. Thank you for everything guys. Dimitar On 10/11/2012 05:21 PM, Alexander Klimetschek wrote: On 11.10.2012, at 12:23, Dimitar Dimitrov ddimit...@consult.bg wrote: Alex you are amazingly insightful:). The NodeType definition in runtime was the easy part. :) As Felix recommends NodeTypeLoader.registerNodeType() did this perfectly. I just put it in new SlingPostOperation based bundle. Alex it seems that you have a lot of experience with this issue, so please could you give me some helpful tips for changing the NodeType definition on a fly :) No, I was serious about this. Autogenerating node types from some kind of UI definition is not a good idea. Just try to start with nt:unstructured and go from there, with JCR there is no need for schemas (= node types). Autogenerating implies that it will change and changing schemas is difficult with any database solution. Cheers, Alex
Re: defining a new primary node type on a fly
Hi again guys. I saw that the low level repository API should to be used when I want to change currently imported NodeType. This information is specified here http://sling.apache.org/site/content-loading.html. Thank you anyway guys. Dimitar On 10/11/2012 01:23 PM, Dimitar Dimitrov wrote: Hi everyone. :) On 10/10/2012 02:30 PM, Alexander Klimetschek wrote: On 10.10.2012, at 06:16, Dimitar Dimitrov ddimit...@consult.bg wrote: I am trying to import new node type definition by CND on a fly. We develop a Adobe Flex based interface which can build CND by hierarchical UI and I want to import this new node type into the JCR repository. For now when I want to import new node type definition I make a new OSGI Sling bundle and import the schema into it. Is there another way to importing the newly generated CND into the repository and start using it immediately. I think you are overusing node types here. For something like UI elements that will evolve a lot, I would not use a fixed schema in the repository. Rather use a few generic types like widget/component etc. but keep them unstructured. Because I see that your next question will be how to change existing node types on the fly ;-) Alex you are amazingly insightful:). The NodeType definition in runtime was the easy part. :) As Felix recommends NodeTypeLoader.registerNodeType() did this perfectly. I just put it in new SlingPostOperation based bundle. Alex it seems that you have a lot of experience with this issue, so please could you give me some helpful tips for changing the NodeType definition on a fly :) Thanks in advance. Dimitar Cheers, Alex
Re: defining a new primary node type on a fly
On 10.10.2012, at 06:16, Dimitar Dimitrov ddimit...@consult.bg wrote: I am trying to import new node type definition by CND on a fly. We develop a Adobe Flex based interface which can build CND by hierarchical UI and I want to import this new node type into the JCR repository. For now when I want to import new node type definition I make a new OSGI Sling bundle and import the schema into it. Is there another way to importing the newly generated CND into the repository and start using it immediately. I think you are overusing node types here. For something like UI elements that will evolve a lot, I would not use a fixed schema in the repository. Rather use a few generic types like widget/component etc. but keep them unstructured. Because I see that your next question will be how to change existing node types on the fly ;-) Cheers, Alex
