jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (JCR-2313) Improvements to user management (2)
Date Mon, 23 Nov 2009 13:44:39 GMT

    [ https://issues.apache.org/jira/browse/JCR-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759113#action_12759113
] 

angela edited comment on JCR-2313 at 11/23/09 1:44 PM:
-------------------------------------------------------

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).


      was (Author: anchela):
    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
- 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).

  
> Improvements to user management (2)
> -----------------------------------
>
>                 Key: JCR-2313
>                 URL: https://issues.apache.org/jira/browse/JCR-2313
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-api, jackrabbit-core
>    Affects Versions: 2.0-alpha7, 2.0-alpha8, 2.0-alpha9
>            Reporter: angela
>            Assignee: angela
>            Priority: Blocker
>             Fix For: 2.0-beta3
>
>
> follow up issue as JCR-2199 is already closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message