title: How can CakePHP Authorization plugin authorize access to indexes?
body: <p>I'm converting my app to CakePHP 3.6, and working now on using the new Authorization plugin. I'm not sure how to check authorization for things like indexes or other reports, where there is no "resource" to pass to the <code>can()</code> or <code>authorize()</code> functions.</p>
  
  <p>For now, I've built a <code>ControllerResolver</code>, loosely copied from the <code>ORMResolver</code>, which accepts controller objects and finds policies based on the singularized controller name, so that they're named the same as the Entity policies I'm building. (That is, my <code>UserPolicy</code> can have <code>canIndex</code> and <code>canEdit</code> functions, the former found via the controller and the latter via the entity.)</p>
  
  <p>This works fine in controller actions where I can call <code>$this-&gt;Authorize-&gt;authorize($this);</code>, but it doesn't work in views, where I'd like to be able to do things like:</p>
  
  <pre><code>if ($this-&gt;Identity-&gt;can('index', *something*)) {
      echo $this-&gt;Html-&gt;link('List', ['action' =&gt; 'index']);
  }
  </code></pre>
  
  <p>so as to only show links to people who are allowed to run those actions.</p>
  
  <p>Anyone know if there's a reason why the system implicitly requires that the "resource" passed into authorization functions be an object? (For example, the plugin component calls <code>get_class($resource)</code> in the case of a failed authorization, without first checking that the provided resource is in fact an object.) Allowing a string (e.g. <code>\App\Controller\UsersController::class</code>) would make my life easy. Very happy to put together a PR for this if it's just an oversight.</p>
  
  <p>But authorizing indexes seems like a pretty obvious function, so I wonder if I've missed something. Maybe I'm supposed to pass the table object, and split the authorization between an entity policy and a table policy? But using table objects in views just for this purpose seems like a violation of separation of concerns. Maybe uses of the plugin to date have been things where indexes are always public?</p>