jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: UserAdmin and GroupAdmin groups in Oak
Date Tue, 08 Oct 2013 09:52:44 GMT
just one additional comment:

the UserAccessControlProvider really only makes sense (if at all)
in the light of a multi-workspace setup where users are stored
in a dedicated separate workspace as we originally had it in CRX 1.x.
the users were in that setup shared between all workspaces.

nowadays i would consider this just legacy.
an somewhat equivalent replacement for that implementation in OAK
should IMO rather store user/group information underneath /jcr:system in
a place that is shared by all workspaces (similar to the version store
or the node type information)... but that's still just an idea and i
have no concrete plans for that (there are also quite some
open questions to solve).

kind regards

On 10/8/13 11:43 AM, "Angela Schreiber" <anchela@adobe.com> wrote:

>hi bertrand
>the two groups you mention are not built-in authorizables but
>only present with and used by the UserAccessControlProvider.
>currently we have no plans to provide a OAK level equivalent to that
>ac provider implementation but rather wish to take advantage
>of this rewrite to drop it altogether...
>however, as with most changes and differences: if we have a
>compelling reason to continue supporting it, we can try to build
>it again... it's rather a matter of priority than ability.
>having said that: in the near future we should IMO try to get
>the functionality completed that is actually used in production by us
>and our customers, which IMO should also be the default setup
>in OAK.
>as far as i understood the sling team is claiming that sling
>is implemented strictly against the JCR specification and using
>Jackrabbit API is considered evil... with that in mind i am a bit
>surprised to see how much it relies on implementation details.
>but maybe this is a good chance to clean up those parts?
>kind regards
>On 10/8/13 11:20 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org> wrote:
>>Angela wrote:
>>> ..there is no equivalent implementation in Oak and there will be no
>>> implementation as long as we don't support multiple workspaces...
>>The SLING-3144 issue is not related to multiple workspaces AFAIK, I'm
>>only missing these additional features provided by [1], as per its
>>- members of the 'User administrator' group are allowed to create,
>>modify and remove users,
>>- members of the 'Group administrator' group are allowed to create,
>>modify and remove groups,
>>So let me rephrase my question more precisely: even if the rest of
>>UserAccessControlProvider is not supported by Oak, are there plans to
>>support those out of the box user admin / group admin groups?
>>Otherwise I'll either implement them myself in the part of Sling that
>>needs them, or disable the corresponding Sling functionality when
>>running on Oak.
>>> [1] 

View raw message