Add a method to the AccessManager that only needs a route name and parameters

+++ b/core/lib/Drupal/Core/Access/AccessManager.phpundefined
@@ -108,6 +109,40 @@ protected function applies(Route $route) {
+   *  Returns TRUE if the user has access to the route, otherwise FALSE.

Indented wrong.

+++ b/core/lib/Drupal/Core/Access/AccessManager.phpundefined
@@ -108,6 +109,40 @@ protected function applies(Route $route) {
+      $route = $$this->container->get('router.route_provider')->getRouteByName($route_name, $parameters);

I just had $$this in another issue, certainly didn't work like I wanted :_

Just did a bit of work on the tests, but no real progress.

Some more tracking of work.

Completed the test coverage.

Oh another one showing a clear lack of sleep.

+++ b/core/lib/Drupal/Core/Access/AccessManager.php
@@ -108,6 +151,48 @@ protected function applies(Route $route) {
+        $defaults['account'] = $this->container->get('request')->attributes->get('account');

Shouldn't this be _account now?

You are totally right.

Thanks for your review!

+++ b/core/lib/Drupal/Core/Access/AccessManager.php
@@ -108,6 +151,48 @@ protected function applies(Route $route) {
+    catch (RouteNotFoundException $e) {
+      // Convert to the expected exception.
+      throw new AccessDeniedHttpException();
+    }
+    catch (NotFoundHttpException $e) {
+      // Convert to the expected exception.
+      throw new AccessDeniedHttpException();
+    }

Exceptions are expensive. Something like checkedNamedRoute() should be returning True/False, not exceptioning.

This totally makes sense, especially this is simpler.

This replaces to get the current request to get it from an injected version instead of the container.

This looks saner but checkNamedRoute() could use some profiling. Have never been keen on mocking the request for every access check and this adds even more setup.

.

To be honest the DB query to load the route worries me, but there is no way around that.

I am fine with creating a profile, but I am not sure what really to profile. The complex bits are probably the route naming but that is cached.

#17: access_manager-2046737-17.patch queued for re-testing.

This didn't seem critical because all of the work we've done have been with relatively simple routes. Now we're hitting the hard stuff.

Here's a list of issues this blocks, I will add it to the issue summary

#2044539: Implement LocalTask plugins for login/password/register tabs
#2056627: Form API autocomplete is broken for routes
#2045267: LocalTaskBase and LocalTaskInterface has to work with routes containing parameters
#2048969: LocalActionBase and LocalActionInterface has to work with routes containing parameters
#2040065: Remove _account from request and use the current user service instead. (partially)
#2040379: Define contextual entity operations through annotation; remove the context property from hook_menu items

add 2031487

The changes to core.services.yml were next to the newly added CSRF stuff, just a straight reroll.

#22 asks what to even profile here...

Well the thing to profile would be when the method gets used a lot of times on the same page. Looks like we've got use cases for this but it's going to be local tasks and contextual links that are the worst which probably isn't so bad. My concern would be if start calling this on regular menu links so in turn create dozens or hundreds of request objects for each access check (not that the performance of that isn't already terrible in general). But we're not doing that yet and might not.

So... committed/pushed to 8.x.

Let's figure out first how to do it for local tasks/actions and then discuss how to do it for menu links, because to be honest menu_item_route_access() is doing that already, so we should try to improve the performance here.

Wrote a changenotice: https://drupal.org/node/2078997

Untagging. Please remove the tag when the change notification task is completed.

updated