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/11/19 15:17:00 UTC

[jira] [Created] (SLING-8120) Pass the ResourceResolver to CapabilitiesSource and remove path and namespaces limitations

Bertrand Delacretaz created SLING-8120:
------------------------------------------

             Summary: 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
            Reporter: Bertrand Delacretaz
            Assignee: Bertrand Delacretaz


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)