You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "David G." <da...@gmail.com> on 2015/04/05 17:57:02 UTC
Teasing protected content to lower-privileged users
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!
Re: Teasing protected content to lower-privileged users
Posted by "David G." <da...@gmail.com>.
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. <da...@gmail.com> 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. <da...@gmail.com> 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 <se...@gmail.com>
>> 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. <da...@gmail.com>
>>> 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!
>>>>
>>>
>>>
>>
>
Re: Teasing protected content to lower-privileged users
Posted by "David G." <da...@gmail.com>.
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. <da...@gmail.com> 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 <se...@gmail.com>
> 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. <da...@gmail.com>
>> 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!
>>>
>>
>>
>
Re: Teasing protected content to lower-privileged users
Posted by Sean Steimer <se...@gmail.com>.
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. <da...@gmail.com> 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!
>