Hi Am 12.06.2012 um 10:40 schrieb Robert Munteanu:
> I've tried to update the ACLs for /apps and /libs using > > $ curl -FprincipalId=administrators -Fprivilege@jcr:all=granted > http://admin:admin@localhost:8080/libs.modifyAce.html > > This works for apps, but not for libs ; the error message from the HTML page > is > > Status: 404 > Message: Resource is not a JCR Node > Location: /libs > Parent Location: / This indicates that an actual /libs node does not exist. > > In the sling explorer I don't see any properties for those nodes so they are > probably not JCR nodes . I did not place any resources by myself under /libs > but this was created by some Sling bundles, for instance the Sling Explorer > > <Sling-Bundle-Resources> > /libs/sling/explorer, > /libs/sling/servlet/default/explorer > </Sling-Bundle-Resources> This are non-JCR resources not hooked off a /libs node. > > How can I make sure that ACLs are applied to the /libs folder as well? Create a /libs node to apply the ACLs 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 >>>>> >>>>
