I meanwhile found https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserInitializer.java which creates both the admin and the anonymous user, but haven’t found out yet how “everyone” is being created.
> On 13. Jun 2024, at 19:30, Konrad Windszus <[email protected]> wrote: > > Hi Angela, > Thanks a lot for your input. > As it turned out in some instances the according “everyone" authorizable has > been removed by mistake and some code cannot deal with that (due to missing > null checks). > I am wondering though who Jackrabbit creates the “everyone” authorizable in > the first place, and why it isn’t being restored after a restart > automatically. > > In Sling usually such setup is done via repoinit, but I guess in Oak there > should also be some kind of repo initialization which automatically restores > the most essential parts for running Oak in case of a restart, > Maybe we can improve Oak to automatically fix such user mistakes. > > Do you have some pointers to the code which creates the “everyone” > authorizable in the first place? > Thanks, > Konrad > > >> On 13. Jun 2024, at 18:53, Angela Schreiber <[email protected]> >> wrote: >> >> Hi Konrad >> >> There has been no change in that area for ages. >> >> Oak out of the box does not mandate a Group 'everyone' to exist in the user >> management. It will however always exist if you retrieve it through >> Principal Manager in the default implementation. So, >> >> >> * >> every user/group accessible through user management API will have a >> principal attached that is also accessible through principal management API >> * >> no every principal accessible through the principal management API is >> guaranteed to be backed by a user/group in user management. >> >> Reason: principals are required for access control setup. They may come from >> any source plugged into Oak.... and one source of principals is user/groups >> stored in the repository. >> >> AEM out of the box will have a group 'everyone' installed.... but if you >> chose to remove it, the access control evaluation and principal resolution >> for your logged in user would still work. >> So, testing for the lookup of the group to null, would just be defensive >> programming. >> >> Hope that helps >> Angela >> >> >> ________________________________ >> From: Konrad Windszus <[email protected]> >> Sent: Thursday, June 13, 2024 17:07 >> To: [email protected] <[email protected]> >> Subject: Authorizable for EveryonePrincipal >> >> EXTERNAL: Use caution when clicking on links or opening attachments. >> >> >> Hi, >> Was it always the case that the “everyone" principal could not be resolved >> to an Authorizable via >> org.apache.jackrabbit.api.security.user.UserManager.getAuthorizable(<EveryonePrincipal>)? >> I found several places in AEM code where the return value of >> UserManager.getAuthorizable(Principal) is unconditionally dereferenced. >> >> Is the null return value a new behaviour or has it always been like that? >> >> Thanks, >> Konrad >
