hi felix thanks a lot for getting this started. this really sounds promising. i would like to give it closer look later this week and in order to provide feedback.
one thing that i noticed right away: the ServiceUserMapper defines a method 'getUserForService' which returns what the API calls a 'user name'. 1) is this intended to be equivalent to the userID. such as e.g. exposed by Session#getUserID if Sling runs on top of a JCR content repository? if this was the case i would like to suggest to consistently use userId both in the API and the implementation as the name of a user might be quite different from it's ID (for example in the CQ context). 2) irrespective on name vs Id i would suggest to avoid 'getUser*' if the method call returns a String. getUserName* or getUserId* would be more appropriate from my point of view. kind regards angela On 7/4/13 11:01 AM, Felix Meschberger wrote:
Hi all It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2]. I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle. I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much. Regards Felix [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative [3] https://issues.apache.org/jira/browse/SLING-2944
