Authenticated role is not correctly taken into account while indexing rendered_item which is the rendered HTML output of the node. None of the layout builder content is recorded into the index by checking with queries in solr administration panel.
Search server solr, group module, layout builder
In a group, create a node and add some content using the layout builder.
Add "Rendered HTML output" to the index:
Create the index
The content added with the layout builder is not in the index.
The issue is found in "src/Plugin/search_api/processor/RenderedItem.php" in addFieldValues()
Before rendering the HTML of the node, the "index user session" gets an access forbidden. Applying patch "3181863" actually solve this access issue.
But when processing the rendered HTML output field "(l292) $this->getRenderer()->renderPlain($build)" returns a "the 'entity:user' context is required [...]" error falling into throwing an exception and skipping the field.
By giving an existing user id (uid) to the temporary user session used, it can the access to the content of the rendered HTML output field.
Proposed solution is to not modify current behavior of the code and provide a new hook to alter the user id (uid) provided to the temporary user sessions. The new uid is to be provided by a custom code using the new hook.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3317397-hook-alter-index-session-uid-7.patch.txt | 1.76 KB | tomefa |
| #2 | 3317397-hook-alter-index-session-uid.patch | 1.92 KB | pierreemmanuel |
Comments
Comment #2
pierreemmanuel commentedPatch file for this issue.
Comment #3
drunken monkeyThanks for reporting this problem, and sorry it took a while to get back to you.
As you are probably aware, this is a really tricky problem, where it seems there are no solutions that work for everyone. An alter hook therefore could make sense. However, we don’t use hooks in this module anymore (all existing ones have been deprecated, see #3023704: Convert hooks to events), so we’d provide an event for this instead. (Also, just for your information, there is
\Drupal::moduleHandler()->alter()for alter hooks, no need to manually pass an array with a reference toinvokeAll().)However, it seems like this could also be solved by having an alternative when configuring the field to specify a user ID instead of the roles? Or what else would you put into your alter hook implementation (resp. event listener)? Code that looks up a user with the correct roles?
Setting a fixed user ID is, of course, also not ideal, since that user’s roles can change (though I would of course advise on adding a special user just for that). But as an optional alternative, it might solve a few users’ problems with this.
Comment #4
pierreemmanuel commentedHi,
We have a very specific workflow where users with the same role and permissions can have different content access. On top of group we can set permissions per node for on or more users both including only a list(s) of people or excluding a list(s).
So this patch is meant to index with an administrator role that can see every nodes because we narrow down after regarding each user access with a custom processor.
So, I think this issue is not an issue and needs to be closed, because it is only one case specific.
Regards
Comment #5
pierreemmanuel commentedComment #7
tomefa commentedReroll of patch for latest version.