Preview link can return AccessResult::forbidden for entity reference fields rendered on the preview route

+++ b/preview_link.module
@@ -75,8 +75,24 @@ function preview_link_entity_access(EntityInterface $entity, $operation, Account
+  $route_match = \Drupal::routeMatch();
+  $entity_type_ids = array_keys(\Drupal::entityTypeManager()->getDefinitions());
+  $route_entity = NULL;
+  foreach ($entity_type_ids as $entity_type_id) {
+    if ($route_entity = $route_match->getParameter($entity_type_id)) {
+      break;
+    }
+  }

I wish core should provide an API for this. Here is another issue #3047936: Generic support for any entity type where we wanted to do the same

Also, see the discussion after #18 in #2847224: Add views argument_default for getting Entity ID from URL.

+++ b/preview_link.module
@@ -75,8 +75,24 @@ function preview_link_entity_access(EntityInterface $entity, $operation, Account
+  $route_match = \Drupal::routeMatch();
+  $entity_type_ids = array_keys(\Drupal::entityTypeManager()->getDefinitions());
+  $route_entity = NULL;
+  foreach ($entity_type_ids as $entity_type_id) {
+    if ($route_entity = $route_match->getParameter($entity_type_id)) {
+      break;
+    }
+  }

This should probably get the route option preview_link.entity_type_id, similar to PreviewLinkController::resolveEntity, instead of iterating parameters.

edit: See below

I wish core should provide an API for this. Here is another issue #3047936: Generic support for any entity type where we wanted to do the same

301 #3138465: Add a generic entity route context

--

Uploaded reroll + 7 feedback

Actually I think I may have gotten the intent of the change wrong :/ In which case a new test is necessary.

Just the reroll

Making a list of issues which would find service outlined in #3138465: Add a generic entity route context useful.

1. +++ b/preview_link.module
   @@ -69,10 +69,26 @@ function preview_link_entity_access(EntityInterface $entity, $operation, Account
   +  $route_match = \Drupal::routeMatch();
   +  $entity_type_ids = array_keys(\Drupal::entityTypeManager()->getDefinitions());
   +  $route_entity = NULL;
   +  foreach ($entity_type_ids as $entity_type_id) {
   +    if ($route_entity = $route_match->getParameter($entity_type_id)) {
   +      break;
   +    }
   +  }
   

   Could simplify with the following?

     $route_match = \Drupal::routeMatch();
     $route_entity = NULL;
     if ($preview_link_entity_type = $route_match->getRouteObject()->getOption('preview_link.entity_type_id')) {
       $route_entity = $route_match->getParameter($preview_link_entity_type);
     }
   

2. +++ b/preview_link.module
   @@ -69,10 +69,26 @@ function preview_link_entity_access(EntityInterface $entity, $operation, Account
   +  // Only run our access checks on the entity we're previewing.
   +  if ($route_entity instanceof ContentEntityInterface && $route_entity->id() === $entity->id()) {
   +    return \Drupal::service('access_check.preview_link')->access($entity, $route_match->getParameter('preview_token'));
   +  }
   

   What if two different entity types have the same ID?

3. I guess the last thing to sanity check would be the cacheability. It seems okay to me, since I don't think access results themselves are cached, they just inform the cacheability of the objects the entities are embedded in? Ie, for a specific entity returning neutral on preview link route A and allowed on preview link route B is fine because they are two different routes?

   Still not completely sure, it's a bit mind bending...

Also failing to apply.

Just a re-roll.

The calls out to routematch in an access always scare me so much, considering history in this project. So long as we have coverage should be alright.

CI reports a minor CS error.

For caution sake, can we make sure we tag this as a non stable release (alpha/beta/RC) and have it get a little bit of usage before we release it widely.