[
https://issues.apache.org/jira/browse/JCR-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090816#comment-14090816
]
angela commented on JCR-3802:
-----------------------------
Thanks for the comments:
Jackrabbit (and JCR in general) actually doesn't have real use-cases for user
management API. That's just a nice to have feature for the built-in
authentication setup... which could perfectly be omitted. As far as the
system/service users are concerned I realized that we will run into some
oddities if we can't distinguish between a regular user account and users that
are intended take care of system administration tasks as they are defined by
the new service user concept in Sling; e.g. the the CUG feature i started
prototyping in Oak or the concept of AuthorizableAction... obviously that could
be worked around with some sort of path or an additional mixin type marking a
specific user as system user... but it fees a bit clumpsy to me if i have to
rely on the user account being stored in the repo with a given structure.
{quote}
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 ?
{quote}
i thought about introducing a separate type for the system users... but as long
as it's just a flag on the regular User interface, i didn't see too much value
in creating a separate type.
{quote}
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.
{quote}
Probably you are right... there is compelling reason for not allowing for
User.disable(String)
{quote}
UserUtil.isSystemUser is missing from the POC patch
{quote}
ok... found more bugs in the mean time :-)
{quote}
UserManagerImpl adds use of com.google.common.base.Strings[.isNullOrEmpty]. Is
that by intent or should this rather be org.apache.lang.StringUtil ?
{quote}
we use the google library throughout oak... not particular reason otherwise.
> 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)
