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! >>> >> >> >
