One thing I hadn't mentioned is that when you have specific resources that require GET/POST/PUT/DELETE, you will most likely be writing servlets extending SlingSafeMethodsServlet or SlingAllMethodsServlet which cater to that specific resource type, selector, extension. You can even register sling servlets which get triggered on a specific path. SlingPostServlet is the default servlet which would handle a request for which it couldn't find another servlet or script so it's not your only one. Best thing to do is download the Sling source and look at all kinds of sling servlet examples. Some docs here (http://sling.apache.org/site/servlets.html)
The other way is writing custom Resource Providers but that's more for when you want to serve resources which aren't JCR resources. I've been on projects where CQ5 has been used as a platform delivering an HTTP API (accepting GET/POST/PUT requests) for custom content lifecycle functions. So it can definitely be used as such because of Sling and OSGi. I developed a lot of those SlingSafeMethodsServlet and SlingAllMethodsServlet classes for that. Where CQ5 excels is that a lot of the CQ5 specific components (dialogs, client library manager, workflows, versioning, search API, query builder etc) are also at your disposal so you don't have to reinvent the wheel in many cases. Sarwar On Wed, May 2, 2012 at 5:40 PM, David G. <[email protected]> wrote: > Sarwar, > > Real-life experience with any sling-based apps are welcome - CQ included! > :) > > First off - thanks for your response! > > I can appreciate locking down content trees and verbs (GET/POST) on the > web server/reverse proxy side - however that doesn't address my primary > concerns. > > My concerns are more around resources that SHOULD allow POSTs to > manipulate data. I'll argue that creating a whitelist of query (read input) > params belongs in the app rather than a reverse proxy config. > > Using tools like mod_security/mod_rewrite to inspect query params and > (:operation, and property names, etc) seems extremely brittle and requires > very tight coupling between the app and the web server config -- and could > even start spilling "logic" into web server configs. > > CQ seems most often used as a content delivery platform rather than web > app platform that manages a wide variety of user input - however there is > really no reason is couldn't be used as such. Understanding how the > SlingPostServlet should/shouldn't be leveraged is critical to the success > of these types of "web app oriented" sling-based implementations though. > > I guess I'm most interested in your thoughts around your comment: > "you absolutely do need some hardening in terms of ACLs > and stuff like that." -- specifically "stuff like that" (considering ACLs > will only get you so far) with regards to the SlingPostServlet behavior :) > > > > > > -- > David Gonzalez > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Wednesday, May 2, 2012 at 12:23 PM, Sarwar Bhuiyan wrote: > > > Not sure if I should respond here with what we do with CQ5 but here goes. > > > > I consider CQ5 (or Sling) to be in the application tier so usually if > it's > > going to serve internet facing content or functionality, then it has to > be > > appropriated fronted by a web server in front which can do this > > whitelisting you're talking about depending on your needs. Most CQ5 > > installations will have Apache/IIS with CQ5 Dispatcher which will deny > all > > access and open up set paths or resources. You could probably use > > mod_security, mod_rewrite to add more of this type of thing or any other > > reverse proxy server like squid or varnish. It really depends on what the > > site is trying to do. > > > > On the server side, you absolutely do need some hardening in terms of > ACLs > > and stuff like that. That just comes with installing any server (CMS or > > not) in production. > > > > Sarwar > > > > On Wed, May 2, 2012 at 4: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) > > > > > > > > > > > >
