Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0-alpha7, 2.0-alpha8, 2.0-alpha9
    • Fix Version/s: 2.0-beta3
    • Labels:
      None

      Description

      follow up issue as JCR-2199 is already closed.

        Activity

        angela created issue -
        Hide
        Jukka Zitting added a comment -

        As discussed, marking this as a blocker for Jackrabbit 2.0.

        Show
        Jukka Zitting added a comment - As discussed, marking this as a blocker for Jackrabbit 2.0.
        Jukka Zitting made changes -
        Field Original Value New Value
        Priority Major [ 3 ] Blocker [ 1 ]
        Hide
        angela added a comment - - 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).

        Show
        angela added a comment - - 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).
        angela made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee angela [ anchela ]
        Resolution Fixed [ 1 ]
        Jukka Zitting made changes -
        Fix Version/s 2.0-beta3 [ 12314350 ]
        Fix Version/s 2.0.0 [ 12312449 ]
        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            angela
            Reporter:
            angela
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development