from:"angela \(JIRA\)"

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/8/13 2:28 PM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java



  was (Author: anchela):
h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java


  
 Permissions: Document changes wrt Jackrabbit
 

 Key: OAK-942
 URL: https://issues.apache.org/jira/browse/OAK-942
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: doc
Reporter: angela
Assignee: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/8/13 2:38 PM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java



  was (Author: anchela):
h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java


  
 Permissions: Document changes wrt Jackrabbit
 

 Key: OAK-942
 URL: https://issues.apache.org/jira/browse/OAK-942
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: doc
Reporter: angela
Assignee: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/8/13 2:40 PM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

{code}
/**
 * @since oak 1.0
 */
 [rep:VersionablePaths]
  mixin
  - * (PATH) protected ABORT
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java



  was (Author: anchela):
h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java


  
 Permissions: Document changes wrt Jackrabbit
 

 Key: OAK-942

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/8/13 3:26 PM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
Due to the fine grained read permissions OAK read access can be separately 
granted/denied for nodes and properties. See also the section about extended 
restriction management in OAK-792. Granting the jcr:read privilege will result 
in a backwards compatible read access for nodes and their properties, while 
specifying {{rep:readNodes}} or rep:readProperties privileges allows separately 
granting or denying access to nodes and properties (see also OAK-910 for 
changes in the privilege definitions).

The only break in terms of backwards compatibility is the accessibility of 
version content underneath /jcr:system/jcr:versionStore. As of OAK the access 
to version content depends on the read permissions present with the versionable 
node while Jackrabbit 2.x doesn't apply any special rule.
This changes are covered by OAK-444 and address the concerns summarized in 
JCR-2963.

h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

{code}
/**
 * @since oak 1.0
 */
 [rep:VersionablePaths]
  mixin
  - * (PATH) protected ABORT
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java



  was (Author: anchela):
h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/9/13 8:44 AM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
Due to the fine grained read permissions OAK read access can be separately 
granted/denied for nodes and properties. See also the section about extended 
restriction management in OAK-792. Granting the jcr:read privilege will result 
in a backwards compatible read access for nodes and their properties, while 
specifying {{rep:readNodes}} or rep:readProperties privileges allows separately 
granting or denying access to nodes and properties (see also OAK-910 for 
changes in the privilege definitions). Together with the restrictions this new 
behavior now allows to individually grant/deny access to properties that match 
a given name/path/nodetype (and as a possible extension even property value).

The only break in terms of backwards compatibility is the accessibility of 
version content underneath /jcr:system/jcr:versionStore. As of OAK the access 
to version content depends on the read permissions present with the versionable 
node while Jackrabbit 2.x doesn't apply any special rule.
This changes are covered by OAK-444 and address the concerns summarized in 
JCR-2963.

h6. Property Modification
Since OAK the former SET_PROPERTY permission has been split such to allow for 
more fined grained control on writing JCR properties. In particular OAK clearly 
distinguishes between creating a new property that didn't exist before, 
modifying or removing an existing property.
This will allow to cover those cases where a given subject is only allowed to 
create content but doesn't have the ability to modify/delete it later on.

h6. Node Removal

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented 
(OAK-920, OAK-710)_  


h6. Version Management
h6. User Management

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

{code}
/**
 * @since oak 1.0
 */
 [rep:VersionablePaths]
  mixin
  - * (PATH) protected ABORT
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java



  was (Author: anchela):
h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/9/13 8:50 AM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
Due to the fine grained read permissions OAK read access can be separately 
granted/denied for nodes and properties. See also the section about extended 
restriction management in OAK-792. Granting the jcr:read privilege will result 
in a backwards compatible read access for nodes and their properties, while 
specifying {{rep:readNodes}} or rep:readProperties privileges allows separately 
granting or denying access to nodes and properties (see also OAK-910 for 
changes in the privilege definitions). Together with the restrictions this new 
behavior now allows to individually grant/deny access to properties that match 
a given name/path/nodetype (and as a possible extension even property value).

The only break in terms of backwards compatibility is the accessibility of 
version content underneath /jcr:system/jcr:versionStore. As of OAK the access 
to version content depends on the read permissions present with the versionable 
node while Jackrabbit 2.x doesn't apply any special rule.
This changes are covered by OAK-444 and address the concerns summarized in 
JCR-2963.

h6. Property Modification
Since OAK the former SET_PROPERTY permission has been split such to allow for 
more fined grained control on writing JCR properties. In particular OAK clearly 
distinguishes between creating a new property that didn't exist before, 
modifying or removing an existing property.
This will allow to cover those cases where a given subject is only allowed to 
create content but doesn't have the ability to modify/delete it later on.

h6. Node Removal
As of Oak `Node#remove()` only requires sufficient permissions to remove the 
target node. In contrast to Jackrabbit 2.x the validation will not traverse the 
tree and verify remove permission on all child nodes/properties. 
In order to obtain backwards compatible behavior with respect to tree removal 
the permission evaluation can be configured to traverse down the hierarchy upon 
removal. This config flag is a best effort approach but doesn't guarantee an 
identical behavior.

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented 
(OAK-920, OAK-710)_  

h6. Version Management
h6. User Management
By default user management operations require the specific user mgt related 
permission to be granted for the editing subject. This permission (including a 
corresponding privilege) has been introduced with OAK 1.0.
For backwards compatibility with Jackrabbit 2.x this behavior can be turned off 
by setting the corresponding configuration flag.

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

{code}
/**
 * @since oak 1.0
 */
 [rep:VersionablePaths]
  mixin
  - * (PATH) protected ABORT
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

- AccessControlConfiguration#getPermissionProvider


h4. 5 References

[0]

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
 ] 

angela edited comment on OAK-942 at 8/9/13 8:58 AM:


h4. 1. Characteristics of the Default Implementation

h5. General


h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action 
strings defined by JCR specification (see constants defined in 
{{Session.java}}) but also handles the names of the permission defined by OAK 
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The 
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as 
e.g. creating or removing user/group, changing user password and editing group 
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
Due to the fine grained read permissions OAK read access can be separately 
granted/denied for nodes and properties. See also the section about extended 
restriction management in OAK-792. Granting the jcr:read privilege will result 
in a backwards compatible read access for nodes and their properties, while 
specifying {{rep:readNodes}} or rep:readProperties privileges allows separately 
granting or denying access to nodes and properties (see also OAK-910 for 
changes in the privilege definitions). Together with the restrictions this new 
behavior now allows to individually grant/deny access to properties that match 
a given name/path/nodetype (and as a possible extension even property value).

The only break in terms of backwards compatibility is the accessibility of 
version content underneath /jcr:system/jcr:versionStore. As of OAK the access 
to version content depends on the read permissions present with the versionable 
node while Jackrabbit 2.x doesn't apply any special rule.
This changes are covered by OAK-444 and address the concerns summarized in 
JCR-2963.

h6. Property Modification
Since OAK the former SET_PROPERTY permission has been split such to allow for 
more fined grained control on writing JCR properties. In particular OAK clearly 
distinguishes between creating a new property that didn't exist before, 
modifying or removing an existing property.
This will allow to cover those cases where a given subject is only allowed to 
create content but doesn't have the ability to modify/delete it later on.

h6. Node Removal
As of Oak `Node#remove()` only requires sufficient permissions to remove the 
target node. In contrast to Jackrabbit 2.x the validation will not traverse the 
tree and verify remove permission on all child nodes/properties. 
In order to obtain backwards compatible behavior with respect to tree removal 
the permission evaluation can be configured to traverse down the hierarchy upon 
removal. This config flag is a best effort approach but doesn't guarantee an 
identical behavior.

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented 
(OAK-920, OAK-710)_  

h6. Version Management
h6. User Management
By default user management operations require the specific user mgt related 
permission to be granted for the editing subject. This permission (including a 
corresponding privilege) has been introduced with OAK 1.0.
For backwards compatibility with Jackrabbit 2.x this behavior can be turned off 
by setting the corresponding configuration flag.

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
 * @since oak 1.0
 */
[rep:PermissionStore]
  orderable
  + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
  + * (rep:Permissions) = rep:Permissions protected IGNORE

/**
 * @since oak 1.0
 */
[rep:Permissions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
  + * (rep:Permissions) = rep:Permissions protected IGNORE
{code}

{code}
/**
 * @since oak 1.0
 */
 [rep:VersionablePaths]
  mixin
  - * (PATH) protected ABORT
{code}

h4. 3. API Extensions

org.apache.jackrabbit.oak.spi.security.authorization.permission
- {{PermissionProvider}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_


h4. 4. Configuration

* Permission Configuration
** AccessControlConfiguration#getPermissionProvider

* Configuration Parameters supported by the default implementation
** PARAM_PERMISSIONS_JR2:

[jira] [Created] (OAK-952) AccessControlValidator: fail for ACEs created for any of the admin principals

2013-08-09 Thread angela (JIRA)

angela created OAK-952:
--

 Summary: AccessControlValidator: fail for ACEs created for any of 
the admin principals
 Key: OAK-952
 URL: https://issues.apache.org/jira/browse/OAK-952
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Priority: Minor


we may consider failing any AC modification if the principal associated with
a given ACE is either the system principal, an admin principal or one of the 
principals listed as admin in the permission configuration.

while having ACEs for those prinicpals don't have an effect it might be 
confusing that they can be created in the first place and may create a wrong 
sense of security.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 8/9/13 9:23 AM:

h4. 1. Characteristics of the Default Implementation

h5. General

h5. JCR API
h6. Session#hasPermission and #checkPermission
Since OAK the permission related API calls not only allow to pass the action
strings defined by JCR specification (see constants defined in
{{Session.java}}) but also handles the names of the permission defined by OAK
(see {{Permissions#getString(long permissions)}}).

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

* READ_NODE: permission to read a node
* READ_PROPERTY: permission to read a property
* ADD_PROPERTY: permission to create a new property
* MODIFY_PROPERTY: permission to change an existing property
* REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY
* USER_MANAGEMENT: permission to execute user management related tasks such as
e.g. creating or removing user/group, changing user password and editing group
membership.

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h5. Permission Evaluation
h6. Reading
Due to the fine grained read permissions OAK read access can be separately
granted/denied for nodes and properties. See also the section about extended
restriction management in OAK-792. Granting the jcr:read privilege will result
in a backwards compatible read access for nodes and their properties, while
specifying {{rep:readNodes}} or rep:readProperties privileges allows separately
granting or denying access to nodes and properties (see also OAK-910 for
changes in the privilege definitions). Together with the restrictions this new
behavior now allows to individually grant/deny access to properties that match
a given name/path/nodetype (and as a possible extension even property value).

The only break in terms of backwards compatibility is the accessibility of
version content underneath /jcr:system/jcr:versionStore. As of OAK the access
to version content depends on the read permissions present with the versionable
node while Jackrabbit 2.x doesn't apply any special rule.
These changes are covered by OAK-444 and address the concerns summarized in
JCR-2963.

h6. Property Modification
Since OAK the former SET_PROPERTY permission has been split such to allow for
more fined grained control on writing JCR properties. In particular OAK clearly
distinguishes between creating a new property that didn't exist before,
modifying or removing an existing property.
This will allow to cover those cases where a given subject is only allowed to
create content but doesn't have the ability to modify/delete it later on.

h6. Node Removal
As of Oak `Node#remove()` only requires sufficient permissions to remove the
target node. In contrast to Jackrabbit 2.x the validation will not traverse the
tree and verify remove permission on all child nodes/properties.
In order to obtain backwards compatible behavior with respect to tree removal
the permission evaluation can be configured to traverse down the hierarchy upon
removal. This config flag is a best effort approach but doesn't guarantee an
identical behavior.

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

h6. Version Management
Reading and writing items in the version store does not follow the regular
permission evaluation but depends on access rights present on the corresponding
versionable node. In case the version information does no longer have a
versionable node in this workspace that original path is used to evaluate the
effective permissions that would apply to that node if the version was
restored.
Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the
regular JCR write permissions is required in order to execute version
operations and thus modify the version store. These changes are covered by
OAK-444 and address the concerns summarized in JCR-2963.

h6. User Management
By default user management operations require the specific user mgt related
permission to be granted for the editing subject. This permission (including a
corresponding privilege) has been introduced with OAK 1.0.
For backwards compatibility with Jackrabbit 2.x this behavior can be turned off
by setting the corresponding configuration flag.

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
* @since oak 1.0
*/
[rep:PermissionStore]
orderable
+ * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
+ * (rep:Permissions) =

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 8/9/13 9:33 AM:

h4. 1. Characteristics of the Default Implementation

h5. General
_TODO_

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
* @since oak 1.0
*/
[rep:PermissionStore]
orderable
+ * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
+ * (rep:Permissions) =

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 8/9/13 11:43 AM:
-

h4. 1. Characteristics of the Default Implementation

h5. General
_TODO_

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
* @since oak 1.0
*/
[rep:PermissionStore]
orderable
+ * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
+ * (rep:Permissions) =

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 8/9/13 11:43 AM:
-

h4. 1. Characteristics of the Default Implementation

h5. General
_TODO_

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

h5. Administrative Principals

h4. 2. Node Types
_TODO_

{code}
/**
* @since oak 1.0
*/
[rep:PermissionStore]
orderable
+ * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
+ * (rep:Permissions) =

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-08-09 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 8/9/13 12:36 PM:
-

h4. 1. Characteristics of the Default Implementation

h5. General
_TODO_

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

h5. Administrative Principals
The following principals always have full access to the whole content
repository irrespective of the access control content:
* {{SystemPrincipal}}
* All instances of {{AdminPrincipal}}
* All

[jira] [Updated] (OAK-754) Pluggable Security Setup

2013-09-04 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-754:
---

Assignee: angela

 Pluggable Security Setup
 

 Key: OAK-754
 URL: https://issues.apache.org/jira/browse/OAK-754
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: core
Reporter: angela
Assignee: angela

 container issue for all security features that should be pluggable at
 runtime:
 - authentication
 - authorization
 - user mgt
 - principal mgt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-998) Node#orderBefore() is not JCR conform

2013-09-05 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-998:
--

Assignee: angela

 Node#orderBefore() is not JCR conform
 -

 Key: OAK-998
 URL: https://issues.apache.org/jira/browse/OAK-998
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela

 In case you call node.orderBefore(nodeName, nodeName), oak throws
 IllegalArgumentException with message limit is negative
 While you may reason that is a wrong useage the spec is explicit about the 
 expected behavior.
 {noformat}If this node supports child node ordering, this method inserts the 
 child node at srcChildRelPath into the child node list at the position 
 immediately the child node at destChildRelPath.
 To place the node srcChildRelPath at the end of the list, a destChildRelPath 
 of null is used.
 Note that (apart from the case where destChildRelPath is null) both of these 
 arguments must be relative paths of depth one, in other words they are the 
 names of the child nodes, possibly suffixed with an index.
 If srcChildRelPath and destChildRelPath are the same, then no change is made.
 This is session-write method, meaning that a change made by this method is 
 dispatched on save{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-998) Node#orderBefore() is not JCR conform

2013-09-05 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

angela resolved OAK-998.

Resolution: Fixed

fixed at revision 1520247.

thanks very much for finding and reporting this issue.

Node#orderBefore() is not JCR conform
-

Key: OAK-998
URL: https://issues.apache.org/jira/browse/OAK-998
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela

In case you call node.orderBefore(nodeName, nodeName), oak throws
IllegalArgumentException with message limit is negative
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{noformat}If this node supports child node ordering, this method inserts the
child node at srcChildRelPath into the child node list at the position
immediately the child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath
of null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-999) Version creates frozenNode children with orignial NoteType instead of frozenNode

2013-09-05 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759027#comment-13759027
 ] 

angela commented on OAK-999:


maybe the definition of the nt:frozenNode is simply wrong by defining the 
jcr:frozenUuid property as mandatory? in jackrabbit-core nobody would have 
noticed since the all nodes had a uuid anyway...

 Version creates frozenNode children with orignial NoteType instead of 
 frozenNode
 

 Key: OAK-999
 URL: https://issues.apache.org/jira/browse/OAK-999
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller

 For a Version the the children of a the Versions FrozenNode have the the 
 NodeType of their origin if they are not rferenceable. Expected is 
 nt:frozenNode.
 The JCR Spec is not explicit on the node-type for this Nodes but it is not 
 Compatible with JR2
 Dummy Test Case that just starts a Oak Repository
 {code}
 public class Issue extends RepositoryBaseTest {
 @Test
 public void testVersionChild() throws RepositoryException {
 Session admin = getAdminSession();
 Node parent = 
 admin.getRootNode().addNode(getClass().getSimpleName()+System.currentTimeMillis(),
  JcrConstants.NT_UNSTRUCTURED);
 Node child = parent.addNode(child);
 parent.addMixin(JcrConstants.MIX_VERSIONABLE);
 admin.save();
 VersionManager vm = admin.getWorkspace().getVersionManager();
 Version v = vm.checkin(parent.getPath());
 Node frozenChild = v.getFrozenNode().getNode(child.getName());
 Assert.assertEquals(JcrConstants.NT_FROZENNODE, 
 frozenChild.getPrimaryNodeType().getName());
 }
 }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-1002) JackrabbitAccessControlList.addEntry() thwos NoSuchMethodError

2013-09-06 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1002:
---

Assignee: angela

 JackrabbitAccessControlList.addEntry() thwos NoSuchMethodError
 --

 Key: OAK-1002
 URL: https://issues.apache.org/jira/browse/OAK-1002
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: security
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela

 Trying to add an Entry to an Acl throws a NoSuchMethodError.
 I have guava 14.0.1 in my classpath
 {noformat}
 java.lang.NoSuchMethodError: 
 com.google.common.collect.Maps.valueIterator(Lcom/google/common/collect/UnmodifiableIterator;)Lcom/google/common/collect/UnmodifiableIterator;
   at 
 com.google.common.collect.ImmutableMapValues.iterator(ImmutableMapValues.java:46)
   at 
 com.google.common.collect.ImmutableMapValues.iterator(ImmutableMapValues.java:31)
   at 
 com.google.common.collect.ObjectArrays.fillArray(ObjectArrays.java:172)
   at 
 com.google.common.collect.ObjectArrays.toArrayImpl(ObjectArrays.java:167)
   at 
 com.google.common.collect.ImmutableCollection.toArray(ImmutableCollection.java:58)
   at 
 com.google.common.collect.ImmutableSet.copyFromCollection(ImmutableSet.java:381)
   at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:376)
   at 
 org.apache.jackrabbit.oak.spi.security.authorization.restriction.AbstractRestrictionProvider.getSupportedRestrictions(AbstractRestrictionProvider.java:59)
   at 
 org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL.addEntry(ACL.java:104)
   at 
 org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlList.addEntry(AbstractAccessControlList.java:132)
   at com.day.cq.wcm.msm.impl.Issue.testNoSuchMethodError(Issue.java:31)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
   at 
 com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
 {noformat}
 Stepps to reproduce
 {code}
 @Test
 public void testNoSuchMethodError() throws RepositoryException {
 Repository repo = new Jcr().createRepository();
 Session admin = repo.login(new SimpleCredentials(admin, 
 admin.toCharArray()), null);
 Node node = admin.getRootNode().addNode(lala, 
 JcrConstants.NT_UNSTRUCTURED);
 admin.save();
 Principal adminPrincipal = ((JackrabbitSession) 
 admin).getPrincipalManager().getPrincipal(admin);
 JackrabbitAccessControlList acl = 
 AccessControlUtils.getAccessControlList(admin, node.getPath());
 acl.addEntry(adminPrincipal,

[jira] [Commented] (OAK-999) Version creates frozenNode children with orignial NoteType instead of frozenNode

2013-09-06 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760051#comment-13760051
 ] 

angela commented on OAK-999:


ok... in this case the mandatory flag is probably correct but we should rather 
read the
jcr:frozenUUID to be the frozen identifier of the node, which apart from 
referenceable nodes is a implementation detail. that way round it actually 
makes sense.

 Version creates frozenNode children with orignial NoteType instead of 
 frozenNode
 

 Key: OAK-999
 URL: https://issues.apache.org/jira/browse/OAK-999
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller

 For a Version the the children of a the Versions FrozenNode have the the 
 NodeType of their origin if they are not rferenceable. Expected is 
 nt:frozenNode.
 The JCR Spec is not explicit on the node-type for this Nodes but it is not 
 Compatible with JR2
 Dummy Test Case that just starts a Oak Repository
 {code}
 public class Issue extends RepositoryBaseTest {
 @Test
 public void testVersionChild() throws RepositoryException {
 Session admin = getAdminSession();
 Node parent = 
 admin.getRootNode().addNode(getClass().getSimpleName()+System.currentTimeMillis(),
  JcrConstants.NT_UNSTRUCTURED);
 Node child = parent.addNode(child);
 parent.addMixin(JcrConstants.MIX_VERSIONABLE);
 admin.save();
 VersionManager vm = admin.getWorkspace().getVersionManager();
 Version v = vm.checkin(parent.getPath());
 Node frozenChild = v.getFrozenNode().getNode(child.getName());
 Assert.assertEquals(JcrConstants.NT_FROZENNODE, 
 frozenChild.getPrimaryNodeType().getName());
 }
 }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-1004) Missing exports and typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1004:


Assignee: angela

 Missing exports and typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-1004) Missing exports and typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762843#comment-13762843
 ] 

angela commented on OAK-1004:
-

if fixed the missing comma at revision 1521368.

why do you think the 2 packages need to be exported? IMO they should not... so, 
i would be interested
to know why this would be needed.

 Missing exports and typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-1004) Missing exports and typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762843#comment-13762843
 ] 

angela edited comment on OAK-1004 at 9/10/13 9:10 AM:
--

if fixed the missing comma at revision 1521368.

why do you think the 2 packages need to be exported? IMO they should not 
because the only contain implementations... so, i would be interested to know 
why this would be needed.

  was (Author: anchela):
if fixed the missing comma at revision 1521368.

why do you think the 2 packages need to be exported? IMO they should not... so, 
i would be interested
to know why this would be needed.
  
 Missing exports and typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-1005) OpenAuthenticationConfiguration should provide AuthInfo

2013-09-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1005.
-

Resolution: Won't Fix

 OpenAuthenticationConfiguration should provide AuthInfo
 ---

 Key: OAK-1005
 URL: https://issues.apache.org/jira/browse/OAK-1005
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: OAK-1005.patch


 While working on SLING-2788 I found that having 
 OpenAuthenticationConfiguration provide minimal AuthInfo is helpful in some 
 testing scenarios.
 I'll attach a suggested patch, I'm not very familiar with these security 
 classes so feel free to tweak. My use case is making sure the ContentSession 
 provides a userID, as currently some of my Sling tests fail due to the lack 
 of that (and yes I'm going to setup proper authentication there at some 
 point).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-1005) OpenAuthenticationConfiguration should provide AuthInfo

2013-09-10 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762881#comment-13762881
 ] 

angela commented on OAK-1005:
-

you can't and should not rely on ContentSession or Session returning a non-null 
user id!

since the OpenAuthenticationConfiguration doesn't perform any login and can't 
populate the
subject with principals it doesn't make too much sense to me to create an 
AuthInfo here.


 OpenAuthenticationConfiguration should provide AuthInfo
 ---

 Key: OAK-1005
 URL: https://issues.apache.org/jira/browse/OAK-1005
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: OAK-1005.patch


 While working on SLING-2788 I found that having 
 OpenAuthenticationConfiguration provide minimal AuthInfo is helpful in some 
 testing scenarios.
 I'll attach a suggested patch, I'm not very familiar with these security 
 classes so feel free to tweak. My use case is making sure the ContentSession 
 provides a userID, as currently some of my Sling tests fail due to the lack 
 of that (and yes I'm going to setup proper authentication there at some 
 point).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-1004) Missing exports and typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762906#comment-13762906
 ] 

angela commented on OAK-1004:
-

if i remember correctly, i discussed this with antonio some time ago and he 
asked felix which said it's not needed. therefore i reverted my commit that 
moved all the login modules to the spi space which is exported.

so, let's reduce this issue to the typo. if it turns out to be required, we can 
create a separate issue for that.

 Missing exports and typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-1004) Typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1004:


Priority: Trivial  (was: Minor)

 Typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Trivial
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-1004) Typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1004.
-

Resolution: Fixed

 Typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Trivial
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-1004) Typo in oak-core pom.xml

2013-09-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1004:


Summary: Typo in oak-core pom.xml  (was: Missing exports and typo in 
oak-core pom.xml)

 Typo in oak-core pom.xml
 

 Key: OAK-1004
 URL: https://issues.apache.org/jira/browse/OAK-1004
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Assignee: angela
Priority: Minor
 Attachments: oak-core.patch


 There's a missing comma in the Jaas-ModuleClass statement, and I think the 
 org.apache.jackrabbit.oak.security.authentication.user and token packages 
 need to be exported. Patch follows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-521) Configurable AuthorizableAction(s)

2013-09-12 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-521.


Resolution: Fixed

 Configurable AuthorizableAction(s)
 --

 Key: OAK-521
 URL: https://issues.apache.org/jira/browse/OAK-521
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, jcr
Reporter: angela

 subtask to address a remaining TODO with respect to configuration
 of authorizable actions such that it's extensible and pluggable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-528) Support configurable/pluggable restrictions

2013-09-12 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-528.


Resolution: Fixed

 Support configurable/pluggable restrictions
 ---

 Key: OAK-528
 URL: https://issues.apache.org/jira/browse/OAK-528
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela

 apart from the built-in restrictions (rep:glob, possible a regexp matching,
 possible nt-matching) it would be desirable to allow for easy deployment
 of additional restrictions.
 in a first step i added a RestrictionProvider interface to the spi 
 authorization
 package that is intended to be used both for JCR ac-editing as well as for
 the ac-evaluation inside oak-core. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-1016) Anonymous session doesn't see node added by admin

2013-09-24 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1016.
-

Resolution: Not A Problem

jackrabbit used to have a configuration option that sets up full read 
permission for everyone on the whole repository (which by default was turned 
on). while this might be handy it's actually a security issue because the 
default setup should not grant read access to everybody. therefore i decided to 
drop that configuration option for oak.

if you want to have this for your tests, your setup should grant jcr:read on 
the root node in your test setup. something like:

{code}
AccessControlUtils.addAccessControlEntry(admin, /, 
EveryonePrincipal.getInstance(), privilegesFromName(Privilege.JCR_READ), true);
admin.save();
{code}

 Anonymous session doesn't see node added by admin
 -

 Key: OAK-1016
 URL: https://issues.apache.org/jira/browse/OAK-1016
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Affects Versions: 0.8
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: oak-jcr-anonymous.patch


 I'll attach a patch that demonstrates this, and I'm seeing the same problem 
 in SLING-3063

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-1026) AccessControlEntry.getPrivileges() behaves diffent than in Oak

2013-09-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776138#comment-13776138
 ] 

angela commented on OAK-1026:
-

thanks for finding this. i will fix it.

 AccessControlEntry.getPrivileges() behaves diffent than in Oak
 --

 Key: OAK-1026
 URL: https://issues.apache.org/jira/browse/OAK-1026
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr, security
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela
Priority: Minor
 Attachments: Issue.java


 Set an Ace of an JackrabbitAccessControlList Policy with the composits of a 
 an aggregate Privilege.
 Eg. the jcr:addNode, jcr:createNode, ... of jcr:write
 On read of the the AccessControlEntry.getPrivileges(), Oak returns the single 
 privileges. 
 On Jackrabbit the aggregate jcr:write is returned.
 I'm aware that both behaviors are valid accoring the specification
 {code}
 /**
  * Returns the privileges associated with this access control entry.
  *
  * @return an array of codePrivilege/codes.
  */
 public Privilege[] getPrivileges();
 {code}
 But it may get an migration issue. Though its occurence may be rare like in 
 testcases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-1026) AccessControlEntry.getPrivileges() behaves diffent than in Oak

2013-09-24 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1026:
---

Assignee: angela

 AccessControlEntry.getPrivileges() behaves diffent than in Oak
 --

 Key: OAK-1026
 URL: https://issues.apache.org/jira/browse/OAK-1026
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr, security
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela
Priority: Minor
 Attachments: Issue.java


 Set an Ace of an JackrabbitAccessControlList Policy with the composits of a 
 an aggregate Privilege.
 Eg. the jcr:addNode, jcr:createNode, ... of jcr:write
 On read of the the AccessControlEntry.getPrivileges(), Oak returns the single 
 privileges. 
 On Jackrabbit the aggregate jcr:write is returned.
 I'm aware that both behaviors are valid accoring the specification
 {code}
 /**
  * Returns the privileges associated with this access control entry.
  *
  * @return an array of codePrivilege/codes.
  */
 public Privilege[] getPrivileges();
 {code}
 But it may get an migration issue. Though its occurence may be rare like in 
 testcases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-680) AbstractRepositoryTest: missing proper permission setup

2013-09-24 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-680.


Resolution: Fixed

Committed revision 1525822.

 AbstractRepositoryTest: missing proper permission setup
 ---

 Key: OAK-680
 URL: https://issues.apache.org/jira/browse/OAK-680
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Priority: Minor

 there are some usages of AbstractRepositoryTest#createAnonymousSession
 that expect the created session to have read/write permission on the
 repository.
 as soon as we switch to a reasonable default-setup this will not work
 any more.
 possible solutions:
 a) create proper permission setup of anonymous as required in the tests
 b) fix tests to use a user with sufficient permission
 for the time being i will change #createAnonymousSession to just return
 an admin session as this blocks me.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-1026) AccessControlEntry.getPrivileges() behaves diffent than in Oak

2013-09-24 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1026.
-

Resolution: Fixed

thanks christian for finding and reporting this.

 AccessControlEntry.getPrivileges() behaves diffent than in Oak
 --

 Key: OAK-1026
 URL: https://issues.apache.org/jira/browse/OAK-1026
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr, security
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela
Priority: Minor
 Attachments: Issue.java


 Set an Ace of an JackrabbitAccessControlList Policy with the composits of a 
 an aggregate Privilege.
 Eg. the jcr:addNode, jcr:createNode, ... of jcr:write
 On read of the the AccessControlEntry.getPrivileges(), Oak returns the single 
 privileges. 
 On Jackrabbit the aggregate jcr:write is returned.
 I'm aware that both behaviors are valid accoring the specification
 {code}
 /**
  * Returns the privileges associated with this access control entry.
  *
  * @return an array of codePrivilege/codes.
  */
 public Privilege[] getPrivileges();
 {code}
 But it may get an migration issue. Though its occurence may be rare like in 
 testcases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-942) Permissions: Document changes wrt Jackrabbit

2013-09-25 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730703#comment-13730703
]

angela edited comment on OAK-942 at 9/25/13 9:10 AM:
-

h4. 1. Characteristics of the Default Implementation

h5. General
_TODO_

h5. Mapping of JCR Actions to Permissions
_TODO_

h5. Permissions
The set of permissions supported by OAK are listed in Permissions [0]. The
following changes have been compared compared to Jackrabbit 2.x:

The following permissions are now an aggregation of new permissions:
* READ: aggregates READ_NODE and READ_PROPERTY
* SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY

h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_

[jira] [Comment Edited] (OAK-792) AccessControl Management: Document changes wrt. Jackrabbit

2013-09-25 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718362#comment-13718362
 ] 

angela edited comment on OAK-792 at 9/25/13 9:11 AM:
-

h4. 1. Characteristics of the Default Implementation

h5. General
In general the authorization related code in OAK clearly separates between 
access control management (such as defined by the JCR and Jackrabbit API) and 
the internal permission evaluation (see also OAK-942).

The default implementation of the access control management corresponds to the 
resource-based implementation present with Jackrabbit 2.x. The former 
principal-base access control management is no longer available but it's 
functionality has been incorporated both in the default ac management 
implementation and the permission evaluation.

h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
As of OAK those methods throw {{PathNotFoundException}} if the corresponding 
node is not accessible by the editing session. This is in accordance with the 
behavior mandated by JSR 283 and a bug in Jackrabbit 2.x.

h6. AccessControlManager#getEffectivePolicies
In contrast to Jackrabbit 2.x the editing session is used to retrieve the 
effective policies and the policies returned by these methods are guarantueed 
to only return information that is otherwise accessible by the session. The 
corresponding methods in Jackrabbit 2.x use to throw an  exception in this 
situation.

h6. AccessControlPolicy
OAK introduces a new type of policy that enforces regular read-access for 
everyone on the trees that hold this new {{ReadPolicy}} [0]. The main usage of 
this new policy is to ensure backwards compatible behavior of repository level 
information (node types, namespace, privileges) that are now kept within the 
content repository. In Jackrabbit 2.x this information was stored in the file 
system without the ability to apply or enforce regular access control such as 
present with items in the repository.

_TODO: managing ReadPolicies (OAK-951)_

h6. AccessControlEntry
Validation: as of OAK the implementation of the {{AccessControlEntry}} 
interface is no longer in charge of validating the specified privileges. While 
some validation is still performed in the corresponding {{AccessControlList}} 
methods, the complete validation is delegated to the commit phase and executed 
by a specific {{Validator}} implementation. 

Restrictions: as of OAK the optional restrictions present with a given 
{{JackrabbitAccessControlEntry}} can be multivalued (see below).

h5. Jackrabbit API
h6. Principal-based Access Control
The principal-based access control management as present in Jackrabbit-core is 
no longer present with OAK. The main benefit of the principal-based approach 
has been incorporated with the changes in the default permission evaluation 
(see OAK-942). In addition the default access control manager implementation 
supports all methods defined by {{JackrabbitAccessControlManager}}; i.e. 
editing access control information by principal is possible as long as the 
editing session has sufficient permission on the target node(s). Similarly, the 
per principal policies exposed to a given session will always respect that 
access rights of that session.

h6. Restrictions
The implementation of the additional restrictions associated with an ACE has 
been modified/extended as follows:
* Separate restriction management API (see below) on the OAK level that allows 
to ease plugging custom restrictions.
* Changed node type definition for storing restrictions in the default 
implementation. 
** as of OAK restrictions are collected underneath a separate child node 
rep:restrictions
** restrictions can be multi-valued (see JCR-3637, JCR-3641)
** backwards compatible behavior for restrictions stored underneath the ACE 
node directly
* New restriction rep:ntNames, which allows to limit the affect ACE to nodes 
of the specified node type(s)

h4. 2. Node Types

As mentioned above the node type definitions have been extended to match the 
new functionality related to restrictions.
The node type definition for access control entries:

{code}
[rep:ACE]
  - rep:principalName (STRING) protected mandatory
  - rep:privileges (NAME) protected mandatory multiple
  - rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
  - rep:glob (STRING) protected   /* deprecated in favor of restrictions */
  - * (UNDEFINED) protected   /* deprecated in favor of restrictions */
  + rep:restrictions (rep:Restrictions) = rep:Restrictions protected
{code}

The new node type definition for restrictions:
{code}
/**
 * @since oak 1.0
 */
[rep:Restrictions]
  - * (UNDEFINED) protected
  - * (UNDEFINED) protected multiple
{code}

h4. 3. API Extensions and Public Classes

org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol

- {{AbstractAccessControlList}}
- {{ImmutableACL}}
-

[jira] [Commented] (OAK-444) Authorization for the jcr version store

2013-09-25 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777473#comment-13777473
 ] 

angela commented on OAK-444:


Committed revision 1526174: 
added access eval for configurations and activities resolving todos in the 
code. currently this cannot be tested as the corresponding features are still 
missing.

apart from that i would consider this issue fixed.

 Authorization for the jcr version store
 ---

 Key: OAK-444
 URL: https://issues.apache.org/jira/browse/OAK-444
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Assignee: angela

 as explained in JCR-2963 the version store needs special attention when
 it comes to access control and permissions enforced on the store.
 for oak we need to define mechanisms on how to control access to the
 version store and provide the possibility to limit access to individual
 parts of the version store. some possibilities are already listed in JCR-2963.
 additional topics include:
 - searching for versioned content
 - find and restore versions that have no corresponding versionable node in
   the content tree
 - ability to prevent access to version store altogether without preventing
   access to versions/version histories through JCR version operations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-444) Authorization for the jcr version store

2013-09-25 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-444.


Resolution: Fixed

 Authorization for the jcr version store
 ---

 Key: OAK-444
 URL: https://issues.apache.org/jira/browse/OAK-444
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Assignee: angela

 as explained in JCR-2963 the version store needs special attention when
 it comes to access control and permissions enforced on the store.
 for oak we need to define mechanisms on how to control access to the
 version store and provide the possibility to limit access to individual
 parts of the version store. some possibilities are already listed in JCR-2963.
 additional topics include:
 - searching for versioned content
 - find and restore versions that have no corresponding versionable node in
   the content tree
 - ability to prevent access to version store altogether without preventing
   access to versions/version histories through JCR version operations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-950) Remove org.apache.jackrabbit.oak.core from package-export

2013-09-25 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-950:
---

Attachment: OAK-950.patch

initial proposal on how to address this (except for the SolrBaseTest).

- move IdManager to a new plugins package
- move obs-part using Immutable* to plugins/observation

since IdManager used the package private method AbstractTree#getIdentifier and 
i didn't want to move all the AbstractTree, i made this method part of the Tree 
interface. that's a simplistic approach to get a patch and i am sure this will 
cause some discussion, because it tends to render the IdManager superfluous :-)

so, please review it and comment.
to me the fact that we have to export the internal core-package indicates that 
we have problem that should be discussed and - hopefully - addressed before we 
officially release oak.

 Remove org.apache.jackrabbit.oak.core from package-export
 -

 Key: OAK-950
 URL: https://issues.apache.org/jira/browse/OAK-950
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
 Attachments: OAK-950.patch


 IMO the package org.apache.jackrabbit.oak.core is the implementation of the
 oak api and should therefore only be used internally. exporting that package
 in the maven-bundle-plugin configuration is from my point of view a major bug.
 if it's needed it indicates that the package contains classes that are 
 misplaced.
 a quick search showed that the following references to the core package are 
 present:
 oak-solr:
 - AbstractRoot used by 
SolrBaseTest
 oak-jcr:
 - IdentifierManager used by 
NodeImpl, 
NodeDelegate, 
SessionDelegate, 
ChangeProcessor,
ImporterImpl
 - ImmutableRoot used by
ChangeProcessor
 - ImmutableTree used by
ChangeProcessor
 to me that indicates that the IdentifierManager should be moved to package
 space that is really public (API, SPI or plugins). 
 as far as the ChangeProcessor is concerned it seems that this was itself a
 candidate for being moved from oak-jcr to oak-core.
 and finally the SolrTest: i think the test should be refactored to obtain the 
 root from a regular OAK repository setup instead of relying on an specific 
 implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-950) Remove org.apache.jackrabbit.oak.core from package-export

2013-09-26 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13778528#comment-13778528
 ] 

angela commented on OAK-950:


if AbstractTree#getIdentifier is only used by the id manager, that would 
definitely be better.
let me check if that would work.

[~mduerig] what's your opinion regarding the observation classes? afaik you did 
most of the work there.
moving them was just an easy way out... but maybe some more refactoring would 
be required to
leave the jcr-event part in oak-jcr and just keep the reference to 
immutabletree/root in oak-core.


 Remove org.apache.jackrabbit.oak.core from package-export
 -

 Key: OAK-950
 URL: https://issues.apache.org/jira/browse/OAK-950
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
 Attachments: OAK-950.patch


 IMO the package org.apache.jackrabbit.oak.core is the implementation of the
 oak api and should therefore only be used internally. exporting that package
 in the maven-bundle-plugin configuration is from my point of view a major bug.
 if it's needed it indicates that the package contains classes that are 
 misplaced.
 a quick search showed that the following references to the core package are 
 present:
 oak-solr:
 - AbstractRoot used by 
SolrBaseTest
 oak-jcr:
 - IdentifierManager used by 
NodeImpl, 
NodeDelegate, 
SessionDelegate, 
ChangeProcessor,
ImporterImpl
 - ImmutableRoot used by
ChangeProcessor
 - ImmutableTree used by
ChangeProcessor
 to me that indicates that the IdentifierManager should be moved to package
 space that is really public (API, SPI or plugins). 
 as far as the ChangeProcessor is concerned it seems that this was itself a
 candidate for being moved from oak-jcr to oak-core.
 and finally the SolrTest: i think the test should be refactored to obtain the 
 root from a regular OAK repository setup instead of relying on an specific 
 implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-950) Remove org.apache.jackrabbit.oak.core from package-export

2013-09-26 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-950:
---

Attachment: OAK-950_2.patch

updated patch that removes AbstractTree#getIdentifier() as suggested by michael

 Remove org.apache.jackrabbit.oak.core from package-export
 -

 Key: OAK-950
 URL: https://issues.apache.org/jira/browse/OAK-950
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
 Attachments: OAK-950_2.patch, OAK-950.patch


 IMO the package org.apache.jackrabbit.oak.core is the implementation of the
 oak api and should therefore only be used internally. exporting that package
 in the maven-bundle-plugin configuration is from my point of view a major bug.
 if it's needed it indicates that the package contains classes that are 
 misplaced.
 a quick search showed that the following references to the core package are 
 present:
 oak-solr:
 - AbstractRoot used by 
SolrBaseTest
 oak-jcr:
 - IdentifierManager used by 
NodeImpl, 
NodeDelegate, 
SessionDelegate, 
ChangeProcessor,
ImporterImpl
 - ImmutableRoot used by
ChangeProcessor
 - ImmutableTree used by
ChangeProcessor
 to me that indicates that the IdentifierManager should be moved to package
 space that is really public (API, SPI or plugins). 
 as far as the ChangeProcessor is concerned it seems that this was itself a
 candidate for being moved from oak-jcr to oak-core.
 and finally the SolrTest: i think the test should be refactored to obtain the 
 root from a regular OAK repository setup instead of relying on an specific 
 implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-950) Remove org.apache.jackrabbit.oak.core from package-export

2013-09-26 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-950:
--

Assignee: angela

 Remove org.apache.jackrabbit.oak.core from package-export
 -

 Key: OAK-950
 URL: https://issues.apache.org/jira/browse/OAK-950
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Assignee: angela
 Attachments: OAK-950_2.patch, OAK-950.patch


 IMO the package org.apache.jackrabbit.oak.core is the implementation of the
 oak api and should therefore only be used internally. exporting that package
 in the maven-bundle-plugin configuration is from my point of view a major bug.
 if it's needed it indicates that the package contains classes that are 
 misplaced.
 a quick search showed that the following references to the core package are 
 present:
 oak-solr:
 - AbstractRoot used by 
SolrBaseTest
 oak-jcr:
 - IdentifierManager used by 
NodeImpl, 
NodeDelegate, 
SessionDelegate, 
ChangeProcessor,
ImporterImpl
 - ImmutableRoot used by
ChangeProcessor
 - ImmutableTree used by
ChangeProcessor
 to me that indicates that the IdentifierManager should be moved to package
 space that is really public (API, SPI or plugins). 
 as far as the ChangeProcessor is concerned it seems that this was itself a
 candidate for being moved from oak-jcr to oak-core.
 and finally the SolrTest: i think the test should be refactored to obtain the 
 root from a regular OAK repository setup instead of relying on an specific 
 implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OAK-1054) Folder containing an admin user should not be removed

2013-09-30 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1054.
-

Resolution: Fixed

thanks for reporting this issue and the test!

 Folder containing an admin user should not be removed
 -

 Key: OAK-1054
 URL: https://issues.apache.org/jira/browse/OAK-1054
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Antonio Sanso
Assignee: angela
 Attachments: OAK-1054-patch.txt


 The action of removing a folder that contains the admin user should fail.
 This is already the case if it is tried to remove the admin node .
 Attaching unit test



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1046) Faster anonymous read operations

2013-09-30 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781942#comment-13781942
 ] 

angela commented on OAK-1046:
-

hi tom

thanks for the patch. i am sure that we will need to add some sort of caching.
regarding the readstatus cache you propose this rather go into 
CompiledPermissionsImpl which also has the possibilty to detect if the cache is 
stale.

apart from that the readstatus calculation you mention is covered by OAK-774.

imo another possible way to improve performance of permission evaluation was to 
share evaluated permissions and maybe caches between sessions with the same 
principal set and the same state of the permission store.

 Faster anonymous read operations
 

 Key: OAK-1046
 URL: https://issues.apache.org/jira/browse/OAK-1046
 Project: Jackrabbit Oak
  Issue Type: Improvement
Reporter: Thomas Mueller
 Attachments: OAK-1046-test-1.patch


 The oak-run test GetNodeWithAnonymous is currently quite a bit slower than 
 GetNodeWithAdmin. According to my profiling data, the main bottleneck is 
 SecurityContext.getReadStatus, which calls PermissionProvider.getReadStatus 
 which calls CompiledPermissionImpl.getReadStatus.
 To improve performance, I tried caching the result of this call, using a 
 simple hash map, with a string key (tree.getPath() + property.getName()). 
 This improved performance to now:
 {code}
 java -Dwarmup=5 -Druntime=30 -jar target/oak-run-*.jar benchmark 
 GetNodeWithAnonymous Oak-Tar
 packages:
 39%: org.apache.jackrabbit.oak.plugins.segment
 23%: org.apache.jackrabbit.oak.core
 14%: org.apache.jackrabbit.oak.plugins.memory
 6%: org.apache.jackrabbit.oak.namepath
 4%: com.google.common.collect
 4%: org.apache.jackrabbit.oak.jcr.session
 3%: org.apache.jackrabbit.oak.util
 .
 Oak-Tar  142 144 146 148 218 203
 java -Dwarmup=5 -Druntime=30 -jar target/oak-run-*.jar benchmark 
 GetNodeWithAdmin Oak-Tar
 packages:
 29%: org.apache.jackrabbit.oak.plugins.segment
 17%: org.apache.jackrabbit.oak.plugins.memory
 17%: org.apache.jackrabbit.oak.namepath
 12%: org.apache.jackrabbit.oak.jcr.session
 8%: org.apache.jackrabbit.oak.util
 5%: org.apache.jackrabbit.oak.core
 4%: org.apache.jackrabbit.oak.plugins.segment.file
 .
 Oak-Tar   35  35  36  37  73 818
 {code}
 So it is still about 4 times slower, but it's an improvement (currently it is 
 10 times slower).
 I wonder if there is a better way. I'm don't think caching the ReadStatus on 
 a property or node level is very memory efficient, but maybe other solutions 
 would be very hard to implement.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-1046) Faster anonymous read operations

2013-09-30 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1046:


Issue Type: Sub-task  (was: Improvement)
Parent: OAK-527

 Faster anonymous read operations
 

 Key: OAK-1046
 URL: https://issues.apache.org/jira/browse/OAK-1046
 Project: Jackrabbit Oak
  Issue Type: Sub-task
Reporter: Thomas Mueller
 Attachments: OAK-1046-test-1.patch


 The oak-run test GetNodeWithAnonymous is currently quite a bit slower than 
 GetNodeWithAdmin. According to my profiling data, the main bottleneck is 
 SecurityContext.getReadStatus, which calls PermissionProvider.getReadStatus 
 which calls CompiledPermissionImpl.getReadStatus.
 To improve performance, I tried caching the result of this call, using a 
 simple hash map, with a string key (tree.getPath() + property.getName()). 
 This improved performance to now:
 {code}
 java -Dwarmup=5 -Druntime=30 -jar target/oak-run-*.jar benchmark 
 GetNodeWithAnonymous Oak-Tar
 packages:
 39%: org.apache.jackrabbit.oak.plugins.segment
 23%: org.apache.jackrabbit.oak.core
 14%: org.apache.jackrabbit.oak.plugins.memory
 6%: org.apache.jackrabbit.oak.namepath
 4%: com.google.common.collect
 4%: org.apache.jackrabbit.oak.jcr.session
 3%: org.apache.jackrabbit.oak.util
 .
 Oak-Tar  142 144 146 148 218 203
 java -Dwarmup=5 -Druntime=30 -jar target/oak-run-*.jar benchmark 
 GetNodeWithAdmin Oak-Tar
 packages:
 29%: org.apache.jackrabbit.oak.plugins.segment
 17%: org.apache.jackrabbit.oak.plugins.memory
 17%: org.apache.jackrabbit.oak.namepath
 12%: org.apache.jackrabbit.oak.jcr.session
 8%: org.apache.jackrabbit.oak.util
 5%: org.apache.jackrabbit.oak.core
 4%: org.apache.jackrabbit.oak.plugins.segment.file
 .
 Oak-Tar   35  35  36  37  73 818
 {code}
 So it is still about 4 times slower, but it's an improvement (currently it is 
 10 times slower).
 I wonder if there is a better way. I'm don't think caching the ReadStatus on 
 a property or node level is very memory efficient, but maybe other solutions 
 would be very hard to implement.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-950) Remove org.apache.jackrabbit.oak.core from package-export

2013-09-30 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-950.


Resolution: Fixed

 Remove org.apache.jackrabbit.oak.core from package-export
 -

 Key: OAK-950
 URL: https://issues.apache.org/jira/browse/OAK-950
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Assignee: angela
 Attachments: OAK-950_2.patch, OAK-950_3.patch, OAK-950.patch


 IMO the package org.apache.jackrabbit.oak.core is the implementation of the
 oak api and should therefore only be used internally. exporting that package
 in the maven-bundle-plugin configuration is from my point of view a major bug.
 if it's needed it indicates that the package contains classes that are 
 misplaced.
 a quick search showed that the following references to the core package are 
 present:
 oak-solr:
 - AbstractRoot used by 
SolrBaseTest
 oak-jcr:
 - IdentifierManager used by 
NodeImpl, 
NodeDelegate, 
SessionDelegate, 
ChangeProcessor,
ImporterImpl
 - ImmutableRoot used by
ChangeProcessor
 - ImmutableTree used by
ChangeProcessor
 to me that indicates that the IdentifierManager should be moved to package
 space that is really public (API, SPI or plugins). 
 as far as the ChangeProcessor is concerned it seems that this was itself a
 candidate for being moved from oak-jcr to oak-core.
 and finally the SolrTest: i think the test should be refactored to obtain the 
 root from a regular OAK repository setup instead of relying on an specific 
 implementation.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1058) Review TreeTypeProvider

2013-10-01 Thread angela (JIRA)

angela created OAK-1058:
---

 Summary: Review TreeTypeProvider
 Key: OAK-1058
 URL: https://issues.apache.org/jira/browse/OAK-1058
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela
Priority: Minor


reminder to review and possibly refactor the tree type provider. this part of 
the core-package is still marked with TODOs and we should clean it up before 
releasing oak.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1064) UnsupportedRepositoryOperationException for UserManager#autoSave

2013-10-02 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784053#comment-13784053
 ] 

angela commented on OAK-1064:
-

right, this behaviour has changed basically because IMO the autosave stuff 
should be deprecated altogether :-)
we can implement this if it turns out to be a problem if it's not there... but 
i would prefer if would could do without.

see OAK-791 for a comprehensive description of what has changed in the user 
management.

 UnsupportedRepositoryOperationException for UserManager#autoSave
 

 Key: OAK-1064
 URL: https://issues.apache.org/jira/browse/OAK-1064
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: Antonio Sanso

 UserManager#autoSave throws always UnsupportedRepositoryOperationException 
 this differs from JR2 where this operation is supported and the autoSave is 
 set to true by default



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2

2013-10-03 Thread angela (JIRA)

[
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] [Assigned] (OAK-1073) PrivilegeManager#getPrivilege throws RepositoryException rather than AccessControlException

2013-10-03 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1073:
---

Assignee: angela

 PrivilegeManager#getPrivilege throws RepositoryException rather than 
 AccessControlException
 ---

 Key: OAK-1073
 URL: https://issues.apache.org/jira/browse/OAK-1073
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Antonio Sanso
Assignee: angela
 Attachments: OAK-1073-patch.txt, OAK-1073-test-patch.txt


 PrivilegeManager#getPrivilege throws RepositoryException rather than 
 AccessControlException.
 Throwing AccessControlException would be better since it is compatible with 
 JR.
 Test and patch to follow



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-1073) PrivilegeManager#getPrivilege throws RepositoryException rather than AccessControlException

2013-10-03 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1073.
-

Resolution: Fixed

thanks antonio for spotting this issue.

 PrivilegeManager#getPrivilege throws RepositoryException rather than 
 AccessControlException
 ---

 Key: OAK-1073
 URL: https://issues.apache.org/jira/browse/OAK-1073
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Antonio Sanso
Assignee: angela
 Attachments: OAK-1073-patch.txt, OAK-1073-test-patch.txt


 PrivilegeManager#getPrivilege throws RepositoryException rather than 
 AccessControlException.
 Throwing AccessControlException would be better since it is compatible with 
 JR.
 Test and patch to follow



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-1002) JackrabbitAccessControlList.addEntry() throws NoSuchMethodError

2013-10-03 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1002:


Summary: JackrabbitAccessControlList.addEntry() throws NoSuchMethodError  
(was: JackrabbitAccessControlList.addEntry() thwos NoSuchMethodError)

 JackrabbitAccessControlList.addEntry() throws NoSuchMethodError
 ---

 Key: OAK-1002
 URL: https://issues.apache.org/jira/browse/OAK-1002
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: security
Affects Versions: 0.8
Reporter: Christan Keller
Assignee: angela

 Trying to add an Entry to an Acl throws a NoSuchMethodError.
 I have guava 14.0.1 in my classpath
 {noformat}
 java.lang.NoSuchMethodError: 
 com.google.common.collect.Maps.valueIterator(Lcom/google/common/collect/UnmodifiableIterator;)Lcom/google/common/collect/UnmodifiableIterator;
   at 
 com.google.common.collect.ImmutableMapValues.iterator(ImmutableMapValues.java:46)
   at 
 com.google.common.collect.ImmutableMapValues.iterator(ImmutableMapValues.java:31)
   at 
 com.google.common.collect.ObjectArrays.fillArray(ObjectArrays.java:172)
   at 
 com.google.common.collect.ObjectArrays.toArrayImpl(ObjectArrays.java:167)
   at 
 com.google.common.collect.ImmutableCollection.toArray(ImmutableCollection.java:58)
   at 
 com.google.common.collect.ImmutableSet.copyFromCollection(ImmutableSet.java:381)
   at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:376)
   at 
 org.apache.jackrabbit.oak.spi.security.authorization.restriction.AbstractRestrictionProvider.getSupportedRestrictions(AbstractRestrictionProvider.java:59)
   at 
 org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL.addEntry(ACL.java:104)
   at 
 org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlList.addEntry(AbstractAccessControlList.java:132)
   at com.day.cq.wcm.msm.impl.Issue.testNoSuchMethodError(Issue.java:31)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
   at 
 com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
 {noformat}
 Stepps to reproduce
 {code}
 @Test
 public void testNoSuchMethodError() throws RepositoryException {
 Repository repo = new Jcr().createRepository();
 Session admin = repo.login(new SimpleCredentials(admin, 
 admin.toCharArray()), null);
 Node node = admin.getRootNode().addNode(lala, 
 JcrConstants.NT_UNSTRUCTURED);
 admin.save();
 Principal adminPrincipal = ((JackrabbitSession) 
 admin).getPrincipalManager().getPrincipal(admin);
 JackrabbitAccessControlList acl

[jira] [Comment Edited] (OAK-1064) UnsupportedRepositoryOperationException for UserManager#autoSave

2013-10-03 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13785237#comment-13785237
 ] 

angela edited comment on OAK-1064 at 10/3/13 2:32 PM:
--

part of OAK-791


was (Author: anchela):
duplicate of OAK-791

 UnsupportedRepositoryOperationException for UserManager#autoSave
 

 Key: OAK-1064
 URL: https://issues.apache.org/jira/browse/OAK-1064
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: Antonio Sanso

 UserManager#autoSave throws always UnsupportedRepositoryOperationException 
 this differs from JR2 where this operation is supported and the autoSave is 
 set to true by default



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-1064) UnsupportedRepositoryOperationException for UserManager#autoSave

2013-10-03 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1064.
-

Resolution: Duplicate

duplicate of OAK-791

 UnsupportedRepositoryOperationException for UserManager#autoSave
 

 Key: OAK-1064
 URL: https://issues.apache.org/jira/browse/OAK-1064
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: Antonio Sanso

 UserManager#autoSave throws always UnsupportedRepositoryOperationException 
 this differs from JR2 where this operation is supported and the autoSave is 
 set to true by default



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2

2013-10-03 Thread angela (JIRA)

[
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 current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:

h5. General

h5. User/Group creation

h5. Handling of the Authorizable ID

h5. Equals and HashCode for Authorizables

h5. The 'everyone' Group

_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:

h5. Group Membership

_TODO_ (see OAK-482)

h4. 2. Builtin Users

h5. Administrator user

[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2

2013-10-03 Thread angela (JIRA)

[
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 current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:

h5. General

h5. User/Group creation

h5. Handling of the Authorizable ID

h5. Equals and HashCode for Authorizables

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:

h5. Group Membership

_TODO_ (see OAK-482)

h4. 2. Builtin Users

h5. Administrator user

[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2

2013-10-03 Thread angela (JIRA)

[
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 current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:

h5. General

h5. User/Group creation

h5. Handling of the Authorizable ID

h5. Equals and HashCode for Authorizables

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:

h5. Group Membership

_TODO_ (see OAK-482)

h4. 2. Builtin Users

h5. Administrator user

[jira] [Commented] (OAK-1081) Node.getNodes throwing exception if user does not have access to any child node

2013-10-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789380#comment-13789380
 ] 

angela commented on OAK-1081:
-

i don't think that any special filtering should be performed for the access 
control content such as e.g. rep:policy nodes. but as far as i can see, you 
didn't incorporate this into the patch, right?

testing for Tree#exists in the NodeDelegate looks ok to me...

 Node.getNodes throwing exception if user does not have access to any child 
 node
 ---

 Key: OAK-1081
 URL: https://issues.apache.org/jira/browse/OAK-1081
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, security
Affects Versions: 0.9
Reporter: Chetan Mehrotra
Assignee: angela
Priority: Minor
 Attachments: OAK-1081-fix.patch, OAK-1081-testcase.patch


 When trying to obtain child iterator via Node.getNodes 
 {{InvalidItemStateException}} is thrown if user does not have access to its 
 content
 {code:java}
 @Test
 public void testGetChildren() throws Exception {
 deny(path, 
 privilegesFromName(PrivilegeConstants.JCR_ADD_CHILD_NODES));
 NodeIterator it1 = testSession.getNode(path).getNodes();
 while(it1.hasNext()){
 Node n = it1.nextNode();
 NodeIterator it2 = n.getNodes();
 }
 }
 {code}
 Executing above code leads to following exception
 {noformat}
 javax.jcr.InvalidItemStateException: Item is stale
   at 
 org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.getTree(NodeDelegate.java:827)
   at 
 org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.getChildren(NodeDelegate.java:336)
   at 
 org.apache.jackrabbit.oak.jcr.session.NodeImpl$8.perform(NodeImpl.java:546)
   at 
 org.apache.jackrabbit.oak.jcr.session.NodeImpl$8.perform(NodeImpl.java:543)
   at 
 org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:125)
   at 
 org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:113)
   at 
 org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNodes(NodeImpl.java:543)
   at 
 org.apache.jackrabbit.oak.jcr.security.authorization.ReadPropertyTest.testGetChildren(ReadPropertyTest.java:135)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
   at 
 org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
   at 
 com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
   at 
 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
 {noformat}
 The exception is thrown for path {{/testroot/node1/rep:policy}}. 
 The issue occurs because the {{NodeIterator}} {{it1}} includes {{rep:policy}} 
 and later when its child are accessed security check leads to exception. 
 Probably the {{it1}} should not include {{rep:policy}} as part of child list 
 and filter it out



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-1091) TokenLoginModule#commit should throw an exception if TokenInfo is not created

2013-10-10 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1091.
-

Resolution: Fixed

fix committed revision 1530963.

 TokenLoginModule#commit should throw an exception if TokenInfo is not created
 -

 Key: OAK-1091
 URL: https://issues.apache.org/jira/browse/OAK-1091
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Antonio Sanso
Assignee: angela

 TokenLoginModule#commit should throw an exception if TokenInfo is not created
 {code}
 if (ti != null) {
 TokenCredentials tc = new TokenCredentials(ti.getToken());
 MapString, String attributes = 
 ti.getPrivateAttributes();
 for (String name : attributes.keySet()) {
 tc.setAttribute(name, attributes.get(name));
 }
 attributes = ti.getPublicAttributes();
 for (String name : attributes.keySet()) {
 tc.setAttribute(name, attributes.get(name));
 }
 subject.getPublicCredentials().add(tc);
 }
 {code}
 the code above should contain an else statement throwing  a LoginException



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1095) versionable path property has wrong type

2013-10-14 Thread angela (JIRA)

angela created OAK-1095:
---

 Summary: versionable path property has wrong type
 Key: OAK-1095
 URL: https://issues.apache.org/jira/browse/OAK-1095
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela


the versionablepath hook doesn't set the type of the versionable path property 
to PATH causing access to that property fail in JCR due to constraintviolation.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (OAK-1097) VersionablePathHook ignores modified version histories

2013-10-15 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1097:
---

Assignee: angela

 VersionablePathHook ignores modified version histories
 

 Key: OAK-1097
 URL: https://issues.apache.org/jira/browse/OAK-1097
 Project: Jackrabbit Oak
  Issue Type: Bug
Reporter: angela
Assignee: angela

 see http://markmail.org/message/ipkxtc73sgdge4ob for a detailed description 
 and a general discussion on this type of issues.
 in order to address this concrete incident, we can work around it by not only 
 listening to added jcr:versionHistory properties but also to it's 
 modification, which IMO looks quite odd as the jcr:versionHistory reference 
 is a protected, mandatory and autocreated property which will never be 
 modified.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1098) AuthorizableImpl methods should convert path to Oak path

2013-10-15 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795248#comment-13795248
 ] 

angela commented on OAK-1098:
-

that's definitely a bug... similarly UserManager#getAuthorizableByPath and 
Authorizable#getPath should do the conversion accordingly. 

 AuthorizableImpl methods should convert path to Oak path
 

 Key: OAK-1098
 URL: https://issues.apache.org/jira/browse/OAK-1098
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Michael Dürig
Assignee: angela

 The methods on {{AuthorizableImpl}} that take a path as an argument all pass 
 that on without converting it to an oak path. I think this is wrong. If not 
 on this layer probably further below.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (OAK-1098) AuthorizableImpl methods should convert path to Oak path

2013-10-15 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1098:
---

Assignee: angela

 AuthorizableImpl methods should convert path to Oak path
 

 Key: OAK-1098
 URL: https://issues.apache.org/jira/browse/OAK-1098
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Michael Dürig
Assignee: angela

 The methods on {{AuthorizableImpl}} that take a path as an argument all pass 
 that on without converting it to an oak path. I think this is wrong. If not 
 on this layer probably further below.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1106) Query engine does not deal with remapped namespaces

2013-10-22 Thread angela (JIRA)

angela created OAK-1106:
---

 Summary: Query engine does not deal with remapped namespaces
 Key: OAK-1106
 URL: https://issues.apache.org/jira/browse/OAK-1106
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela


while trying to resolve the query related part of OAK-1098 i realized that the 
NamePathMapper passed to QueryEngine#executeQuery isn't used to convert jcr 
names/paths that are passed as part of the query statement.

as far as i can see this affects 
- path included in the statement
- property name(s)
- values

i tried to convert my user-mgt related tests to simple query test on the JCR 
level to illustrate the issue.




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123
 ] 

angela commented on OAK-482:


thomas suggest another alternative: instead of having multivalued rep:members 
properties underneath the member nodes we might also consider having 
non-residual single valued properties (e.g. rep:member). the drawback is that 
there would be a node for every member property. 

 Group members stored in a rep:members tree
 --

 Key: OAK-482
 URL: https://issues.apache.org/jira/browse/OAK-482
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela

 storing group members in a dedicated rep:members tree is currently not
 yet implemented.
 - jr 2.x node type definition allows SNS which are not supported in oak
 - jr 2.x node type definition stores members in residual properties, which
   up to now doesn't allow to use a specific property index.
 - the jr 2.x implementation is rather cumbersome as it doesn't allow
   to change the configuration later on such that existing groups can
   benefit from the config change.
 - the node names in the tree structure would rely on userId being equal
   to the principal name, which is not mandated.
 for a new implementation in oak i see the following variants to provide this
 feature:
 h6. variant 1: 
 - drop SNS
 - change member-property to a multivalue rep:members property in the
   node hierarchy - same index as for non-tree implementation
 - config change will result in the member-tree to be created also for
   existing groups.
 - even if member-tree option is enabled the members are stored in the
   default mv property and just have a tree structured added if required
   based on the config option.
 - adjust xml import of user content accordingly
 pros:
 - dedicated property index for rep:members property defined by rep:Members
   works out of the box - performance of membership lookup.
 - fixing SNS definition
 - fixing confusion of uid with principalname
 cons:
 - not backwards compatible out of the box
 - updating membership might not be efficient
 - we need to add backwards compatible behavior when reading and querying 
   existing membership information or provide an upgrade path that converts
   'old' structure to the new one upon repo upgrade
 h6. variant 2:
 - rebuild use same logic as in JR2.x to build tree structure but include
   fixing the principalName/uid issue.
 pros:
 - backwards compatible (no upgrade path required)
 - most probably changing membership of a group was more efficient
 cons:
 - efficient lookup of membership doesn't work (AFAIK the property index is 
 limited
   to named properties). thus we probably need to adjust the query/index logic 
 such that
   a property index can be created for residual properties defined by the 
 rep:Members node type
 - SNS problem not addressed - might cause failure upon upgrade



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-482:
---

Assignee: Tobias Bocanegra

 Group members stored in a rep:members tree
 --

 Key: OAK-482
 URL: https://issues.apache.org/jira/browse/OAK-482
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Assignee: Tobias Bocanegra

 storing group members in a dedicated rep:members tree is currently not
 yet implemented.
 - jr 2.x node type definition allows SNS which are not supported in oak
 - jr 2.x node type definition stores members in residual properties, which
   up to now doesn't allow to use a specific property index.
 - the jr 2.x implementation is rather cumbersome as it doesn't allow
   to change the configuration later on such that existing groups can
   benefit from the config change.
 - the node names in the tree structure would rely on userId being equal
   to the principal name, which is not mandated.
 for a new implementation in oak i see the following variants to provide this
 feature:
 h6. variant 1: 
 - drop SNS
 - change member-property to a multivalue rep:members property in the
   node hierarchy - same index as for non-tree implementation
 - config change will result in the member-tree to be created also for
   existing groups.
 - even if member-tree option is enabled the members are stored in the
   default mv property and just have a tree structured added if required
   based on the config option.
 - adjust xml import of user content accordingly
 pros:
 - dedicated property index for rep:members property defined by rep:Members
   works out of the box - performance of membership lookup.
 - fixing SNS definition
 - fixing confusion of uid with principalname
 cons:
 - not backwards compatible out of the box
 - updating membership might not be efficient
 - we need to add backwards compatible behavior when reading and querying 
   existing membership information or provide an upgrade path that converts
   'old' structure to the new one upon repo upgrade
 h6. variant 2:
 - rebuild use same logic as in JR2.x to build tree structure but include
   fixing the principalName/uid issue.
 pros:
 - backwards compatible (no upgrade path required)
 - most probably changing membership of a group was more efficient
 cons:
 - efficient lookup of membership doesn't work (AFAIK the property index is 
 limited
   to named properties). thus we probably need to adjust the query/index logic 
 such that
   a property index can be created for residual properties defined by the 
 rep:Members node type
 - SNS problem not addressed - might cause failure upon upgrade



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803129#comment-13803129
 ] 

angela commented on OAK-482:


[~tri...@apache.org]: assigning to you as discussed.

 Group members stored in a rep:members tree
 --

 Key: OAK-482
 URL: https://issues.apache.org/jira/browse/OAK-482
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Assignee: Tobias Bocanegra

 storing group members in a dedicated rep:members tree is currently not
 yet implemented.
 - jr 2.x node type definition allows SNS which are not supported in oak
 - jr 2.x node type definition stores members in residual properties, which
   up to now doesn't allow to use a specific property index.
 - the jr 2.x implementation is rather cumbersome as it doesn't allow
   to change the configuration later on such that existing groups can
   benefit from the config change.
 - the node names in the tree structure would rely on userId being equal
   to the principal name, which is not mandated.
 for a new implementation in oak i see the following variants to provide this
 feature:
 h6. variant 1: 
 - drop SNS
 - change member-property to a multivalue rep:members property in the
   node hierarchy - same index as for non-tree implementation
 - config change will result in the member-tree to be created also for
   existing groups.
 - even if member-tree option is enabled the members are stored in the
   default mv property and just have a tree structured added if required
   based on the config option.
 - adjust xml import of user content accordingly
 pros:
 - dedicated property index for rep:members property defined by rep:Members
   works out of the box - performance of membership lookup.
 - fixing SNS definition
 - fixing confusion of uid with principalname
 cons:
 - not backwards compatible out of the box
 - updating membership might not be efficient
 - we need to add backwards compatible behavior when reading and querying 
   existing membership information or provide an upgrade path that converts
   'old' structure to the new one upon repo upgrade
 h6. variant 2:
 - rebuild use same logic as in JR2.x to build tree structure but include
   fixing the principalName/uid issue.
 pros:
 - backwards compatible (no upgrade path required)
 - most probably changing membership of a group was more efficient
 cons:
 - efficient lookup of membership doesn't work (AFAIK the property index is 
 limited
   to named properties). thus we probably need to adjust the query/index logic 
 such that
   a property index can be created for residual properties defined by the 
 rep:Members node type
 - SNS problem not addressed - might cause failure upon upgrade



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123
]

angela edited comment on OAK-482 at 10/23/13 6:41 PM:
--

thomas suggest another alternative:

h6. variant 3:
instead of having multivalued rep:members properties underneath the member
nodes we might also consider having non-residual single valued properties (e.g.
rep:member). the drawback is that there would be a node for every member
property.
apart from that same applies as for variant 2.

was (Author: anchela):
thomas suggest another alternative:

Group members stored in a rep:members tree
--

Key: OAK-482
URL: https://issues.apache.org/jira/browse/OAK-482
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core
Reporter: angela

storing group members in a dedicated rep:members tree is currently not
yet implemented.
- jr 2.x node type definition allows SNS which are not supported in oak
- jr 2.x node type definition stores members in residual properties, which
up to now doesn't allow to use a specific property index.
- the jr 2.x implementation is rather cumbersome as it doesn't allow
to change the configuration later on such that existing groups can
benefit from the config change.
- the node names in the tree structure would rely on userId being equal
to the principal name, which is not mandated.
for a new implementation in oak i see the following variants to provide this
feature:
h6. variant 1:
- drop SNS
- change member-property to a multivalue rep:members property in the
node hierarchy - same index as for non-tree implementation
- config change will result in the member-tree to be created also for
existing groups.
- even if member-tree option is enabled the members are stored in the
default mv property and just have a tree structured added if required
based on the config option.
- adjust xml import of user content accordingly
pros:
- dedicated property index for rep:members property defined by rep:Members
works out of the box - performance of membership lookup.
- fixing SNS definition
- fixing confusion of uid with principalname
cons:
- not backwards compatible out of the box
- updating membership might not be efficient
- we need to add backwards compatible behavior when reading and querying
existing membership information or provide an upgrade path that converts
'old' structure to the new one upon repo upgrade
h6. variant 2:
- rebuild use same logic as in JR2.x to build tree structure but include
fixing the principalName/uid issue.
pros:
- backwards compatible (no upgrade path required)
- most probably changing membership of a group was more efficient
cons:
- efficient lookup of membership doesn't work (AFAIK the property index is
limited
to named properties). thus we probably need to adjust the query/index logic
such that
a property index can be created for residual properties defined by the
rep:Members node type
- SNS problem not addressed - might cause failure upon upgrade

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123
]

angela edited comment on OAK-482 at 10/23/13 6:41 PM:
--

thomas suggest another alternative:

was (Author: anchela):
thomas suggest another alternative: instead of having multivalued rep:members
properties underneath the member nodes we might also consider having
non-residual single valued properties (e.g. rep:member). the drawback is that
there would be a node for every member property.

Group members stored in a rep:members tree
--

Key: OAK-482
URL: https://issues.apache.org/jira/browse/OAK-482
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core
Reporter: angela

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)

angela created OAK-1115:
---

 Summary: Remove of Subtree after Move is not subjected to 
permission validation
 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Critical


the following test passes in Jackrabbit-Core but fails in OAK:

{code}
@Test
public void testMoveRemoveSubTree() throws Exception {
superuser.getNode(childNPath).addNode(nodeName3);
superuser.save();

/* allow READ/WRITE privilege for testUser at 'path' */
givePrivileges(path, privilegesFromNames(new String[] 
{Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
/* deny READ/REMOVE property privileges at subtree. */
withdrawPrivileges(path, privilegesFromNames(new String[] 
{Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
superuser.getValueFactory().createValue(*/+nodeName3)));

Session testSession = getTestSession();
assertTrue(testSession.nodeExists(childNPath));
assertTrue(testSession.hasPermission(childNPath, 
Session.ACTION_REMOVE));
assertTrue(testSession.hasPermission(childNPath2, 
Session.ACTION_ADD_NODE));

testSession.move(childNPath, childNPath2 + /dest);
Node dest = testSession.getNode(childNPath2 + /dest);
dest.getNode(nodeName3).remove();

try {
testSession.save();
fail(Removing child node must be denied.);
} catch (AccessDeniedException e) {
// success
}
}
{code}

this is a critical security issue as it moving around the parent is sufficient 
in order to be able to remove a node that was otherwise not removable due to 
limited permissions.

Afaik this behavior is caused by a limitation in the Diff process which doesn't 
allow to identify the move and thus makes it impossible to find out if that the 
subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804182#comment-13804182
 ] 

angela commented on OAK-1115:
-

well, i don't see it... as the move is perfectly valid and there was no removal 
at all except for the subtree.
as soon as a node was really removed the validator checks if that node can be 
removed but doesn't check for all the child nodes which makes sense IMO.

in other words: i don't see how i can find out that the only tree that was 
really removed was actually the subtree and not the one that is being reported 
(but which was associated with the move and which has been removed at all)?

 Remove of Subtree after Move is not subjected to permission validation
 --

 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Critical

 the following test passes in Jackrabbit-Core but fails in OAK:
 {code}
 @Test
 public void testMoveRemoveSubTree() throws Exception {
 superuser.getNode(childNPath).addNode(nodeName3);
 superuser.save();
 /* allow READ/WRITE privilege for testUser at 'path' */
 givePrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
 /* deny READ/REMOVE property privileges at subtree. */
 withdrawPrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
 superuser.getValueFactory().createValue(*/+nodeName3)));
 Session testSession = getTestSession();
 assertTrue(testSession.nodeExists(childNPath));
 assertTrue(testSession.hasPermission(childNPath, 
 Session.ACTION_REMOVE));
 assertTrue(testSession.hasPermission(childNPath2, 
 Session.ACTION_ADD_NODE));
 testSession.move(childNPath, childNPath2 + /dest);
 Node dest = testSession.getNode(childNPath2 + /dest);
 dest.getNode(nodeName3).remove();
 try {
 testSession.save();
 fail(Removing child node must be denied.);
 } catch (AccessDeniedException e) {
 // success
 }
 }
 {code}
 this is a critical security issue as it moving around the parent is 
 sufficient in order to be able to remove a node that was otherwise not 
 removable due to limited permissions.
 Afaik this behavior is caused by a limitation in the Diff process which 
 doesn't allow to identify the move and thus makes it impossible to find out 
 if that the subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804182#comment-13804182
 ] 

angela edited comment on OAK-1115 at 10/24/13 1:43 PM:
---

well, i don't see it... as the move is perfectly valid and there was no removal 
at all except for the subtree.
as soon as a node was really removed the validator checks if that node can be 
removed but doesn't check for all the child nodes which makes sense IMO.

in other words: i don't see how i can find out that the only tree that was 
really removed was actually the subtree and not the one that is being reported 
(but which was associated with the move and which hasn't been removed at all)?

if i was able to detect that the removeNode is in fact triggered by a move i 
would walk down and verify that the subtree hasn't been modified (neither add 
nor removal)


was (Author: anchela):
well, i don't see it... as the move is perfectly valid and there was no removal 
at all except for the subtree.
as soon as a node was really removed the validator checks if that node can be 
removed but doesn't check for all the child nodes which makes sense IMO.

in other words: i don't see how i can find out that the only tree that was 
really removed was actually the subtree and not the one that is being reported 
(but which was associated with the move and which has been removed at all)?

 Remove of Subtree after Move is not subjected to permission validation
 --

 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Critical

 the following test passes in Jackrabbit-Core but fails in OAK:
 {code}
 @Test
 public void testMoveRemoveSubTree() throws Exception {
 superuser.getNode(childNPath).addNode(nodeName3);
 superuser.save();
 /* allow READ/WRITE privilege for testUser at 'path' */
 givePrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
 /* deny READ/REMOVE property privileges at subtree. */
 withdrawPrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
 superuser.getValueFactory().createValue(*/+nodeName3)));
 Session testSession = getTestSession();
 assertTrue(testSession.nodeExists(childNPath));
 assertTrue(testSession.hasPermission(childNPath, 
 Session.ACTION_REMOVE));
 assertTrue(testSession.hasPermission(childNPath2, 
 Session.ACTION_ADD_NODE));
 testSession.move(childNPath, childNPath2 + /dest);
 Node dest = testSession.getNode(childNPath2 + /dest);
 dest.getNode(nodeName3).remove();
 try {
 testSession.save();
 fail(Removing child node must be denied.);
 } catch (AccessDeniedException e) {
 // success
 }
 }
 {code}
 this is a critical security issue as it moving around the parent is 
 sufficient in order to be able to remove a node that was otherwise not 
 removable due to limited permissions.
 Afaik this behavior is caused by a limitation in the Diff process which 
 doesn't allow to identify the move and thus makes it impossible to find out 
 if that the subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-783) Reflect Move and Rename upon Root#commit

2013-10-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804204#comment-13804204
 ] 

angela commented on OAK-783:


cool... thanks for the effort. very much appreciated. 
i will use it in the permission validator and can also add more permission 
related tests to see/demonstrate how big the impact of the limitations will be 
in that area.

 Reflect Move and Rename upon Root#commit
 

 Key: OAK-783
 URL: https://issues.apache.org/jira/browse/OAK-783
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela

 right now rename and move operations cannot be identified during 
 commit processing in validators or commit hooks.
 for proper (and backwards compatible) permission evaluation however
 we need the ability to distinguish between moving a node around or
 having nodes + properties being removed and added.
 during the last oakathon michael and myself had a discussion regarding
 that issue and michael convinced me that this can't be achieved by simply
 passing the move information contained in RootImpl to the commit hook.
 therefore creating this issue to track progress and discussions regarding
 move and renaming.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804226#comment-13804226
 ] 

angela commented on OAK-1115:
-

 I think it's important that the remove permissions are evaluated for the 
 entire subtree instead of just the parent.

well, the last time we discussed this, you said that it's seems better to just 
enforce the remove permission for the remove target, didn't you? apart from 
that we will not be able to enforce remove permissions on the entire subtree 
for backwards compatibility reasons. an example: if you don't have permissions 
to read/edit AC content in a given subtree but you are allowed to remove the 
root of that subtree, you could remove that tree in jr2 irrespective of any 
kind of ac content being present in the subtree... that's something that used 
to cause troubles in the beginning when we introduced access control in jr2.

 Remove of Subtree after Move is not subjected to permission validation
 --

 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Critical

 the following test passes in Jackrabbit-Core but fails in OAK:
 {code}
 @Test
 public void testMoveRemoveSubTree() throws Exception {
 superuser.getNode(childNPath).addNode(nodeName3);
 superuser.save();
 /* allow READ/WRITE privilege for testUser at 'path' */
 givePrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
 /* deny READ/REMOVE property privileges at subtree. */
 withdrawPrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
 superuser.getValueFactory().createValue(*/+nodeName3)));
 Session testSession = getTestSession();
 assertTrue(testSession.nodeExists(childNPath));
 assertTrue(testSession.hasPermission(childNPath, 
 Session.ACTION_REMOVE));
 assertTrue(testSession.hasPermission(childNPath2, 
 Session.ACTION_ADD_NODE));
 testSession.move(childNPath, childNPath2 + /dest);
 Node dest = testSession.getNode(childNPath2 + /dest);
 dest.getNode(nodeName3).remove();
 try {
 testSession.save();
 fail(Removing child node must be denied.);
 } catch (AccessDeniedException e) {
 // success
 }
 }
 {code}
 this is a critical security issue as it moving around the parent is 
 sufficient in order to be able to remove a node that was otherwise not 
 removable due to limited permissions.
 Afaik this behavior is caused by a limitation in the Diff process which 
 doesn't allow to identify the move and thus makes it impossible to find out 
 if that the subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reassigned OAK-1115:
---

Assignee: angela

 Remove of Subtree after Move is not subjected to permission validation
 --

 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Assignee: angela
Priority: Critical

 the following test passes in Jackrabbit-Core but fails in OAK:
 {code}
 @Test
 public void testMoveRemoveSubTree() throws Exception {
 superuser.getNode(childNPath).addNode(nodeName3);
 superuser.save();
 /* allow READ/WRITE privilege for testUser at 'path' */
 givePrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
 /* deny READ/REMOVE property privileges at subtree. */
 withdrawPrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
 superuser.getValueFactory().createValue(*/+nodeName3)));
 Session testSession = getTestSession();
 assertTrue(testSession.nodeExists(childNPath));
 assertTrue(testSession.hasPermission(childNPath, 
 Session.ACTION_REMOVE));
 assertTrue(testSession.hasPermission(childNPath2, 
 Session.ACTION_ADD_NODE));
 testSession.move(childNPath, childNPath2 + /dest);
 Node dest = testSession.getNode(childNPath2 + /dest);
 dest.getNode(nodeName3).remove();
 try {
 testSession.save();
 fail(Removing child node must be denied.);
 } catch (AccessDeniedException e) {
 // success
 }
 }
 {code}
 this is a critical security issue as it moving around the parent is 
 sufficient in order to be able to remove a node that was otherwise not 
 removable due to limited permissions.
 Afaik this behavior is caused by a limitation in the Diff process which 
 doesn't allow to identify the move and thus makes it impossible to find out 
 if that the subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-1115) Remove of Subtree after Move is not subjected to permission validation

2013-10-24 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804226#comment-13804226
 ] 

angela edited comment on OAK-1115 at 10/24/13 2:14 PM:
---

 I think it's important that the remove permissions are evaluated for the 
 entire subtree instead of just the parent.

well, the last time we discussed this, you said that it's seems better to just 
enforce the remove permission for the remove target, didn't you? apart from 
that we will not be able to enforce remove permissions on the entire subtree 
for backwards compatibility reasons. an example: if you don't have permissions 
to read/edit AC content in a given subtree but you are allowed to remove the 
root of that subtree, you could remove that tree in jr2 irrespective of any 
kind of ac content being present in the subtree... that's something that used 
to cause troubles in the beginning when we introduced access control in jr2.

example 2: a user that is not allowed to execute version operations but is a 
allowed to remove a node should IMO be able to do so, although removing the 
version related protected properties would not be allowed due to lack of the 
corresponding version-mgt permission.


was (Author: anchela):
 I think it's important that the remove permissions are evaluated for the 
 entire subtree instead of just the parent.

well, the last time we discussed this, you said that it's seems better to just 
enforce the remove permission for the remove target, didn't you? apart from 
that we will not be able to enforce remove permissions on the entire subtree 
for backwards compatibility reasons. an example: if you don't have permissions 
to read/edit AC content in a given subtree but you are allowed to remove the 
root of that subtree, you could remove that tree in jr2 irrespective of any 
kind of ac content being present in the subtree... that's something that used 
to cause troubles in the beginning when we introduced access control in jr2.

 Remove of Subtree after Move is not subjected to permission validation
 --

 Key: OAK-1115
 URL: https://issues.apache.org/jira/browse/OAK-1115
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela
Priority: Critical

 the following test passes in Jackrabbit-Core but fails in OAK:
 {code}
 @Test
 public void testMoveRemoveSubTree() throws Exception {
 superuser.getNode(childNPath).addNode(nodeName3);
 superuser.save();
 /* allow READ/WRITE privilege for testUser at 'path' */
 givePrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_READ, rep:write}), Collections.String, ValueemptyMap());
 /* deny READ/REMOVE property privileges at subtree. */
 withdrawPrivileges(path, privilegesFromNames(new String[] 
 {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap(rep:glob, 
 superuser.getValueFactory().createValue(*/+nodeName3)));
 Session testSession = getTestSession();
 assertTrue(testSession.nodeExists(childNPath));
 assertTrue(testSession.hasPermission(childNPath, 
 Session.ACTION_REMOVE));
 assertTrue(testSession.hasPermission(childNPath2, 
 Session.ACTION_ADD_NODE));
 testSession.move(childNPath, childNPath2 + /dest);
 Node dest = testSession.getNode(childNPath2 + /dest);
 dest.getNode(nodeName3).remove();
 try {
 testSession.save();
 fail(Removing child node must be denied.);
 } catch (AccessDeniedException e) {
 // success
 }
 }
 {code}
 this is a critical security issue as it moving around the parent is 
 sufficient in order to be able to remove a node that was otherwise not 
 removable due to limited permissions.
 Afaik this behavior is caused by a limitation in the Diff process which 
 doesn't allow to identify the move and thus makes it impossible to find out 
 if that the subtree has been removed.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1118) Removing and readding mix:versionable fails if node is referenceable

2013-10-25 Thread angela (JIRA)

angela created OAK-1118:
---

 Summary: Removing and readding mix:versionable fails if node is 
referenceable
 Key: OAK-1118
 URL: https://issues.apache.org/jira/browse/OAK-1118
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela


removing mix:versionable from a referenceable node will fail with the following 
exception:

{quote}
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0022: 
/testdata[nt:unstructured, mix:referenceable, mix:versionable]: Mandatory 
property jcr:predecessors can not be removed
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:220)
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:207)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:471)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:334)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:399)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:396)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:128)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:117)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:396)
at 
org.apache.jackrabbit.oak.jcr.nodetype.MixinTest.testRemoveAddMixVersionable2(MixinTest.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62)
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
OakConstraint0022: /testdata[nt:unstructured, mix:referenceable, 
mix:versionable]: Mandatory property jcr:predecessors can not be removed
{quote}

the test:

{code}
@Test
public void testRemoveAddMixVersionable() throws Exception {
testRootNode.addMixin(mixReferenceable);
testRootNode.addMixin(mixVersionable);
superuser.save();
String vhId = testRootNode.getVersionHistory().getUUID();

testRootNode.removeMixin(mixVersionable);
testRootNode.addMixin(mixVersionable);
superuser.save();

assertFalse(vhId.equals(testRootNode.getVersionHistory().getUUID()));
}
{code}

i am not totally sure what is going wrong here as works if the node is only 
mix:versionable



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1098) AuthorizableImpl methods should convert path to Oak path

2013-10-28 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806692#comment-13806692
 ] 

angela commented on OAK-1098:
-

the tests using the simple query pass as of revision 1536314.
however, findAuthorizable(Query) still fails... i ask thomas whether he could 
take a quick look if that could be an issue in the query engine.

 AuthorizableImpl methods should convert path to Oak path
 

 Key: OAK-1098
 URL: https://issues.apache.org/jira/browse/OAK-1098
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Michael Dürig
Assignee: angela

 The methods on {{AuthorizableImpl}} that take a path as an argument all pass 
 that on without converting it to an oak path. I think this is wrong. If not 
 on this layer probably further below.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1124) OAK-938 incomplete: session refresh must also be reflected on derived interfaces

2013-10-29 Thread angela (JIRA)

angela created OAK-1124:
---

 Summary: OAK-938 incomplete: session refresh must also be 
reflected on derived interfaces
 Key: OAK-1124
 URL: https://issues.apache.org/jira/browse/OAK-1124
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela


OAK-938 only wraps the UserManager; what is required in order to fully reflect 
the refresh was to also wrap:

- Authorizable
- User
- Group
- Impersonation



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-1124) OAK-938 incomplete: session refresh must also be reflected on derived interfaces

2013-10-29 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1124:


Assignee: Michael Dürig

 OAK-938 incomplete: session refresh must also be reflected on derived 
 interfaces
 

 Key: OAK-1124
 URL: https://issues.apache.org/jira/browse/OAK-1124
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Michael Dürig

 OAK-938 only wraps the UserManager; what is required in order to fully 
 reflect the refresh was to also wrap:
 - Authorizable
 - User
 - Group
 - Impersonation



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1124) OAK-938 incomplete: session refresh must also be reflected on derived interfaces

2013-10-29 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808008#comment-13808008
 ] 

angela commented on OAK-1124:
-

[~mduerig] maybe you can take care of this? wdyt?

 OAK-938 incomplete: session refresh must also be reflected on derived 
 interfaces
 

 Key: OAK-1124
 URL: https://issues.apache.org/jira/browse/OAK-1124
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Michael Dürig

 OAK-938 only wraps the UserManager; what is required in order to fully 
 reflect the refresh was to also wrap:
 - Authorizable
 - User
 - Group
 - Impersonation



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2

2013-10-30 Thread angela (JIRA)

[
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 current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:

h5. General

h5. User/Group creation

h5. Handling of the Authorizable ID

h5. Equals and HashCode for Authorizables

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:

h5. Group Membership

_TODO_ (see OAK-482)

h4. 2. Builtin Users

h5. Administrator user

The admin user is always being created. The ID of this user is retrieved

[jira] [Updated] (OAK-1126) Same node and property name support

2013-10-30 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1126:


Attachment: OAK-1126.patch

as discussed today in the oak-meeting: i tried it out to see if OAK would 
really work with the corresponding descriptor enabled. the attached a patch 
that shows the effect and includes some extra tests (could not find the tests 
in the TCK).

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-10-30 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809369#comment-13809369
 ] 

angela commented on OAK-1126:
-

in case we decide to apply the patch we could drop this issue from the diff.

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-1126) Same node and property name support

2013-10-30 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809367#comment-13809367
 ] 

angela edited comment on OAK-1126 at 10/30/13 5:30 PM:
---

as discussed today in the oak-meeting: i tried it out to see if OAK would 
really work with the corresponding descriptor enabled. attached a patch that 
shows the effect and includes some extra tests (could not find the tests in the 
TCK).


was (Author: anchela):
as discussed today in the oak-meeting: i tried it out to see if OAK would 
really work with the corresponding descriptor enabled. the attached a patch 
that shows the effect and includes some extra tests (could not find the tests 
in the TCK).

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (OAK-1135) NPE in CompiledPermissionImpl.getTreePermission()

2013-10-31 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela reopened OAK-1135:
-


would it be possible to have test case that illustrates how the problem arises?
i would also suggest to slightly refactor the fix, which i felt more 
comfortable with when having a test.

 NPE in CompiledPermissionImpl.getTreePermission()
 -

 Key: OAK-1135
 URL: https://issues.apache.org/jira/browse/OAK-1135
 Project: Jackrabbit Oak
  Issue Type: Improvement
Reporter: Tobias Bocanegra
 Fix For: 0.11


 I don't know exactly why and when, but accessing an property in the version 
 store can yield to an NPE in CompiledPermissionImpl.getTreePermission() if 
 the TreeLocation is a PropertyLocation. then TreeLocation.getTree() returbs 
 NULL and subsequently causes a NPE.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-1136) Revisit/Improve CompiledPermissionImpl.getTreePermission()

2013-10-31 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1136:


Issue Type: Sub-task  (was: Improvement)
Parent: OAK-527

 Revisit/Improve CompiledPermissionImpl.getTreePermission()
 --

 Key: OAK-1136
 URL: https://issues.apache.org/jira/browse/OAK-1136
 Project: Jackrabbit Oak
  Issue Type: Sub-task
Reporter: Tobias Bocanegra

 Debugging a problem in CompiledPermissionImpl.getTreePermission() showed that 
 many TreeLocation objects are created and expensive path calculations are 
 performed. 
 The code should be looked at again and optimized.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-414) Importing protected properties and nodes

2013-10-31 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-414.


Resolution: Fixed

 Importing protected properties and nodes
 

 Key: OAK-414
 URL: https://issues.apache.org/jira/browse/OAK-414
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela
Assignee: Manfred Baedke

 for backwards compatibility with jackrabbit we should also implement
 the ability to import protected items.
 while import version content is most probably unique and system defined,
 there are quite some areas like user management and access control that
 need to be pluggable and thus the particular import behavior should be
 defined by the corresponding implementation.
 i envision this to work in a similar way than the implementation
 specific validators.
 steps to get there include:
 - properly setup the xml-import such that it recognizes protected items
   and calls the configured protected-item-importers.
 - allow to plugin implementation specific extensions
 - define an interface for that protected item import.
 regarding the latest part: in contrast to jackrabbit core, where we had
 just the JCR API at hand i would suggest to setup those special importers
 such that they can operate both on the JCR API (session and extensions)
 and on the OAK API giving the implementation more flexibility on how
 to actually treat the import.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-414) Importing protected properties and nodes

2013-10-31 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810485#comment-13810485
 ] 

angela commented on OAK-414:


i think we can resolve that fixed. workspace import works in the mean time and 
the import now uses OAK API instead of JCR API. 

 Importing protected properties and nodes
 

 Key: OAK-414
 URL: https://issues.apache.org/jira/browse/OAK-414
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela
Assignee: Manfred Baedke

 for backwards compatibility with jackrabbit we should also implement
 the ability to import protected items.
 while import version content is most probably unique and system defined,
 there are quite some areas like user management and access control that
 need to be pluggable and thus the particular import behavior should be
 defined by the corresponding implementation.
 i envision this to work in a similar way than the implementation
 specific validators.
 steps to get there include:
 - properly setup the xml-import such that it recognizes protected items
   and calls the configured protected-item-importers.
 - allow to plugin implementation specific extensions
 - define an interface for that protected item import.
 regarding the latest part: in contrast to jackrabbit core, where we had
 just the JCR API at hand i would suggest to setup those special importers
 such that they can operate both on the JCR API (session and extensions)
 and on the OAK API giving the implementation more flexibility on how
 to actually treat the import.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-952) AccessControlValidator: fail for ACEs created for any of the admin principals

2013-10-31 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-952.


Resolution: Won't Fix

probably too restrictive and could possibly cause backwards compatibility 
issues... that's not worth the trouble.

 AccessControlValidator: fail for ACEs created for any of the admin principals
 -

 Key: OAK-952
 URL: https://issues.apache.org/jira/browse/OAK-952
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela
Priority: Minor

 we may consider failing any AC modification if the principal associated with
 a given ACE is either the system principal, an admin principal or one of the 
 principals listed as admin in the permission configuration.
 while having ACEs for those prinicpals don't have an effect it might be 
 confusing that they can be created in the first place and may create a wrong 
 sense of security.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1135) NPE in CompiledPermissionImpl.getTreePermission()

2013-10-31 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810824#comment-13810824
]

angela commented on OAK-1135:
-

if we can't reproduce an issue we most probably didn't understand what went
wrong and where the bug is... so i would argue that any fix that relies on that
kind of analysis is most probably not correct. IMHO it is indispensable to
write tests for odd behavior or whenever a failure arises with the permission
evaluation. if we get NPE, we must have a test that covers the setup that
caused that error because this was apparently something we didn't expect to
happen. having tests for things like that is IMO required irrespective on
whether we change the code or not... but having them makes it easier to change
the code later on.

if it's not a simple setup i would suggst to use the jcr-logger present with
jackrabbit-commons to determine the set of JCR calls that lead to the problem

NPE in CompiledPermissionImpl.getTreePermission()
-

Key: OAK-1135
URL: https://issues.apache.org/jira/browse/OAK-1135
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Tobias Bocanegra
Fix For: 0.11

I don't know exactly why and when, but accessing an property in the version
store can yield to an NPE in CompiledPermissionImpl.getTreePermission() if
the TreeLocation is a PropertyLocation. then TreeLocation.getTree() returbs
NULL and subsequently causes a NPE.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (OAK-1144) Avoid wrapping TreePermission into SecurityContext

2013-11-04 Thread angela (JIRA)

angela created OAK-1144:
---

 Summary: Avoid wrapping TreePermission into SecurityContext
 Key: OAK-1144
 URL: https://issues.apache.org/jira/browse/OAK-1144
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela
Assignee: angela
Priority: Minor


as suggested on the mailing list we may want to drop the extra security context 
(see http://markmail.org/message/75msw25wkicy6bdu)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (OAK-1144) Avoid wrapping TreePermission into SecurityContext

2013-11-04 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1144:


Attachment: OAK-1144.patch

proposed patch.

[~jukkaz], i would be glad if you could review the patch. i wasn't totally sure 
about the equals present on the SecurityContext. for the time being i moved it 
to the TreePermission implementation but that's definitely something i would 
love to get a second opinion on. thanks.

 Avoid wrapping TreePermission into SecurityContext
 --

 Key: OAK-1144
 URL: https://issues.apache.org/jira/browse/OAK-1144
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela
Assignee: angela
Priority: Minor
 Attachments: OAK-1144.patch


 as suggested on the mailing list we may want to drop the extra security 
 context (see http://markmail.org/message/75msw25wkicy6bdu)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-11-05 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813810#comment-13813810
 ] 

angela commented on OAK-1126:
-

{quote}
This was never a use case. From the beginning on oak-core was deemed to be the 
only client to the MicroKernel ever. 
{quote}

i can confirm this; it was one of the fundamental design decisions and i was 
always and officially promised that oak-core was the only way to access the 
microkernel when i expressed concerns wrt security of the MK. if this has 
changed in the mean time we should also reconsider on how to secure the MK.

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 
 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1135) NPE in CompiledPermissionImpl.getTreePermission()

2013-11-05 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813821#comment-13813821
 ] 

angela commented on OAK-1135:
-

actually it's in the sandbox not in the commons project :-) i got the link from 
thomas who originally created the feature:

http://svn.apache.org/viewvc/jackrabbit/trunk/contrib/jcrlog/?pathrev=540521

 NPE in CompiledPermissionImpl.getTreePermission()
 -

 Key: OAK-1135
 URL: https://issues.apache.org/jira/browse/OAK-1135
 Project: Jackrabbit Oak
  Issue Type: Improvement
Reporter: Tobias Bocanegra
 Fix For: 0.11


 I don't know exactly why and when, but accessing an property in the version 
 store can yield to an NPE in CompiledPermissionImpl.getTreePermission() if 
 the TreeLocation is a PropertyLocation. then TreeLocation.getTree() returbs 
 NULL and subsequently causes a NPE.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (OAK-1098) AuthorizableImpl methods should convert path to Oak path

2013-11-05 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1098.
-

Resolution: Fixed

 AuthorizableImpl methods should convert path to Oak path
 

 Key: OAK-1098
 URL: https://issues.apache.org/jira/browse/OAK-1098
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Michael Dürig
Assignee: angela

 The methods on {{AuthorizableImpl}} that take a path as an argument all pass 
 that on without converting it to an oak path. I think this is wrong. If not 
 on this layer probably further below.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit

2013-11-05 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
 ] 

angela edited comment on OAK-910 at 11/5/13 1:09 PM:
-

h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type definition.  In addition 
a specific privilege {{Validator}} and {{CommitHook}} implementations assert 
the consistency of the privilege store. The built-in privileges are installed 
using a dedicated implementation of the {{RepositoryInitializer}} [0].

h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves 
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the 
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that 
modifications made on the OAK API directly is equally verified. Subsequently 
any violation (permission, privilege consistency) is only detected at the end 
of the registration process. The privilege manager itself does not perform any 
validation.

h4. 2. Built-in Privilege Definitions

* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties

Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties, 
rep:alterProperties and rep:removeProperties

h4. 3. Node Type Definitions

The following privilege related built-in node types have been added in OAK 1.0. 
They are used to represent built-in and custom privilege definitions in the 
repository.

{code}
[rep:Privileges]
  + * (rep:Privilege) = rep:Privilege protected ABORT
  - rep:next (LONG) protected multiple mandatory

[rep:Privilege]
  - rep:isAbstract (BOOLEAN) protected
  - rep:aggregates (NAME) protected multiple
  - rep:bits (LONG) protected multiple mandatory
{code}

h4. 4. API Extensions

org.apache.jackrabbit.oak.spi.security.privilege
- {{PrivilegeBitsProvider}} : Provider implementation to read {{PrivilegeBits}} 
from the repository content and map names to internal representation (and vice 
versa).
- {{PrivilegeBits}}: Internal representation of JCR privileges.

h4. 5. Configuration

* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} - returns a new instance of the 
{{PrivilegeManager}} interface such as exposed by 
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default 
implementation is based on OAK API and can equally be used for privilege 
related tasks in the OAK layer.

h4. 6. References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java


was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type definition.  In addition 
a specific privilege {{Validator}} and {{CommitHook}} implementations assert 
the consistency of the privilege store. The built-in privileges are installed 
using a dedicated implementation of the {{RepositoryInitializer}} [0].

h5. Registration of Custom Privileges
As far as registration of

[jira] [Resolved] (OAK-910) Privilege Management: Document changes wrt Jackrabbit

2013-11-05 Thread angela (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-910.


Resolution: Fixed

 Privilege Management: Document changes wrt Jackrabbit
 -

 Key: OAK-910
 URL: https://issues.apache.org/jira/browse/OAK-910
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, jcr
Reporter: angela
Assignee: angela





--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit

2013-11-05 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
 ] 

angela edited comment on OAK-910 at 11/5/13 1:11 PM:
-

h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type definition.  In addition 
a specific privilege {{Validator}} and {{CommitHook}} implementations assert 
the consistency of the privilege store. The built-in privileges are installed 
using a dedicated implementation of the {{RepositoryInitializer}} [0].

h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves 
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the 
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that 
modifications made on the OAK API directly is equally verified. Subsequently 
any violation (permission, privilege consistency) is only detected at the end 
of the registration process. The privilege manager itself does not perform any 
validation.

h4. 2. Built-in Privilege Definitions

* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties

Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties, 
rep:alterProperties and rep:removeProperties

h4. 3. Node Type Definitions

The following privilege related built-in node types have been added in OAK 1.0. 
They are used to represent built-in and custom privilege definitions in the 
repository.

{code}
[rep:Privileges]
  + * (rep:Privilege) = rep:Privilege protected ABORT
  - rep:next (LONG) protected multiple mandatory

[rep:Privilege]
  - rep:isAbstract (BOOLEAN) protected
  - rep:aggregates (NAME) protected multiple
  - rep:bits (LONG) protected multiple mandatory
{code}

h4. 4. API Extensions

org.apache.jackrabbit.oak.spi.security.privilege
- {{PrivilegeBitsProvider}} : Provider implementation to read {{PrivilegeBits}} 
from the repository content and map names to internal representation (and vice 
versa) [2].
- {{PrivilegeBits}}: Internal representation of JCR privileges [3].

h4. 5. Configuration

* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} - returns a new instance of the 
{{PrivilegeManager}} interface such as exposed by 
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default 
implementation is based on OAK API and can equally be used for privilege 
related tasks in the OAK layer.

h4. 6. References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
[2] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBitsProvider.java
[3] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBits.java


was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type

< 1 2 3 4 5 6 7 8 9 10 >

501 - 600 of 4199 matches

Mail list logo