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 angela On 10/8/13 11:43 AM, "Angela Schreiber" <[email protected]> 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 >angela > > >On 10/8/13 11:20 AM, "Bertrand Delacretaz" <[email protected]> wrote: > >>Hi, >> >>Angela wrote: >>> ..there is no equivalent implementation in Oak and there will be no >>>equivalent >>> 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 >>javadoc: >> >>- 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. >> >>-Bertrand >> >>> [1] >>>http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security >>>/ >>>user/UserAccessControlProvider.html >
