The reindexObjectSecurity patch relies on the fact whether the indexed value changed or not to determine when it can safely stop recursion. This check did not account for the fact that the allowedRolesAndUsers indexer contains a [shortcut / optimization that makes the indexed allowed roles not correspond exactly to the real allowed roles in all cases:
If any of the Anonymous or Authenticated roles are present in the allowed roles, the resulting value to be indexed gets simplified to just that role name.
This can lead to situations where the effective set of allowed roles and principals changed, but the indexed value stays the same. That's fine for that specific object, but the change may make it necessary to reindex security for a child further down the line.
But because we useis_index_up_to_date() to determine when to stop recursion, we would stop recursion too early in that case.
We therefore always assume the indexed value has changed if we see any of these two roles in the new indexed value.
The reindexObjectSecurity patch relies on the fact whether the indexed value changed or not to determine when it can safely stop recursion. This check did not account for the fact that the
allowedRolesAndUsersindexer contains a [shortcut / optimization that makes the indexed allowed roles not correspond exactly to the real allowed roles in all cases:If any of the
AnonymousorAuthenticatedroles are present in the allowed roles, the resulting value to be indexed gets simplified to just that role name.This can lead to situations where the effective set of allowed roles and principals changed, but the indexed value stays the same. That's fine for that specific object, but the change may make it necessary to reindex security for a child further down the line.
But because we use
is_index_up_to_date()to determine when to stop recursion, we would stop recursion too early in that case.We therefore always assume the indexed value has changed if we see any of these two roles in the new indexed value.
Fixes #126