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


Reply via email to