[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861576#comment-13861576 ] Carsten Ziegeler commented on SLING-2944: - [~fmeschbe] Can we close this issue? It seems everything is implemented 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: SLING-2944.patch, serviceusermapper.tgz 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 was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768103#comment-13768103 ] Carsten Ziegeler commented on SLING-2944: - I think this method makes not that much sense if we don't support the header as it's basically concatenating the bundle symbolic name with the service id. So this is more an utility method than a service method. But if you think that it's worth having it in the service, we can add it back again 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768130#comment-13768130 ] Felix Meschberger commented on SLING-2944: -- IMHO this is not really utility method but it is a question of abstraction. The getServiceUserName method takes a bundle and an optional sub-service name and maps this a user name. This implies that the actual extraction of the required service information is abstracted in the service and there is no API documentation that the bundle symbolic name is taken for this. I strongly suggest to re-add the method to keep supporting the abstraction. 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768165#comment-13768165 ] Carsten Ziegeler commented on SLING-2944: - Apart from the service implementation, no java client code needs this method - that's why I removed it. So it's completely up to the service implementation how to do the mapping. I've changed the log messages of the clients using this code to not assume how this is done in the service, so they are just outputting the bundle and the sub service name now as separate information. 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760085#comment-13760085 ] Carsten Ziegeler commented on SLING-2944: - I've removed the header stuff in rev 1520522 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760624#comment-13760624 ] Felix Meschberger commented on SLING-2944: -- [~cziegeler] Why did you remove the getServiceID method ? This is unrelated to the bundle header. 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731910#comment-13731910 ] Felix Meschberger commented on SLING-2944: -- Hmm, excellent point. The goal of the header is to allow for multiple bundles to cooperate on the same service -- the MTA for example where the sub services may be spread accross bundles. WDYT ? 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731925#comment-13731925 ] Carsten Ziegeler commented on SLING-2944: - Right - I think the point is to be able to configure this without a specific packaging (bundling) of services - so we rather want to configure this based on a service than on a bundle - as the service might move from one bundle to another. Unfortunately we only get support for the client bundle through a ServiceFactory. On the other hand we can't rely alone on a service identifier (comparable to the PID) as this would be open to the same attack as the additional header. So the only thing which is quiet safe to use is the bundle symbolic name as we have it right now. I think it's better to be a little bit safer with the burden of potentially more configuration if sub services spread across bundles. So I would remove the header 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731932#comment-13731932 ] Felix Meschberger commented on SLING-2944: -- Right using a service does not work: Not only is a service property unsafe, its also worthless: Its not allways a service desiring repository or resource tree access. It could also be a simple immediate component which happily sits in the background doing some cleanup (for example). But I am ok with removing the header stuff for now. 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730490#comment-13730490 ] Carsten Ziegeler commented on SLING-2944: - I'm wondering if we shouldn't remove the support for a header in the manifest and simply rely on bundle symbolic name? E.g. if a dev knows that the Sling eventing bundle uses this mechanism to get an admin session (or whatever is configured), the dev can simply use the header entry and use the symbolic name of the eventing bundle as the value, using the same configuration as the Sling eventing bundle. It's try that once a bundle can be deployed, more or less everything is possible, but still just relying on the symbolic name makes this concept a little bit easier, doesn't open the above mentioned door and doesn't make it's usage more difficult. 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729298#comment-13729298 ] Felix Meschberger commented on SLING-2944: -- Prepared initial documentation in Rev. 1510382 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, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729354#comment-13729354 ] Felix Meschberger commented on SLING-2944: -- Committed a first batch of implementations in Rev. 1510413: * Add ServiceUserMapper service and implementation bundle * Add service login methods to ResourceResolverFactory and SlingRepository * Add implementations of new methods 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, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729453#comment-13729453 ] Felix Meschberger commented on SLING-2944: -- Temporarily reverted the SlingRepository implementation in Jackrabbit Server in Rev. 1510446 to cut a 2.1.2 release first (see SLING-2923) 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, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729469#comment-13729469 ] Felix Meschberger commented on SLING-2944: -- Reapplied the temporarily removed changes to the Jackrabbit Server bundle in Rev. 1510453 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, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729547#comment-13729547 ] Felix Meschberger commented on SLING-2944: -- The following bundles have also to be updated: * Filesystem Resource Provider * Bundle ResourceProvider * Servlet Resolver * Jackrabbit UserManager These bundles implement the ResourceProvider interface and extend the AbstractResource class and thus have got a narrow import range of [2.3,2.4). I think this import range is not really appropriate for these interfaces: In OSGi Versioning speak these would be Consumer Type types. Thus these are intended to be implemented by consumers of the API and thus should be changed with care. See SLING-2993 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729563#comment-13729563 ] Felix Meschberger commented on SLING-2944: -- 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
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699874#comment-13699874 ] Felix Meschberger commented on SLING-2944: -- Discussion on dev@sling: http://markmail.org/message/2ucwgneqdsiffnbw 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, JCR Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, 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
