Hi, Am 12.06.2012 um 12:35 schrieb Robert Munteanu:
> Hi, > > >>> How can I make sure that ACLs are applied to the /libs folder as >> well? >> >> Create a /libs node to apply the ACLs > > Thanks, creating the node using webdav manually worked and then ACLs were > applied. I was just thrown off that the sling explorer did show a node for > libs. Yes, The Sling ResourceResolver exposes a virtual resource if there are resources below. So if there is a resource at /libs/sling/exporer, there is a virtual resource at /libs and probably also /libs/sling such that the full resource tree can be traversed Regards Felix > > Robert > >> >> Regards >> Felix >> >>> >>> Thanks, >>> >>> Robert >>> >>>> -----Original Message----- >>>> From: Robert Munteanu >>>> Sent: Tuesday, June 12, 2012 10:35 AM >>>> To: [email protected] >>>> Subject: RE: Securing scripts under {libs,apps} >>>> >>>> Hi Eric, >>>> >>>> (Thanks to Davide and David for their answers as well) >>>> >>>>> -----Original Message----- >>>>> From: Eric Norman [mailto:[email protected]] >>>>> Sent: Sunday, June 10, 2012 7:46 AM >>>>> To: [email protected] >>>>> Subject: Re: Securing scripts under {libs,apps} >>>>> >>>>> If I recall correctly, if all your scripts are published to the JCR >>>>> repository, then you can just configure the JCR ACL to deny read >>>> access >>>>> to >>>>> everyone. Sling uses a "script user" (admin by default) to read >> the >>>>> scripts, so the end user doesn't have to have rights to read those >>>>> script >>>>> resources to use them. On the other hand, if your scripts are >>>> provided >>>>> by >>>>> some non JCR resource provider then you would have more work to do >> to >>>>> block >>>>> read access to those files. >>>> >>>> I'll go down the route of denying access to everyone to/{libs,apps} >> and >>>> allowing only the administrators group to read those. I might tweak >> it >>>> more since - for instance - the sling explorer deploys static assets >> to >>>> /libs/sling/explorer. >>>> >>>> I'll also look into setting up some rules on the reverse proxy - >> which >>>> is already there. >>>> >>>> Thanks, >>>> >>>> Robert >>>> >>>>> >>>>> Regards, >>>>> Eric >>>>> >>>>> On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez >>>>> <[email protected]>wrote: >>>>> >>>>>> Ideally all security should be handled via JCR ACLs. Reverse proxy >>>>>> rules/dispatcher should be used to harden those ACLs. Be careful >>>>> using >>>>>> ACLs - as they may impede script resolution - I believe >>>>>> getResourceSuperType() where the SuperType is not readable by the >>>>> user >>>>>> will throw an error (unless this has already been fixed). >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On Jun 8, 2012, at 10:19 AM, Davide <[email protected]> wrote: >>>>>> >>>>>>> On 08/06/2012 13:46, Robert Munteanu wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've recently been made aware that all resources under /apps are >>>>>> readable by everyone. This includes JSP scripts and I presume >>>> bundles >>>>>> deployed under the install folder. >>>>>>>> >>>>>>>> What is the recommended way of securing access to such >>>> resources? >>>>>>> >>>>>>> hi Robert, >>>>>>> >>>>>>> normally I work with CQ and in that case there's the Dispatcher >>>>> (apache >>>>>>> module) that takes care about it. >>>>>>> >>>>>>> Let's say that without knowing sling too much, if I'd have to do >>>> it >>>>> I >>>>>>> would manage it a 2 levels. >>>>>>> >>>>>>> First one with ACL in jackrabbit. Giving the read access only >>>>> behind >>>>>>> authentication. >>>>>>> >>>>>>> Second using the apache rewrite rules a would rewrite all /apps >>>> and >>>>>>> /libs to a 404. >>>>>>> >>>>>>> HTH >>>>>>> Davide >>>>>>> >>>>>> >
