You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2009/09/18 15:14:16 UTC
[jira] Created: (JCR-2313) Improvements to user management (2)
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-alpha9, 2.0-alpha8, 2.0-alpha7
Reporter: angela
Fix For: 2.0.0
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.
[jira] Commented: (JCR-2313) Improvements to user management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759113#action_12759113 ]
angela commented on JCR-2313:
-----------------------------
List of changes
------------------------------------------------------------------------------------------------------------------------------------
- calculate jcr:uuid of user/group nodes from the ID instead of having it generated randomly
-> simplify getAuthorizable(String id) to a Session.getNodeByNodeId
-> structure of user/group nodes must no longer be defined by the impl
-> no need to ignore intermediatePath parameter
-> this also remove some limitations of the built-in, config driven node structure
- make userPath and groupPath configurable.
see UserManagerImpl#PARAM_USERS_PATH and UserManagerImpl#PARAM_GROUPS_PATH.
If the config option is missing the originally hardcoded values are used as default (-> UserConstants)
- Referees: remove concept form API and node type definition.
After all nobody i asked had strong arguments for the referees and i found myself struggling with the
concept that has been part of the initial patch created by christian.
- rep:userId is redundant now that jcr:uuid is used to lookup a user by id. a human readable form of the id was/is
present in the node's name.
> 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
> Priority: Blocker
> Fix For: 2.0.0
>
>
> 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.
[jira] Issue Comment Edited: (JCR-2313) Improvements to user
management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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 10/29/09 6:19 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 SystemUserManager that asserts the existance of
the admin user.
- 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).
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 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.
- 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 SystemUserManager that asserts the existance of
the admin user.
- 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
> Priority: Blocker
> Fix For: 2.0.0
>
>
> 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.
[jira] Issue Comment Edited: (JCR-2313) Improvements to user
management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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 10/22/09 5:29 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 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.
- 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 SystemUserManager that asserts the existance of
the admin user.
- 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).
was (Author: anchela):
List of changes
------------------------------------------------------------------------------------------------------------------------------------
- calculate jcr:uuid of user/group nodes from the ID instead of having it generated randomly
-> simplify getAuthorizable(String id) to a Session.getNodeByNodeId
-> structure of user/group nodes must no longer be defined by the impl
-> no need to ignore intermediatePath parameter
-> this also remove some limitations of the built-in, config driven node structure
- make userPath and groupPath configurable.
see UserManagerImpl#PARAM_USERS_PATH and UserManagerImpl#PARAM_GROUPS_PATH.
If the config option is missing the originally hardcoded values are used as default (-> UserConstants)
- Referees: remove concept form API and node type definition.
After all nobody i asked had strong arguments for the referees and i found myself struggling with the
concept that has been part of the initial patch created by christian.
- rep:userId is redundant now that jcr:uuid is used to lookup a user by id. a human readable form of the id was/is
present in the node's name.
> 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
> Priority: Blocker
> Fix For: 2.0.0
>
>
> 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.
[jira] Issue Comment Edited: (JCR-2313) Improvements to user
management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (JCR-2313) Improvements to user management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-2313.
-------------------------
Resolution: Fixed
Assignee: angela
> 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.0
>
>
> 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.
[jira] Updated: (JCR-2313) Improvements to user management (2)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2313:
-------------------------------
Priority: Blocker (was: Major)
As discussed, marking this as a blocker for Jackrabbit 2.0.
> 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
> Priority: Blocker
> Fix For: 2.0.0
>
>
> 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.
[jira] Issue Comment Edited: (JCR-2313) Improvements to user
management (2)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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/17/09 9:47 AM:
-------------------------------------------------------
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).
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 SystemUserManager that asserts the existance of
the admin user.
- 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
> Priority: Blocker
> Fix For: 2.0.0
>
>
> 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.