Lars - thanks for the feedback - i look forward to your extended answers. When you mention "handlers" .. do you mean creating custom servlets/JSPs to handle the POST requests?
Or create custom overriding supporting implementations for: SlingPostProcessor PostOperation NodeNameGenerator PostResponseCreator ContentImporter and allowing the SlingPostServlet to use those to handle custom impl? The reason I ask is ideally the "SlingPostServlet API pattern" would be used across all calls -- Adding divergent custom APIs for specific resources makes for a less maintainable app. Thanks -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, May 3, 2012 at 12:10 PM, Lars Krapf wrote: > Hello David > > > > Ah - this is what i'm looking for. Can you expound on "globbing ACL"? > > I was under the impression globbing ACLs were merely on the Node level. > > Could you enforce permissioning on the property level using this as well? > > > > > Yes. The rep:globs work on property level. > You can for example set deny jcr:write on a node and then add > allow jcr:write with globbing on jcr:title to allow writing > to the title property only. > > > > > I assume a structural restriction is setting a node to be a certain node > > type which enforces certain properties? Does this cause existing nodes to > > become inflexible? Once a node type, always a node type? > > There is some flexibility. > The node type is a protected property. (e.g. you can only change > it using the API call "setPrimaryType") > Additionally you could add a mix-in type to the node to extend > its functionality. > > > I think an example would be very helpful. > > > > My sample requirement is: Allow users to post comments with an optional > > supporting links (Properties: title, body, link). Title and Body are > > required, Link is optional. Once a comment is written Title and Body cannot > > be edited, but the Link can be changed by the original-submitter if it was > > not previously submitted. Upon success the user is displayed a "thank you" > > page, on error the user is returned to the comment form with the offending > > fields denoted and the previously submitted values repopulated. > > > > The "Title" must be alpha-numeric, non-empty and unique across comment > > titles. > > The "Body" must be alpha-numeric, non-empty. > > The "Link" is optional, but if provided must be a well formed URL and > > responds to a GET with a 200 response. > > "sling:resourceType" must be "mysite/components/comment" > > "jcr:primaryType" must be "nt:unstructured" > > > > The only properties allowed on the node are as listed above (these > > resources will be consumed via a browser as HTML and as JSON for access by > > external clients). > > > > Using the SlingPostServlet and ACLs how can this requirement be met? > > I will have to get back to you on this. > Short answer: I don't think these input restrictions can be met with > just ACLs, you would need your own handler for this. > > Traditionally we do not bother to much with input validation > (e.g try to store anything unfiltered), and only potect the user on > output. (which i agree does not work to well for your link-juice > extraction case above) > > > Anonymous comments would be UGC created by unauth'd users. I think this is > > a very reasonable requirement for a web site. > > Yes this is an important use-case. > For managing content from unauthenticated sources, I suggest writing > an own handler as well. It should then read/write the content > using something like a special 'UGC' user. > > But I will still try to find you some meaningful examples. > > Cheers > Lars > >
