EntityToJsonapi service does not respect overridden routes

@logickal any chance you can give this a try before starting to fix tests?

I feel this will deserve dedicated testing. Maybe normalizing a user with and without the proper permissions?

1. +++ b/src/EntityToJsonApi.php
   @@ -22,14 +25,44 @@ class EntityToJsonApi {
   +    $this->session = $request->hasPreviousSession()
   +      ? $request->getSession()
   +      : $session;
   
   @@ -42,15 +75,25 @@ class EntityToJsonApi {
   +    if ($this->session) {
   +      $request->setSession($this->session);
   +    }
   

   Session handling is complex. I can't vouch for this being correct. It'd require digging very deep in Drupal and Symfony internals.

   Given that it seems to be working for both @logickal and @e0ipso (and testbot), I think this is probably fine.

2. +++ b/src/EntityToJsonApi.php
   @@ -42,15 +75,25 @@ class EntityToJsonApi {
   -    $jsonapi_url = Url::fromRoute($route_name, ['entity' => $entity->uuid()])->toString(TRUE)->getGeneratedUrl();
   ...
   +    $jsonapi_url = Url::fromRoute($route_name, ['entity' => $entity->uuid()])
   +      ->toString(TRUE)
   +      ->getGeneratedUrl();
   

   Unnecessary change, was confused by this (wondering: "huh, what is different?!").

3. +++ b/src/EntityToJsonApi.php
   @@ -42,15 +75,25 @@ class EntityToJsonApi {
   +    $resource_type_name = $this->resourceTypeRepository
   +      ->get($entity->getEntityTypeId(), $entity->bundle())
   +      ->getTypeName();
   +    $route_name = sprintf('jsonapi.%s.individual', $resource_type_name);
   

   Ah, so this is what we were missing :)

(Marked as Needs review so that automated testing kicks in; then we'd at least know that our current tests still pass.)

Thanks for taking a look Wim!

Unnecessary change, was confused by this (wondering: "huh, what is different?!").

Well, it was running beyond 80 characters. The linter took care of it.

Even if the session handling is right I don't think we can ensure authentication is properly propagated to the HTTP subrequests. What if we are authenticating the master via an HTTP header, or a qs parameter, or some obscure auth provider? Will subrequests inherity the "current user" properly?

What if we are authenticating the master via an HTTP header, or a qs parameter, or some obscure auth provider?

That's what \Symfony\Component\HttpFoundation\Request::create()'s $server parameter is for (PHP $_SERVER contains HTTP request headers — yes this is weird, this is PHP's legacy sadly). CommentController's subrequest handling does do this.

So it seems that I introduced two bugs in #3035045: Make EntityToJsonApi use subrequests so that it never breaks again:

1. not respecting resource type name aliasing (that's what the issue title says)
2. not passing on all information from the master request to the subrequest

WRT point 2, I did that kind of intentionally. I've always have been and still am concerned about using this service to generate information for anonymous consumption while in an authenticated user's context, because that would leak information only accessible to the authenticated user to the general public. But clearly I have to admit defeat here since people do want to use it in this way. OTOH this means I think this can never ever get into Drupal core; it's too easy and hence too dangerous to get wrong.

So… ported that same logic from CommentController's subrequest handling. Patch still needs to be cleaned up, but this gets the gist across.

I think that with #11's interdiff, all of the things in #8.1 can be removed.

1. +++ b/src/EntityToJsonApi.php
   @@ -42,15 +76,26 @@ class EntityToJsonApi {
   +    $query = $request->query->all();
   

   This is probably going to cause an error if the request calling this service contains a non-jsonapi approved qs parameter.

2. +++ b/src/EntityToJsonApi.php
   @@ -42,15 +76,26 @@ class EntityToJsonApi {
   +    $request = Request::create($jsonapi_url, 'GET', $query, $request->cookies->all(), [], $request->server->all());
   

   :clap:

   also, how is $_SERVER still a thing?! Oh… PHP.

3. +++ b/src/EntityToJsonApi.php
   @@ -42,15 +76,26 @@ class EntityToJsonApi {
   +      $request->setSession($this->session);
   

   Now that we are passing cookies. I think that cookie-less sessions that are relevant can be considered an edge case. If so, this makes me a bit nervous to have it here.

1. Yep. I think we can choose to not retain the master request's query string TBH; authentication would nearly always happen through request headers. We can leave supporting that as a future enhancement.
2. :)
3. See #12 :)