[
https://issues.apache.org/jira/browse/SLING-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13596933#comment-13596933
]
Carsten Ziegeler commented on SLING-2780:
-
Yepp, that was a poor choice but :( now
2013/3/8 Ian Boston i...@tfd.co.uk:
Ok, next stupid question :)
How will the ResourceProviderDecorator protect from navigating using a
native object of the ResourceProvider impl acquired using an adaptTo ?
Another stupid question :)
How does a ResourceDecorator prevent such things?
I have another use case for the decorator, it's possible to enhance
resources with data coming from a different location, so for example
for the file resource provider I could store metadata about a file
somewhere else and combine the information. This would also support
updating/creating the
On Fri, Mar 8, 2013 at 8:53 AM, Ian Boston i...@tfd.co.uk wrote:
...How will the ResourceProviderDecorator protect from navigating using a
native object of the ResourceProvider impl acquired using an adaptTo ?...
By native object I assume you mean a JCR Node for example?
If yes you're right
On 8 March 2013 19:13, Carsten Ziegeler cziege...@apache.org wrote:
I have another use case for the decorator, it's possible to enhance
resources with data coming from a different location, so for example
for the file resource provider I could store metadata about a file
somewhere else and
2013/3/8 Bertrand Delacretaz bdelacre...@apache.org:
What I definitely want to keep is the if using JCR, don't use any
other access control mechanism constraint, and if people do otherwise
it's their problem.
Exactly - that summarizes the whole discussion very good :)
You can probably work
2013/3/8 Ian Boston i...@tfd.co.uk:
sources are navigable.
eg
/a is managed by a JCR Resource Provider wrapped in a
ResourceProviderDecorator
/a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
/a/b/c/d/e is allowed by the ResourceProviderDecorator
Node n =
On 8 March 2013 19:52, Carsten Ziegeler cziege...@apache.org wrote:
2013/3/8 Ian Boston i...@tfd.co.uk:
sources are navigable.
eg
/a is managed by a JCR Resource Provider wrapped in a
ResourceProviderDecorator
/a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
Hi,
Basically, I like the idea of ResourceProviderDecorator to augment and increase
the functionality of a decorated ResourceProvider. But we should not sell it as
a security device, which it is not.
Why not ?
(1) For the reasons explained by Ian: If you adaptTo the resource to the
See
https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1591/
Hi all
There have been a number of threads and proposal flying around recently in an
attempt to make the Resource API more secure: It started with Mike's
ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
I would like to promote a third strategy:
* ResourceProviders
See https://builds.apache.org/job/sling-trunk-1.6/changes
Hi,
just to clarify, the ResourceProviderDecorator is not a proposal for
security - it's a proposal for extensibility. Feature's like the
ResourceAccessGate can be implemented with them - but I think the
decorator makes sense regardless of that.
While I agree that resource providers should
Hi,
Should the ResourceAccessGate be a service or a utility helper class the
ResourceProvider can instance and configure? I can imagine generalising
path+principal+permission assertions as utility helper class leaving the
ResourceProvider with to implement an interface to provided data to feed
14 matches
Mail list logo
