Problem/Motivation

I will try to explain the following issue as precise as I possibly can.

Currently I am working on a project which uses profile installation and imports config on installation on a local VM. The Drupal installation runs on 192.168.42.42 or vm (as pseudo-domain). The project makes also use of REST and imports rest.settings.yml on installation like

resources:
  'entity:bookmark':
    GET:
      supported_formats:
        - hal_json
      supported_auth:
        - basic_auth
    POST:
      supported_formats:
        - hal_json
      supported_auth:
        - basic_auth
link_domain: null

The request is based on the following information (I am currently using PHPStorm's build in REST test so no cUrl, Sorry!)

X-CSRF-Token: <Get some token from rest>
Authorization: Basic <some base64>
Accept: application/hal+json
Content-Type: application/hal+json
POST http://192.168.42.42/entity/bookmark?_format=hal_json
DATA {   "_links":{     "type":{       "href":"http://192.168.42.42\/rest\/type\/bookmark\/bookmark"     }   },  [...]  }

This configuration should allow me to send POST requests to Drupal as soon as the Drupal installation finishes - assuming all code and settings regarding entities are correct. However, any POST requests which yields any other href than "localhost" (I will come to this soon) fails with the following error (or similar).

{
  "error":"Type http:\/\/192.168.42.42\/rest\/type\/bookmark\/bookmark does not correspond to an entity on this site."
}

I was baffled because I knew this should work and It did some time in development so I went into debugging hell.
I looked up the part where the Exception would be thrown and went further from that. TypeLinkManager does for some reason cache a uri called "localhost" (see ::getTypeUri() for that) into cache_default. This will skip the part where getTypes should try to work on http://192.168.42.42 because the if-clause will fail. So when I am trying to look up the resource for http://192.168.42.42 Drupal fails and gives me the error above.

The error would maybe go away after some random time but effectively could be prevented with adding trusts_host_patterns in settings.php.
Another solution was to change the data in my request

DATA {   "_links":{     "type":{       "href":"http://localhost\/rest\/type\/bookmark\/bookmark"     }   },  [...]  }

which makes no sense from my point of view.

Hopefully I could describe by problem above and someone can decide whether this is a behaviour by design or a bug or just not well documented.

Comments

steamx created an issue. See original summary.

dawehner’s picture

Note: you can configure a different local domain if you want:

  protected function getLinkDomain() {
    if (empty($this->linkDomain)) {
      if ($domain = $this->configFactory->get('rest.settings')->get('link_domain')) {
        $this->linkDomain = rtrim($domain, '/');
      }
      else {
        $request = $this->requestStack->getCurrentRequest();
        $this->linkDomain = $request->getSchemeAndHttpHost() . $request->getBasePath();
      }
    }
    return $this->linkDomain;

Would that solve the problem for you?

Wim Leers’s picture

Status: Active » Postponed (maintainer needs more info)
steamx’s picture

Changing the link_domain in the configuration file works fine for me. I am just curious if localhost should be the default value for link_domain.
For my workflow I don't really care which domain is present in _link though I could work around that problem with simply using json instead of hal+json. Besides it seem to be more secure to use localhost by default.

You may consider this problem to be solved.

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Fixed

I am just curious if localhost should be the default value for link_domain.

It would be, if you were actually accessing Drupal via http://localhost too. It looks like you were accessing Drupal via http://192.168.42.42. Which is okay. But an extreme edge case. 99.99% of the time, I've seen people use local domains. Like drupal.dev, d8.dev, customername.dev or just localhost.

So, considering you also said this was solved, I'm marking this fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.