I usually try to avoid using the nt:unstructured node type (and anything similar) to prevent issues where an authorized user is able to add unexpected content to the repository.
If you define JCR node types you can explicitly declare what properties and child nodes are allowed along with some simple constraints. Then I also usually register a POST servlet for each of the custom JCR node types that does some pre-validation of the submitted request parameters. If any of the validation fails, you can forward back to the original page to display the validation errors. If validation passes, you can just forward the request on to the default sling POST servlet to do the rest of the work. Regards, Eric On Tue, Jun 12, 2012 at 2:07 AM, Davide <getting...@gmail.com> wrote: > On 12/06/2012 07:13, Carsten Ziegeler wrote: > > Another solution is to not rely on the Sling post servlet but write > > special post scripts for the resource types you want to support. > > Thanks everyone for the suggestions. > > My rough idea was to use the JSON import for creating the initial > strucuture. Let's call it "1st POST". Then using the > resourceTypes+selectors+POST to update the already existing structures > (2nd POSTs). > > About the user having the rights and messing with the data it's always > possible. I'd just like to reduce the risk of people messing around just > for fun. > > > Btw, I still think that we need something in this area - along with > > better validation. I started a prototype long time ago, but never got > > it to a point to share it. But I plan to have something for the next > > adaptTo in September... > > I'll give a look at all the suggestions but I really think that Sling > should provide some "security" mechanism against misusage of PostServlet. > > Cheers > davide > >
