[ 
https://issues.apache.org/jira/browse/SLING-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-5006:
-----------------------------------
    Comment: was deleted

(was: You are right that the {{ServiceUserMapped}} only says that a service 
mapping configuration for a specific user is there. But I would extend its 
usage so that dependent services are also restarted if a change on the 
validator happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?)

> Allow to enable the usage of regular JCR users for service resolvers
> --------------------------------------------------------------------
>
>                 Key: SLING-5006
>                 URL: https://issues.apache.org/jira/browse/SLING-5006
>             Project: Sling
>          Issue Type: Improvement
>          Components: Service User Mapper
>    Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>            Reporter: Konrad Windszus
>            Assignee: Konrad Windszus
>             Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
>         Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to