Hi David Maybe you missunderstood me. The idea in the linked thread is NOT implemented at this time. But the idea discussed there could also be the solution for your problem. The main idea is, that you can plug in any kind of ACL which is not covered by the JCR - so even special ACLs on properties or, as in the thread mentioned, eg. access from 8.00 to 17.00 to the resource could be implemented, because you can implement it in Java code. The only thing you have to do is to register something like a ResourceAccessController. But as said, this is not implemented yet. My suggestion was, not to implement something new which only covers the SlingPostServlet-case but introduce real ACLs for all actions (CRUD).
best regards mike > -----Original Message----- > From: David G. [mailto:[email protected]] > Sent: Wednesday, May 02, 2012 11:13 PM > To: [email protected] > Subject: Re: SlingPostServlet - Real-world concerns and general thoughts. > Discussion encouraged! > > Mike, > > I read through the thread you linked to and it appears that the > "ACLAwareResourceProvider" was an idea that Carsten floated but isn't > implemented (I can't find the interface in the sling github proj at least, or > any docs > around it). > > Without thinking too hard about how ACLs can be used to manage this type of > thing, it seems like modeling and applying the ACLs would get messy > (difficult to > maintain) -- also, I dont believe ACLs be applied on a property level in the > JCR. > Here's a list of the available privileges: > http://www.day.com/maven/jsr170/javadocs/jcr-2.0/constant- > values.html#javax.jcr.security.Privilege.JCR_ADD_CHILD_NODES > Even with ACLs on the node level, I don't see how you could only allow certain > child-nodes (named in a certain way, or with certain properties, etc.) to be > added > to a node by a client. > > Each resource type could have its own requirements on how it can be > manipulated > in VERY specific ways - I'm having a difficult time seeing how ACLs are > flexible > enough provide a robust real-world solution to using the SlingPostServlet. > > Have you seen this done on a large-scale in the wild? Ive very interested in > seeing > "proven" solutions to this issue - as the devils are in the implementation > details :) > > -- > David Gonzalez > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Wednesday, May 2, 2012 at 3:21 PM, Mike Müller wrote: > > > Hi David > > > > I definitifely agree with you that the configuration if the webserver > (Apache/IIS/...) > > should not contain any application logic. The configuration should only > > harden > > the already existing security of the application itself. > > > > I think the problem you mentioning is less about filters but more about > > ACLs. > > We discussed ACLs in Sling a few months ago [1]. > > > > I feel confident that we rather should solve the ACLs for READ the same > > way as the ACLs for WRITE, MODIFY and DELETE. > > > > > > [1] http://markmail.org/thread/x77vyc3shinxdxof > > > > > > best regards > > mike > > > > > > > -----Original Message----- > > > From: Julian Sedding [mailto:[email protected]] > > > Sent: Wednesday, May 02, 2012 7:12 PM > > > To: [email protected] (mailto:[email protected]) > > > Subject: Re: SlingPostServlet - Real-world concerns and general thoughts. > Discussion > > > encouraged! > > > > > > Hi David > > > > > > This is an interesting question and I consider the concerns you > > > mention absolutely valid. I have been thinking about this problem > > > before, but never got around to implementing/prototyping my ideas. In > > > a SlingPostProcessor, the changes should not yet be persisted, so it > > > should be possible to do a session.refresh(true), in order to reset > > > the session. Alternatively, I imagine that you could throw an > > > exception from a SlingPostProcessor, and have the action aborted. This > > > would need testing though. > > > > > > My preferred idea would be a Filter implementation (scope request) > > > that checks whether the POST'ed parameters are allowed (and possibly > > > also whether they are valid). The allowed parameters (and validations) > > > could be described by a resource-type dependent description, which > > > could be expressed by a node structure. A contrived example: > > > > > > /apps/sample/comment > > > /comment.jsp > > > /properties > > > /email (validate=email, mandatory=true) > > > /website (validate=url) > > > /text (validate=length, min=20, max=500) > > > > > > The filter implementation would then only allow POSTs where the > > > allowed parameters correspond to the configured properties. Different > > > validation implementations could be hooked in as OSGi services, > > > identified by name (e.g. email, url, length) and consuming any given > > > supplemental properties (e.g. min, max). > > > > > > Of course there is more to it, e.g. how do you handle POSTs that > > > create intermittent nodes, i.e. "./node/property=value", how do you > > > deal with uploads etc. It should be possible to accommodate these into > > > whatever description of the allowed (white-listed) properties, > > > however. > > > > > > Do you see the need for a use-case, where POST validation would not be > > > "per resource-type"? > > > > > > Regards > > > Julian > > > > > > > > > On Wed, May 2, 2012 at 5:47 PM, David G. <[email protected] > (mailto:[email protected])> 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). > > > > > > > > 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. > > > > > > > > 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) > > > > 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. > > > > > > > > Which leaves creating POST servlet/jsp handlers for each resource-type > > > > to > handle > > > data manipulation, which will be used in lieu of the SlingPostServlet. > > > > > > > > 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. > > > > > > > > > > > > Am i missing something here? > > > > > > > > Does anyone have examples of actual Prod sites where the > > > > SlingPostServlet > is > > > heavily leveraged to allow public clients manipulate data? > > > > > > > > I'd love to hear everyone's thoughts and how they've handle similar > situations. > > > > > > > > -- > > > > David Gonzalez > > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > > > > > > > > > > > > > >
