Jukka Zitting added a comment - 18/Sep/09 13:19 As discussed, marking this as a blocker for Jackrabbit 2.0.

angela added a comment - 24/Sep/09 13:14 - edited Changes to the API --------------------------------------------------------------------- Referees -> removed. this includes Authorizable#getPrincipals() Authorizable#addReferee(Principal) Authorizable#removeReferee(Principal) comment: Nobody i asked had strong arguments for the referees and i found myself struggling with the concept that has been part of the very initial patch. Ability to have User API changes transient. Therefore added UserManager#isAutoSave() UserManager#autoSave(boolean enable) comment: JCR generally defines all changes made on a Session level to be transient that require an extra save. User management however take some intermediate position as it isn't operating on 'path' or 'items' and there is no requirement that changes made are effective on the original Session. in order to have the ability make user API changes transient i decided to add the 2 methods above. Changes to the Implementation --------------------------------------------------------------------- AuthorizableImpl#setProperty does not fail if single valued property gets replaced by multivalued property and vice versa. AuthorizableImpl overriding Object#hashCode, #equals and #toString UserManagerImpl: make userPath and groupPath configurable. see also UserManagerImpl#PARAM_USERS_PATH and #PARAM_GROUPS_PATH. comment: If the config option is missing the originally hardcoded values are used as default (-> UserConstants) UserManagerImpl: only returns authorizables from nodes that have the expected node type AND reside under the corresponding root node (see configurable root paths above). UserManagementImpl#isAutoSave and #autoSave(boolean) is disabled in the default implementation as this one may be used with users stored i a dedicated system workspace. in this case the editing session is not the one the user manager was obtained from (-> session.save not working). UserManagerImpl: No creation of nested user/groups. In contrast to 1.5 nested groups/users are not supported any more. See also changes to the node type definitions. UserID/GroupID used for jcr:uuid The jcr:uuid of user/group nodes is calculated from the lowercased ID instead of having it generated randomly > simplify getAuthorizable(String id) to a Session.getNodeByNodeId > structure of user/group nodes must no longer be predefined > no need to ignore intermediatePath parameter > this also remove some limitations of the built-in, config driven node structure > rep:userId is not needed any more as the humand readable form can as well be retrieved from the node name. > login is case insensitive > creating multiple users/groups whose id only differ in terms of case will not be possible any more Group membership moved back to GroupImpl based on discussion along with the new user-per-workspace model (see below) we were once again debating the ac constraints vs. performance (frequency of access) and decided to move the group membership infomation back to the GroupImpl as it was in JR 1.5. Allow subclasses of GroupImpl for custom implementations for consistency with the extensions made by dominique for UserImpl (rev.792467) Configuration of UserManager as part of the SecurityManager config. improved, added UserManagerConfig Added isSystemUserManager to the UserManager implementation. UserManager instances having this flag turned on assert the existance of the admin user. Conflicting nodes having the same jcr:uuid as calculated for the admin user node, will be removed. JackrabbitSecurityManager#getAuthContext was changed to take an additional param workspaceName -> see user-per-workspace below JackrabbitSecurityManager#getUserID was changed to take an additional workspaceName parameter. -> see user-per-workspace below Additional tests in various areas. among other: > intermediate path containing parent elements > recreation of users (reuse of id) > property type of membership > collision of user/group node with some intermediate folder > test transient vs. autosaving user changes Changes to the NodeType Definitions --------------------------------------------------------------------- rep:AuthorizableFolder > no longer has protected child node definitions. > extends from nt:hierarchyNode > no longer extends from mix:referenceable rep:Authorizable > no longer defines protected child node definitions. > may have residual child nodes meant to be used for application specific content. > no longer defines rep:referees property > no longer defines rep:groups property > extends from nt:hierarchyNode rep:Group > defines rep:members property (again) rep:User > no longer defines mandatory rep:userID New Functionality --------------------------------------------------------------------- We decided to try an alternative approach for storing user and group information. Instead of having a separate, dedicated workspace that stores user/groups for the whole repository, there should be the ability to keep users/groups in each workspace. Both approaches can be used based on the SecurityManager configuration: The DefaultSecurityManager stores users/groups in a separate workspace as it used to be. The new approach is obtained when using the new security manager implementation. Backwards Compatibility Issues --------------------------------------------------------------------- I didn't yet try to run the new user management on an older version. The user manager configuration provides a compatibility config option that currently addresses < 2.0 lookup of user/groups by ID but none of the recent changes that potentially cause troubles (group membership and the nt:hierarchyNode are candidates from my point of view).