Problem
From looking at the code, I think DefaultContentEntityProcessor does not respect field access .
Steps to reproduce
foreach ($display->getComponents() as $field_name => $options) {
if (isset($entity->{$field_name})) {
$this->getCustomElementGenerator()->process($entity->get($field_name), $custom_element, $viewMode);
}
}
getComponents() does not have a field-access filter, nor is it filtered here. It's usuallly done at EntityViewDisplay::buildMultiple()
Proposed resolution
Check field access like
foreach ($display->getComponents() as $field_name => $options) {
if (isset($entity->{$field_name}) && field access) {
$this->getCustomElementGenerator()->process($entity->get($field_name), $custom_element, $viewMode);
}
}
besides that we need to make sure to reflect this in caching metadata as done by EntityViewDisplay:
// Apply the field access cacheability metadata to the render array.
$this->renderer
->addCacheableDependency($build_list[$id][$name], $field_access);
Best, let's also add a follow-up for adding a unit test that ensures that not accessible fields are not displayed.
Comments
Comment #2
fagoComment #5
vasikeplease check the MR open
Unit testing should chased here ... or new issue?
Comment #6
fagothx, I think this looks pretty good already. We really need to setup the drupal testbot here now.
I added two comments to the MR, please see the above to comments for that. In particular the access-check cache metadata issue, see https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Access%21... - the API should support that somehow.
Comment #7
vasikeComment #8
fagoseems good to me now. let's do some more testing and then let's merge when all fine. I created #3273275: Make custom_elements_thunder follow field-access for the remaining thunder sub-module.
Comment #9
fagoComment #12
useernamee commentedpr merged. will be included in the next release