It seems like what you actually need is 2 parallel resource trees, one with the protected content, and another with a rendition of the protected content which only includes the properties which are anonymously viewable. Why not create the second tree with a custom resource provider rooted at /teasers, so your sling:include looks something like:
<sling:include path=/teasers/<protected content teaserPath> resourceType=whatever/resource/type/i/want/> In the provider, you can get the protected resource using a raised security context, read it's properties as needed, and then return a synthetic resource only containing the properties which should be accessible to an anonymous user. Worth noting that I haven't tested this, but in theory it seems like it should work. --Sean On Sun, Apr 5, 2015 at 8:57 AM, David G. <[email protected]> wrote: > Have an interesting permissioning problem... > > I have a use case with large amounts of ACL protected content. As an > anonymous user, I need to see "content teasers" for the protected content > throughout the site; An anonymous user clicking through would be promoted > to login; a logged in user would directly access the content. > > I want to follow a resource-driven application design pattern using > sling:include to express a resource's representation using a resource-type. > > Example of what I would like to do (Pseudo code) > > // SlingRequest's ResourceResolver is that of Anonymous > > // This Service would look up content to tease using a teaser service RR > teaserPaths = teaserManager.getTeasersUsingElevatedResourceResolver(...); > > for teaserPath in teaserPaths { > // This will include using anonymous security context, which means > teaserPath will not resolve and nothing will show > <sling:include path=teaserPath > resourceType=whatever/resource/type/i/want/> > } > > ----- > > I know i can do something like below, but really dislike this design > pattern. > > Ex (Pseudo code) > > // SlingRequest's ResourceResolver is that of Anonymous > > // This Service would look up content to tease using a teaser service RR > teaserResources = > teaserManager.getTeasersUsingElevatedResourceResolver(...); > > for teaserResource in teaserResources { > > <h1> teaserResource.valueMap.get("title")</h1> > <p> teaserResource.valueMap.get("description")</p> > > } > > > > Any thoughts on how I can include another resource with some other Security > Context other than what is attached to the Sling Request? > > I understand that the "ideal" way is to permission the content such that it > its accessible to those that should be able to read it, but the > hierarchical nature of content make its hard (I only want certain > properties and don't want those pages/files i'm teasing to be directly > accessible) > > Thoughts? Thanks! >
