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)