[
https://issues.apache.org/jira/browse/JCR-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090775#comment-14090775
]
Felix Meschberger commented on JCR-3802:
----------------------------------------
Sounds good to me.
The API patch defines the properties of a system user. But what is the use case
for system users from a pure Jackrabbit point of view ? I understand the
support for Sling's SlingRepository.loginService method and I think that makes
sense. Is that enough to justify the introduction of system users in Jackrabbit
?
(Don't get me wrong. I think the idea is perfectly valid and with my Sling hat
on, I welcome it very much.)
And some comments on the POC patch:
* SystemUserImpl.checkValidTree checks for type AuthorizableType.USER to check
whether the tree is of the correct type. Is that correct or should that be
AuthorizableType.SYSTEM_USER ?
* UserValidator prohibits disabling system users. What is the reason ? I would
think we should be able to disable these users just as any other users for some
quick stop-gap security measures.
* UserUtil.isSystemUser is missing from the POC patch
* UserManagerImpl adds use of com.google.common.base.Strings[.isNullOrEmpty].
Is that by intent or should this rather be org.apache.lang.StringUtil ?
> User Management: API for System Users
> -------------------------------------
>
> Key: JCR-3802
> URL: https://issues.apache.org/jira/browse/JCR-3802
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api
> Reporter: angela
> Attachments: JCR-3802___POC_implementation_for_Oak.patch,
> JCR-3802_proposed_API.patch
>
>
> Apache Sling recently added the ability to define dedicated service users
> that allows to replace the troublesome
> {{SlingRepository.loginAdministrative}} with {{SlingRepository.loginService}}.
> In a default Sling repository backed by a Jackrabbit/Oak content repository
> this results in user accounts being created for these service users.
> Since these service users are never expected to represent a real subject that
> has a userId/password pair or profile information editable by this very
> subject, I figured out that it may be useful to cover these service users
> with the following API extensions, which would allow us to identify if a
> given user account is in fact a service (or system) user.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
