[ 
https://issues.apache.org/jira/browse/SLING-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz updated SLING-8120:
---------------------------------------
    Affects Version/s: org.apache.sling.capabilities 0.1.0
                       org.apache.sling.capabilities.jcr 0.1.0

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

Reply via email to