[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

["Konrad Windszus (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14984947#comment-14984947 ] 

Konrad Windszus commented on SLING-5006:
----------------------------------------

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)