Setting up developer portals

Support Installation and Deployment
1

I’m having some issues setting up the Tyk Portal with correct settings.

What I want is:

  • api.my-org.org → a portal
  • ui.my-org.org → the dashboard

Both domain names are registered as CNAMEs, and points to a single host that currently runs the dashboard (v1.0.0.0), and the dashboard is configured to listen on port 443 with the SSL settings enabled. The dashboard works as expected, but the portal pages doesn’t.

I have one single organization:

{
  "owner_name" : "my-org",
  "owner_slug" : "",
  "cname_enabled" : true,
  "cname" : "api.my-org.org",
  …
}

And my tyk_analytics config is:

{
  "host_config": {
    "enable_host_names": false,
    "disable_org_slug_prefix": true,
    "hostname": "ui.my-org.org",
    "override_hostname": "",
    "portal_domains": {},
    "portal_root_path": "/portal"
  },
  "http_server_options": {
    "use_ssl": true,
    "certificates": [
      {
        "domain_name": "*.my-org.org",
        "cert_file": "/path/to/cert.pem",
        "key_file": "/path/to/key.pem"
      }
    ],
    "min_version": 2
  },
  …
}

I think I’ve tried every concievable way to configure the host_config settings and the tyk_analytics.tyk_organisation objects, but I cannot get the portal pages to work:

  • The «Open Your Portal» url from the Dashboard always points to a http:// address
  • Going to `https://api.my-org.org/portal/ always results in a 404

How should I configure the dashboard and the organisation object in order to make this work?

2

This looks ok to me… but:

Have you tried removing the trailing slash from the request you are trying? i.e.: https://api.my-org.org/portal

3

No, both https://api.my-org.org/portal and https://api.my-org.org/portal/ gives me a 404.

I should probably add – I’m unable to set the cname org setting using the «Set your portal domain» option in the Dashboard («There was a problem updating your CNAME, please contact support», level=error msg=“INvalid domain supplied, not saving: api.my-org.org” in the logs).

Also, regardless of whether the cname and cname_enabled settings are set, both https://<ip>/<org-id>/portal and https://<ip>/<org-id>/portal/ works as expected (except none of the URLs).

Is there a way to get the Dashboard to log more (log level DEBUG or similar) and maybe figure out what happens when the 404 page is served?

4

Your problem lies here

Missed it in my delirium of jetlag yesterday. You need to tell Analytics to respect hostnames, because it will stop the IP form working, you need:

"host_config": {
    "enable_host_names": true,
     ...
5

Ah, never touched that option.

That helped a bit – If I turn SSL off and serve at port 80, everyting works as expected. But if i turn SSL on and change the listen_port to 443, I now get 404 on both api.my-org.org and ui.my-org.org…

I decided to dig a little, and it seems there are some problems with port numbers in the Host header.

  • When serving at port 80, the following happens:
    • Host: sub.domain.org → OK
    • Host: sub.domain.org:80 → 404
  • and on any other port N:
    • Host: sub.domain.org → 404
    • Host: sub.domain.org:N → OK

The latter one causes problems, because browsers generally don’t include the port number in the header field when accessing a https:// url…

6

Ah, I think you’ve found a bug :slight_smile: We only normalise the listen host on pot 80, will add a fix so that it compiles to the nightlies.

[edit] That’s been pushed now - check our nightlies for the dashboard tarball, you should just need to replace the binary