Lars - appreciate the responses - see my own inline: -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday, May 3, 2012 at 8:17 AM, Lars Krapf wrote: > Hello David > > Please find some comments inline. > > On 05/02/2012 05:47 PM, David G. wrote: > > > > I thought i'd throw this out there as I've been mulling it over for a while. > > > > Sling is a pretty powerful framework, and one of its most powerful pieces > > is the SlingPostServlet, which provides a client-based interface for > > manipulating data. > > > > Now, the SlingPostServlet seems very powerful and very useful in a trusted > > environment - for example, on the authoring side of sling-based CMS ;) -- > > where there is some amount of trust that the folks w access won't fire up a > > REST client and start shooting off operations (assuming they enjoy gainful > > employment). > > It's not too much about trust, but more about authorization. > You define where authors can write to by setting repository > ACLs. > Absolutely. I agreed wholeheartedly that "trust" is not truly sufficient -- thought, in the "real-world" trust is sometimes (often??) considered as much -- such as in enterprise CMS's that allow authors to post any data to nodes -- i won't name names. :) For instance, Author Mallory could POST full a HTML page representations to /content/good/en/services/jcr:content/title/hidden-page-prop with back links to her affiliate site (bad.com), get the Services page pushed through review (since hidden-page-prop would only be seen by someone inspecting the JCR or looking at full JSON/XML/Node-dump representations of the page) and then submit http://good.com/content/good/en/services/_jcr_content/title/hidden-page-prop to Google and start squeezing good.com for link juice! > > When you expose the SlingPostServlet to the public (internet) things seem > > like they can get dicey. For example, if I find a set of nodes that that > > are writeable to me (say under my profile, or some suer generated content > > tree) I could start adding unexpected data, like unexpected properties that > > could show up in public representations of the resource (XML, JSON, etc.) > > or moving/renaming nodes, etc. > > If you find a node that is (explicitly) writeable to you it is just > that. Data added there should not be unexpected, or you have a problem > with your ACLs. There's nothing the POST servlet can or should do > about that. > Sure - I am trying to understand how the best way (if there is a way) to manage what is written to a node and (after your reply now) what level of granularity is provided by JCR and how that maps to the standard SlingPostServlet operations. > > > There are a couple ways to help mitigate this: > > > > 1) Ensure all the correct permissions are applied to the resources in > > question (however this only helps prevent certain operations - if a > > resource is writable, permissioning won't restrict what properties I can > > write to it) > > For access control on a property level you can either use a globbing > ACL or structural restrictions in the node type definition. > But again: If a node is writeable to you, there must be reason for it. > 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? http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html 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? > > 2) Create SlingPostProcessors that handle all the various conditions - > > PostProcessors are executed after the POST operation has taken place, and > > I'm not aware of a way to tell Sling to revert all changes and fail the > > operation. > > 3) Create workflows/eventhandlers that perform some sort of async data > > verification/scrubbing - I don't like this sort of async as bad things can > > still happen to the data, and its difficult to alert the client of an issue. > > > > > I am not sure I really understand your point. > I believe there is no need for additional input verification/scrubbing. > Can you maybe give an example? > 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? Using a "traditional" web-app approach, this is fairly trivial: accept the POST, validate the data, if the data meets the validation requirements use the Session to save the data to the node, if not kick back an error response. The only ACLs required would be that the node is writable by the user. > > > > > Which leaves creating POST servlet/jsp handlers for each resource-type to > > handle data manipulation, which will be used in lieu of the > > SlingPostServlet. > > But only for the (imo rare) cases that could not be handled by ACLs / > node types? Even UGC is usually created by authenticated users only. > Anonymous comments would be UGC created by unauth'd users. I think this is a very reasonable requirement for a web site. > > > > > TLDR > > > > My problem in using the SlingPostServlet requires you to develop > > (conceptually) a blacklist of behaviors/operations/data that should not be > > allowed - rather than a whitelist -- and I hope most of us will concede > > that a whitelist is (almost) always better than a blacklist when it comes > > to managing security. > > I'm all for whitelists. But IMO this is exactly how it works now. > Set deny all on / for everyone - and then reopen what > you need. What operations do you have in mind? > > > Cheers > Lars > > Lars - really appreciate the feedback. I'd love to here your thoughts and if possible get links to resources around how best to manage more complex ACLs combined with data validation all while using the SlingPostServlet to transport data. Thanks again.
