Security issue. Add access callback for admin views.

This is by design. The view is kept generic so that it can be readily reused, and then the page that actually displays the view takes care of the permissions. Should someone clone the view to customize it, etc then it's up to them to make sure it still has the appropriate permissions.

Are these views enabled by default at all? This seems at least like we could put the basic security permission around, rather than leaving it open by default.

Both views are enabled by default. I am using 7.x-1.5+36-dev. Actually, the security review module complains about it straight away. I support adding basic access control.

ok, *Fine* ;-)

Committed.

The patch committed from this issue has caused a regression. It adds a permission check to the 'fieldable_pane_entity_revisions' view. The 'administer fieldable panels panes' permission is now required to access the view.

The view is used exclusively on the FPP entity revision page, which is already controlled by an access callback:

  $items['admin/structure/fieldable-panels-panes/view/%fieldable_panels_panes/revision'] = array(
    'title' => 'Revisions',
    'type' => MENU_LOCAL_TASK,
    'page callback' => 'fieldable_panels_panes_entity_list_revisions_page',
    'page arguments' => array(4),
    'access callback' => 'fieldable_panels_panes_access',
    'access arguments' => array('delete', 4),
    'weight' => -7,
  ) + $base;

Access to the page requires the delete permission for the bundle; however, access to the view requires the 'administer fieldable panels panes' permission. As a result, all users with the delete permission for the bundle but not the 'administer fieldable panels panes' permission will get a WSOD.

I don't disagree access control should be implemented for the view; however, it appears a Views access plugin is necessary.

+1 to #10. This is a regression. It makes no sense to have 2 separate permission checks that have to be kept in sync. Why exactly can't we rely on the page's callback here?

Patch that just focuses on the revisions view. I would think we could also remove the custom access plugin for the fieldable_pane_entities since I think it's in the same situation but I didn't quite follow all of the discussion in #2207625: Add permission to list fieldable panel panes so I just left that alone for now.

The idea is that administrative views are bundled with an administrative-level permission by default. Unfortunately if the views are disabled then views_embed_views() doesn't work.

Throwing some darts at the dartboard.

What if we got rid of fieldable_panels_panes_access_callback() and just worked off fieldable_panels_panes_access()? Need to do some testing with this, and probably write more tests.

Lets see if the tests can be made green.

Ok, tests are green, but I really feel we need additional tests.