[
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)
