Views display plugin's list of handlers is not filtered by access

+++ b/core/modules/views/tests/modules/views_test_data/lib/Drupal/views_test_data/Plugin/views/area/TestExample.php
@@ -19,11 +20,19 @@
+    $options['custom_access'] = array('default' => TRUE, 'bool' => TRUE);

we don't really need 'bool' => TRUE

Rerolled for #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4. Edit: I didn't fix #5.

Before we just fix this, we have to take into account all the bugs caused by this security fix.

RE #5: See our postponed issue - #1922966: Remove 'bool' and 'translatable' key from option definitions

Straight reroll. The end of may seems a long time ago

Since this has a disclosed SA, it should be an upgrade path blocker (per #2341575: [meta] Provide a beta to beta/rc upgrade path).

1. +++ b/core/modules/views/src/Tests/Handler/AreaTest.php
   @@ -113,6 +113,19 @@ public function testRenderArea() {
   +    $output = drupal_render($output);
   

   note: drupal_render() is already deprecated. use \Drupal::service('renderer')->render() instead.

2. +++ b/core/modules/views/tests/modules/views_test_data/src/Plugin/views/area/TestExample.php
   @@ -20,11 +21,19 @@
   +    $options['custom_access'] = array('default' => TRUE, 'bool' => TRUE);
   

   Note: this does not need 'bool' => TRUE any longer, but rather an update to the views schema for this plugin.

5 weeks is a long time in D8 development ...
Patch still applies, but I am not certain everything will be green

So retesting

An updated version of #11 with the changes from #13 (replacing drupal_render(), removing 'bool' => TRUE and adding a schema for views.area.test_example).

Fixed wrong file location.

+++ b/core/modules/views/src/Tests/Handler/AreaTest.php
@@ -113,6 +113,19 @@ public function testRenderArea() {
+    $this->assertFalse(strpos($output, 'a custom string') !== FALSE);

Testing a negative is always a little fragile, since there might be multiple reasons for a certain string to not appear, access being only one of them. Should we also add a test for turning access on and verifying that "a custom string" is present, thereby increasing our confidence that it not appearing was because of a properly functioning access checker?

Also, I think it would be good for the issue summary to explain why the testing strategy employed here (render and check for what rendered) is different than what was committed to D7 Views. I think it's fine to use a different testing approach for the different versions, but since it's a security issue, I think having a documented record of the reason is valuable.

The actual D7 commit had a really explicit test, we really should have that here.
Given that we should mark this issue as needs work, sorry.

I wrote the original test, I should be able to recreate it for D8.

I left in the string-based check as well, but added the explicit checks, and included testing when access is allowed.

Alright, the tests now look a little bit more sane.

Committed 3dcbc22 and pushed to 8.0.x. Thanks!