[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 11/20/13 10:16 AM: --- moved to http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-doc/src/site/markdown/differences_user.md was (Author: anchela): h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}} as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false See also PARAM_SUPPORT_AUTOSAVE below; while this should not be needed if application code has been written against the Jackrabbit API (and thus testing if auto-save mode is enabled or not) this configuration option can be used as last resort. h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 10/30/13 11:39 AM: --- h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}} as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false See also PARAM_SUPPORT_AUTOSAVE below; while this should not be needed if application code has been written against the Jackrabbit API (and thus testing if auto-save mode is enabled or not) this configuration option can be used as last resort. h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 10/3/13 8:43 AM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}}s as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 10/3/13 2:50 PM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}}s as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 10/3/13 2:52 PM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}} as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 10/3/13 2:53 PM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}} as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 8/8/13 7:37 AM: h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}s as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: adjust query_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 8/8/13 7:43 AM: h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. The 'everyone' Group As in Jackrabbit 2.x the OAK implementation contains special handling for the optional group corresponding to the {{EveryonePrincipal}} which always contains all {{Authorizable}}s as member. As of OAK this fact is consistently reflected in all group membership related methods. _TODO: OAK-949 (query)_ h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 8:15 AM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. f) XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 8:24 AM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. f) XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 8:43 AM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 8:45 AM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 3:24 PM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/26/13 6:41 PM: - h4. 1. Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: h5. General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). h5. User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. h5. Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. h5. Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. h5. Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false h5. XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - NEW: The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). - NEW: Workspace Import h5. Group Membership _TODO_ (see OAK-482) h4. 2. Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): h5. Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). h5. Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/24/13 1:33 PM: - 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false f) XML Import As of OAK 1.0 user and group nodes can be imported both with Session and Workspace import. The difference compare to Jackrabbit are listed below: - Importing an authorizable to another tree than the configured user/group node will only failed upon save (- see UserValidator during the Root#commit). With Jackrabbit core it used to fail immediately. - The BestEffort behavior is now also implemented for the import of impersonators (was missing in JR). 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 9:34 AM: - 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is: {code} Repository#login(new GuestCredentials(), wspName); {code} was (Author: anchela): 1) Characteristics of the Default Implementation - The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 9:38 AM: - 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is: {code} Repository#login(new GuestCredentials(), wspName); {code} was (Author: anchela): 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 10:07 AM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is: {code} Repository#login(new GuestCredentials(), wspName); {code} was (Author: anchela): 1) Characteristics of the Default Implementation
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 10:09 AM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is: {code} Repository#login(new GuestCredentials(), wspName); {code} 3) Authorizable Actions 4) API
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 12:01 PM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is [see also OAK-793]: {code} Repository#login(new GuestCredentials(), wspName); {code} 3) Authorizable Actions
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 12:14 PM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is [see also OAK-793]: {code} Repository#login(new GuestCredentials(), wspName); {code} 3) Authorizable Actions
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 12:18 PM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is (see also OAK-793): {code} Repository#login(new GuestCredentials(), wspName); {code} 3) Authorizable Actions
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475 ] angela edited comment on OAK-791 at 7/19/13 12:17 PM: -- 1) Characteristics of the Default Implementation The default user management implementation present with OAK always stores user/group information in the workspace associated with the editing Session (see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant corresponding to Jackrabbit's default UserManagerImpl is blocked by missing workspace handling (see OAK-118). The current user manager has the following characteristics that differ from the corresponding Jackrabbit implementation: a) General - Changes made to the user management API are always transient and require Session#save() to be persisted. - In case of a failure Session#refresh is no longer called in order to prevent reverting other changes unrelated to the user mgt operation. Consequently it's the responsibility of the API consumer to specifically revert pending or invalid transient modifications. - The implementation is no longer built on top of the JCR API but instead directly acts on Tree and PropertyState defined by the OAK API. This move allows to make use of the user management API within the OAK layer (aka SPI). b) User/Group creation - The rep:password property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that User#changePassword does not allow to remove the password property. - UserManager#createGroup(Principal) will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added UserManager#createGroup(String groupID). - Since OAK is designed to scale with flat hierarchies the former configuration options 'autoExpandTree' and 'autoExpandSize' are no longer supported. c) Handling of the Authorizable ID - As of OAK the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group. - The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID. - Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the ID property is missing. - The name of the authorizable node is generated based on a configurable implementation of the 'AuthorizableNodeName' interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name. d) Equals and HashCode for Authorizables The implementation of Object#equals() and Object#hashCode() for user and groups slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of the underlaying JCR node but only compares IDs and the user manager instance. e) Autosave behavior Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently, - UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException - UserManager#isAutoSave() always returns false 2) Builtin Users The setup of builtin user and group accounts is triggered by the configured WorkspaceInitializer associated with the user management configuration (see Configuration section below). The default user mgt implementation in OAK comes with an initializer that creates the following builtin user accounts (as in JR2): a) Administrator user The admin user is always being created. The ID of this user is retrieved from the user configuration parameter PARAM_ADMIN_ID, which defaults to admin. As of OAK 1.0 however the administrator user might be created without initial password forcing the application to set the password upon start (see PARAM_OMIT_ADMIN_PW configuration parameter). b) Anonymous user In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration parameter is null or empty. Note, that the anonymous user will always be created without specifying a password in order to prevent login with SimpleCredentials. The proper way to obtain a guest session is [see also OAK-793]: {code} Repository#login(new GuestCredentials(), wspName); {code} 3) Authorizable Actions