Problem/Motivation
Drupal\field\Plugin\views\field\Field::access() according to the ViewsHandlerInterface should return a boolean. Instead it calls fieldAccess with $return_as_object set to TRUE. Later in ViewExecutable::_initHandler it converts the object into a boolean and so grants access all the time.
Proposed resolution
Call fieldAccess() in Drupal\field\Plugin\views\field\Field::accesswith $return_as_object = FALSE instead of TRUE.
Remaining tasks
User interface changes
API changes
Beta phase evaluation
| Issue category | Bug because its a security problem |
|---|---|
| Issue priority | Critical as access checking for entity fields in views don't work |
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | views-field-access-2382931-20-test-only.patch | 4.41 KB | pfrenssen |
| #20 | views-field-access-2382931-20.patch | 5.21 KB | pfrenssen |
Comments
Comment #1
dawehnerAdded a beta evaluation.
Comment #2
dawehnerComment #3
mile23That will allow access for 'neutral' access. Here are two patches. One just changes $return_as_object to FALSE. The other leaves it as TRUE and then asks the object for explicit access. Let's see what the testbot thinks.
Comment #4
yesct commentedComment #5
dawehnerThe first one is the way to go.
I removed the argumentation regarding the test. We need an integration tests, so we are really sure this does not happen on application level, sorry.
Security is always a critical problem!
The unit test will be part of that other issue, given that you can't just copy it over.
Comment #6
mile23So fields don't require explicit access?
Ahh, never mind. The bool solution just short-cuts isAllowed(). Yay security as a side-effect!
Comment #7
berdirFALSE is the default value, so you can remove the last two arguments...
Comment #8
mile23Learning to generate a fixture for a views integration test isn't something I'm going to be able to get to in a timely manner, so if someone wants to take this up, go right ahead.
Comment #9
larowlanadding tests
Comment #10
larowlanSo I wrote a test, and scratched the surface, picked at the wallpaper and accidentally discovered that any plugin that uses the standard views field plugin *ignores entity access controllers*
Here's a test to demonstrate that.
The issue is
in HandlerBase isn't overridden by FieldPluginBase
Comment #11
larowlantagging
Comment #12
larowlanComment #13
larowlanSpoke to @chx on irc - this is a new issue, opening separate issue.
Comment #15
chx commentedComment #16
larowlanAdded #2385443: Test that base entity fields on views respect field level access for base field issue.
Comment #17
larowlanHere's a WIP towards a test for this, unfortunately it passes.
Comment #18
pfrenssenGoing to have a look as part of the DA core sprint in Ghent.
Comment #19
pfrenssenThe test currently works because the field is tested as part of an entity. When
ViewExecutable::_initHandler()checks access during$view->preExecute()the failed access is ignored because the object is passed instead of the boolean. Later on in the test a second access check is performed inEntityViewDisplay::buildMultiple()which is called as part of$view->style_plugin->getField(). This one is handling the access correctly and sets '#access' to FALSE on the field.So in order to prove that this bug is definitively fixed we need to check that the field is removed from the view after the preExecute() step. I would also leave the current test in place because that is a good functional test: it checks that the field is actually not being rendered.
Comment #20
pfrenssenComment #22
pfrenssenComment #23
dawehnerThis is fanstatic work!
Comment #24
alexpottThis issue addresses a critical bug and is allowed per https://www.drupal.org/core/beta-changes. Committed fb40bd6 and pushed to 8.0.x. Thanks!
Fixed duplication in comment.
Comment #26
andypostthis needs follow-up to add docblocks