[
https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729563#comment-13729563
]
Felix Meschberger edited comment on SLING-2944 at 8/5/13 3:30 PM:
------------------------------------------------------------------
Fixed Servlet Resolver in Rev. 1510541:
Sling API 2.4.0 is not required and probably only has been updated to make sure
the import version range for the Resource API is correct. Given SLING-2993 we
should actually provide proper annotation of implemented API for the bundle
plugin to properly devise the import version range.
For now removing the 'provide:=true' import tag solves this issue, since we
only implement the ResourceProvider interface (intended to be @ConsumerType)
and extend AbstractSlingResource (which is safe to extend in @ConsumerType
fashion).
Same for Bundle Resource Provider in Rev. 1510562
and Filesystem Resource Provider in Rev. 1510565
and Jackrabbit UserManager in Rev. 1510567
and make sure Filesystem and Bundle Resource provider are used in the builder
in Rev. 1510569
was (Author: fmeschbe):
Fixed Servlet Resolver in Rev. 1510541:
Sling API 2.4.0 is not required and probably only has been updated to make sure
the import version range for the Resource API is correct. Given SLING-2993 we
should actually provide proper annotation of implemented API for the bundle
plugin to properly devise the import version range.
For now removing the 'provide:=true' import tag solves this issue, since we
only implement the ResourceProvider interface (intended to be @ConsumerType)
and extend AbstractSlingResource (which is safe to extend in @ConsumerType
fashion).
> Replace administrative login by service-based login
> ---------------------------------------------------
>
> Key: SLING-2944
> URL: https://issues.apache.org/jira/browse/SLING-2944
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver, Service User Mapper
> Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR
> Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Service User Mapper 1.0.0, Servlets Resolver 2.2.6, JCR
> Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0,
> File System Resource Provider 1.1.4, Extensions Bundleresource 2.1.4, API
> 2.5.0, Resource Resolver 1.1.0
>
> Attachments: serviceusermapper.tgz, SLING-2944.patch
>
>
> From the start Sling tried to solve the problem of providing services access
> to the repository and resource tree without having to hard code and configure
> any passwords. This was done first with the
> SlingRepository.loginAdministrative and later with the
> ResourceResolverFactory.getAdministrativeResourceResolver methods.
> Over time this mechanism proved to be the hammer to hit all nails.
> Particularly these methods while truly useful have the disadvantage of
> providing full administrative privileges to services where just some specific
> kind of privilege would be enough.
> For example for the JSP compiler it would be enough to be able to read the
> JSP source scripts and write the Java classes out to the JSP compiler's
> target location. Other access is not required. Similarly to manage users user
> management privileges are enough and no access to /content is really required.
> To solve this problem a new API for Service Authentication has been proposed
> at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication.
> The prototype of which is implemented in
> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative.
> This issue is about merging the prototype code back into trunk and thus fully
> implementing the feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
