I noticed something interesting .. If I use an elevated (admin) RR to get a resource, and pass that resource into the
<sling:include resource="<%= adminResource %>" resourceType="test/title" ../> it works, however in the script (/apps/test/title/title.jsp) the resourceResolver.getUserID() belongs to the the RR on the request, however resource.getResourceResolver() belongs to the elevated user (in this case admin). This is a bit confusing though as the script (test/title) needs to know not to use the injected resourceResolver but rather the resource.getResourceResolver() .. On Sun, Apr 5, 2015 at 2:42 PM, David G. <[email protected]> wrote: > Sean - interesting idea; I really like RP's but have a few initial > thoughts/concerns... > > 1) If resource types that tease this content drop down to the JCR Node > apis, I'd hit some trouble since there are no real backing Nodes. (IDK what > other APIs will be used in these yeh; i'd wager at least a few drop to the > JCR APIs for some reason) > > 2) Exposing all necessary data, binary properties, nt:files, etc. for > teased content (ex. Thumbnails for PDFs) may end up creating a lot of > corner cases; It's not as simple as loading a few values into a ValueMap. I > think i'd rather just want to wrap the entire "real" resource, rather than > create some (brittle) mapping of the which properties I want to expose for > each "category" of overlayed resources. > > The odd part of this use case is, it feels like, its really the VIEWS of > the content that is "protected"; the content itself isnt in that its teased > and protected content drives the exposure of Teasers. For example, fulltext > search should include protected results that are teased - the thing we want > to protect is the "full" content rendition (Ex. HTML page) of the resource, > or the PDF rendition of a "PDF resource". > > On Sun, Apr 5, 2015 at 2:40 PM, David G. <[email protected]> wrote: > >> Sean - interesting idea; I really like RP's but have a few initial >> thoughts/concerns... >> >> 1) If resource types that tease this content drop down to the JCR Node >> apis, I'd hit some trouble since there are no real backing Nodes. (IDK what >> other APIs will be used in these yeh; i'd wager at least a few drop to the >> JCR APIs for some reason) >> >> 2) Exposing all necessary data, binary properties, nt:files, etc. for >> teased content (ex. Thumbnails for PDFs) may end up creating a lot of >> corner cases; It's not as simple as loading a few values into a ValueMap. I >> think i'd rather just want to wrap the entire "real" resource, rather than >> create some (brittle) mapping of the which properties I want to expose for >> each "category" of overlayed resources. >> >> The odd part of this use case is, it feels like, its really the VIEWS of >> the content that is "protected"; the content itself isnt in that its teased >> and protected content drives the exposure of Teasers. For example, fulltext >> search should include protected results that are teased - the thing we want >> to protect is the "full" content rendition (Ex. HTML page) of the resource, >> or the PDF rendition of a "PDF resource". >> >> >> >> On Sun, Apr 5, 2015 at 2:05 PM, Sean Steimer <[email protected]> >> wrote: >> >>> 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! >>>> >>> >>> >> >
