You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Eric Norman (Jira)" <ji...@apache.org> on 2022/02/15 08:55:00 UTC

[jira] [Comment Edited] (OAK-9675) Configuration option for allowed authorizable properties mixin types

    [ https://issues.apache.org/jira/browse/OAK-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492448#comment-17492448 ] 

Eric Norman edited comment on OAK-9675 at 2/15/22, 8:54 AM:
------------------------------------------------------------

[~angela] I stated several times that I only grant the user permission to alter properties that already exist and subnodes are precreated with a custom nodetype.  So that is a solved problem for me.  You would get an access denied error during the commit if they to add something else.  Can we please stay focused on the reading of the properties and not change the subject to writing properties?


was (Author: enorman):
[~angela] I stated several times that I only grant the user permission to alter properties that already exist.  So that is a solved problem for me.  You would get an access denied error during the commit.  Can we please stay focused on the reading of the properties and not change the subject to writing properties?

> Configuration option for allowed authorizable properties mixin types
> --------------------------------------------------------------------
>
>                 Key: OAK-9675
>                 URL: https://issues.apache.org/jira/browse/OAK-9675
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, security-spi
>            Reporter: Eric Norman
>            Assignee: Angela Schreiber
>            Priority: Major
>             Fix For: 1.44.0
>
>
> This is in support of a use case where we want a stricter value constraint on what is allowed to be stored in an authorizable property.  The unstructured property definition from rep:Authorizable is too permissive for the use case.  Defining  and using a mixin with a property definition that has a value constraint defined solves most of the use case, but  after doing that then the property is no longer visible in the authorizable properties.
> Basically, the current implementation of AuthorizablePropertiesImpl#getAuthorizableProperty will exclude any properties whose property definition is not declared by the rep:Authorizable node type.  This means property definitions that are defined by any mixin type are excluded.
> The proposed improvement here is to add an optional configuration property that would define the names of mixin types that are allowed to define authorizable properties.  Any property definition defined by a mixin type in this set would be included, and anything else would be excluded as before.
>  
> NOTE: This is applicable only to the properties stored in the root user/group home node.  Any properties defined under subnodes are not affected by this configuration as those properties were not being excluded the same way that the properties on the root home node were.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)