You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2018/12/13 10:29:00 UTC
[jira] [Resolved] (SLING-8120) Pass the ResourceResolver to
CapabilitiesSource and remove path and namespaces limitations
[ https://issues.apache.org/jira/browse/SLING-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz resolved SLING-8120.
----------------------------------------
Resolution: Fixed
Forgot to mark this as fixed but it's been implemented
> Pass the ResourceResolver to CapabilitiesSource and remove path and namespaces limitations
> ------------------------------------------------------------------------------------------
>
> Key: SLING-8120
> URL: https://issues.apache.org/jira/browse/SLING-8120
> Project: Sling
> Issue Type: Improvement
> Components: Capabilities
> Affects Versions: org.apache.sling.capabilities 0.1.0, org.apache.sling.capabilities.jcr 0.1.0
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
> Priority: Major
> Fix For: org.apache.sling.capabilities 0.2.0, org.apache.sling.capabilities.jcr 0.2.0
>
>
> The Capabilities module currently implements pattern-based path and namespace restrictions ( described at [https://github.com/apache/sling-org-apache-sling-capabilities] ) to make sure access control is taken into account when exposing capabilities.
> Thinking about it, the following model would be a simpler way to implement this:
> * Pass the current {{ResourceResolver}} to the {{CapabilitiesSource}} services so they know the identity of the current user.
> * Document in that service interface that only information that that user can find out in other ways can be exposed as Capabilities - in other words, trust boundaries must not be crossed by these services.
> * Remove the current path and namespace patterns restrictions, as the above rule makes them unnecessary
> This results in a simpler model and delegates the trust boundary aspects to the {{CapabilitiesSource}} services, which can each decide what to do based on their "local" constraints.
> These changes will result in backwards incompatibilities, but as the only release of that module is 0.1.0 and it's labeled as a contrib module I think that's reasonable - better change this now than later.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)