Shlink Web Client can cURL successfully to shlink API on Docker network, but adding the server in the web client UI fails

[andrewvaughan]

Shlink version

4.2.0

PHP version

Whatever is in Docker

How do you serve Shlink

Docker image

Database engine

MySQL

Database version

n/a

Summary

I have a shlink container and a shlink-web container for the web client. Both are loading and functioning as expected on their own, but getting them to connect with each other is causing issues.

I have a backend network connecting the two, and I have no issue accessing my shlink container using cURL on the shlink-web instance:

andrew@iron01:~$ sudo docker exec -it shlink-web curl -I http://shlink:8080/rest/health
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: application/health+json
X-Request-Id: 7ee72215-6707-4a99-9d5d-b7db85f6a65b
Date: Wed, 18 Sep 2024 15:16:16 GMT

I also have a pre-set API key within my Docker configuration that shows, as expected:

$ sudo docker exec -it shlink shlink api-key:list
+--------------------------------------+------+------------+-----------------+-------+
| Key                                  | Name | Is enabled | Expiration date | Roles |
+--------------------------------------+------+------------+-----------------+-------+
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | -    | +++        | -               | Admin |
+--------------------------------------+------+------------+-----------------+-------+

However, whenever I add these credentials within my self-hosted shlink-web interface, I get:

Oops! Could not connect to this Shlink server.

Make sure you have internet connection, and the server is properly configured and on-line.

For reference, here is my docker-compose.yml for the services. I use a Traefik reverse proxy:

services:
  # ...
  
  shlink:
    container_name : "shlink"
    image          : "shlinkio/shlink:latest"

    # Common DNS configs, etc; can ignore.
    <<: *common

    depends_on:
      postgres-common:
        condition: "service_started"

    networks:
      - "shlink-backend"
      - "postgres-backend"

    environment:
      DEFAULT_DOMAIN: "redacted"
      IS_HTTPS_ENABLED: true  # Does not seem to make a difference if set or not
      GEOLITE_LICENSE_KEY: "redacted"
      INITIAL_API_KEY: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

      DB_DRIVER: "postgres"
      DB_NAME: "shlink"
      DB_USER: "shlink"
      DB_PASSWORD: "redacted"
      DB_HOST: "postgres-common"

  shlink-web:
    container_name : "shlink-web"
    image          : "shlinkio/shlink-web-client"

    <<: *common

    depends_on:
      shlink:
        condition: "service_started"

    networks:
      - "reverse-proxy"
      - "shlink-backend"

    volumes:
      - "./shlink/servers.json:/usr/share/nginx/html/servers.json"

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=reverse-proxy"
      
      # TODO - shlink is causing an infinite redirect - using Cloudflare SSL for now
      # Use Let's Encrypt for certificate management over HTTPS
      #- "traefik.http.routers.shlink.rule=Host(`redacted`)"
      #- "traefik.http.services.shlink.loadbalancer.server.port=8080"
      #- "traefik.http.routers.shlink.entrypoints=websecure"
      #- "traefik.http.routers.shlink.tls.certresolver=lets-encrypt"

      # Redirect HTTP to HTTPS
      #- "traefik.http.routers.shlink-http.rule=Host(`redacted`)"
      #- "traefik.http.routers.shlink-http.entrypoints=web"
      #- "traefik.http.routers.shlink-http.middlewares=redirect-to-https@file"

      - "traefik.http.routers.shlink-http.rule=Host(`redacted`)"
      - "traefik.http.routers.shlink-http.entrypoints=web"
      - "traefik.http.services.shlink.loadbalancer.server.port=8080"

Additionally, here is my server config (although, it also fails if I enter it directly into the UI):

[
  {
    "name": "Homelab Shlink Backend",
    "url": "http://shlink:8080",
    "apiKey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  }
]

I'm not entirely sure what I'm doing wrong, but it very well could be user error. What's confusing to me is being able to access the /rest/health endpoint without issue from the web client container, but that is apparently failing (?) when done through the app.

[andrewvaughan]

Disregard, but I'll leave this up for anyone in the same situation. It wasn't clear to me that the web client was only a browser client and needed WAN access to the backend API. Not my favorite architecture choice in the world...