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!
