[
https://issues.apache.org/jira/browse/OAK-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798861#comment-16798861
]
Alex Deparvu edited comment on OAK-8054 at 3/22/19 11:16 AM:
-------------------------------------------------------------
Just noticed another side effect of this change and I'm documenting it here for
future reference:
If a group has a conflict which gets merged with the old code, its
{{rep:members}} property effectively changes type from {{WEAKREFERENCE[]}} to
{{STRING[]}}.
Chaging the type will break the {{Authorizable.memberOf()}} call because this
in turn relies on the {{reference}} index (which will ignore the string[]
property) to return the groups that an authorizable is directly a part of.
Breakage here means that the LoginModule call that compiles the current
session's principals will not contain all of the users's groups so it will not
have a correct view on the aggregated permissions.
Reindexing the {{reference}} index will not help as long as the property's type
is wrong.
In some cases if the group's membership changes (adds or removes members) the
property's type will self-heal (type is set correctly by the update code), but
due to the internal structure there can be more that one member list chunks and
only the updated one will be fixed.
As a workaround removing (save the changes so they trigger an update) and
adding a user to the group seems to fix the problem for that specific user as
it will probably get moved to a different chunk of the membership list.
was (Author: alex.parvulescu):
Just noticed another side effect of this change and I'm documenting it here for
future reference:
If a group has a conflict which gets merged with the old code, its
{{rep:mebers}} property effectively changes type from {{WEAKREFERENCE[]}} to
{{STRING[]}}.
Chaging the type will break the {{Authorizable.memberOf()}} call because this
in turn relies on the {{reference}} index (which will ignore the string[]
property) to return the groups that an authorizable is directly a part of.
Breakage here means that the LoginModule call that compiles the current
session's principals will not contain all of the users's groups so it will not
have a correct view on the aggregated permissions.
> RepMembersConflictHandler creates property with wrong type
> ----------------------------------------------------------
>
> Key: OAK-8054
> URL: https://issues.apache.org/jira/browse/OAK-8054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
> Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6, 1.8.7,
> 1.8.8, 1.8.9, 1.8.10, 1.8.11, 1.8.12, 1.10
> Reporter: Alex Deparvu
> Assignee: Alex Deparvu
> Priority: Critical
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.13
>
> Attachments: OAK-8054-impact.patch, OAK-8054.patch
>
>
> The {{RepMembersConflictHandler}} handler uses type {{STRING}} instead of
> {{WEAKREFERENCE}} [0] as per the property's definition, which will trigger
> the type validation to fail the commit.
> Running external login tests I see that the type fails as soon as the handler
> comes into play:
> {noformat}
> WARN o.a.j.o.s.s.a.e.i.ExternalLoginModule - User synchronization failed
> during commit: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakConstraint0004:
> /rep:security/rep:authorizables/rep:groups/pathPrefix/g8/rep:membersList/9[[rep:MemberReferences]]:
> No matching property definition found for rep:members =
> [8e490910-17b6-30c1-8e11-6abdfa8a4ebc, 1a8e79f5-428e-39e9-88bb-2b86bd9b402e,
> ... ]. (attempt 10/50)
> {noformat}
> This seems to be a pretty big issue, and I'm not yet sure why it wasn't
> caught by the existing tests.
> // fyi [~anchela]
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/RepMembersConflictHandler.java#L135
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
