enapps-enorman commented on a change in pull request #471:
URL: https://github.com/apache/jackrabbit-oak/pull/471#discussion_r797977228
##########
File path:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/AuthorizablePropertiesImpl.java
##########
@@ -234,9 +236,34 @@ private PropertyState getAuthorizableProperty(@NotNull
Tree authorizableTree, @N
}
ReadOnlyNodeTypeManager nodeTypeManager =
authorizable.getUserManager().getNodeTypeManager();
PropertyDefinition def = nodeTypeManager.getDefinition(parent,
property, true);
- if (def.isProtected() || (authorizablePath.equals(parent.getPath())
- &&
!def.getDeclaringNodeType().isNodeType(UserConstants.NT_REP_AUTHORIZABLE))) {
+ if (def.isProtected()) {
+ // exclude all protected properties
return null;
+ } else if (authorizablePath.equals(parent.getPath())) {
+ // non-protected properties on the root must be defined by the
expected
+ // primary type or one of the configured mixin types
+ Boolean allowed = null;
+ NodeType declaringNodeType = def.getDeclaringNodeType();
+ if
(declaringNodeType.isNodeType(UserConstants.NT_REP_AUTHORIZABLE)) {
+ // defined by the expected primary type so allowed
+ allowed = Boolean.TRUE;
Review comment:
@anchela Yes, that is basically correct. My proposal is not really
about limiting the set of properties that can be written, I simply wish to have
a more specific value constraint defined for certain property definitions (as
defined by a mixin type that I have assigned). And I don't want the existence
of that more specific property definition (with the value constraint) to make
the property invisible from the Authorizable.getProperty call.
If you are curious, the more specific value constraint idea is motivated by
security concerns about ensuring that self-registered end users of the platform
can not abuse their self-managed user profile properties to store invalid or
unreasonably long values to the repository. For an extreme example, we don't
want the user to do something like encoding a binary file as text and storing
that value as the "nickname" property in their user profile. We want some
reasonable max length (or other) value constraint on the property definition so
extremely invalid values will never be stored even if the end user somehow
manages to get around the form post validation checking.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
