Exposing/Running directus on a port other than 8055 prevents the admin app from loading

[gerolds]

Describe the Bug

Exposing/Running directus on a port other than 8055 prevents the admin app from loading. Broken since rc.84.

To Reproduce

try to access localhost:8080 from compose.yaml:

services:
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: directus
      POSTGRES_PASSWORD: directus
      POSTGRES_DB: directus
    networks:
      - default

  directus:
    image: directus/directus:9.0.0-rc.85
    ports:
      - 8080:8055
    depends_on:
      - db
    environment:
      KEY: directus
      SECRET: directus
      ADMIN_EMAIL: user@example.com
      ADMIN_PASSWORD: directus
      DB_CLIENT: pg
      DB_HOST: db
      DB_PORT: 5432
      DB_DATABASE: directus
      DB_USER: directus
      DB_PASSWORD: directus
    networks:
      - default

networks:
  default:

What version of Directus are you using?

9.0.0.rc.85

What version of Node.js are you using?

official docker image

What database are you using?

official docker image

What browser are you using?

Chrome

What operating system are you using?

Windows

How are you deploying Directus?

docker compose

[gerolds]

Running directus on port 8080 via .env will surface the same issue.

[helge000]

This issue started with rc.84. It seems a static port 8055 used in the returned html:

[rijkvanzanten]

Make sure to set the PUBLIC_URL environment variable correctly 👍🏻

[helge000]

@rijkvanzanten , what is the reasoning here? The problem: If I want a proxy in my stack, I'll deploy one. The app should not be a proxy in itself.

[rijkvanzanten]

This isn't about proxying. The issue is static asset retrieval in a SPA context. People run Directus in all sorts of contexts, paths, and subfolders. The only way the app can accurately do routing and asset retrieval is by having the correct path to the base URL. Secondly, as per the docs, Directus uses this public url for things like password-reset links in emails, oAuth redirect paths, public logo retrieval etc etc.

[helge000]

I can see your reasoning as we may need something like it in prod envs. However in doing so, basic container functionality is broken.

Maybe it would be an option to get the pre rc-84 behaviour back simple boolean env; or by setting PUBLIC_URL=false.

In our dev setup, we do not need advanced stuff like email and oAuth or accessing assets other then local.The current design, requiring PUBLIC_URL to be set, makes it nearly impossible to write a compose file for our developers as I do not have fancy rendering functions here. My only option is to drop this feature - forcing people to a single running directus container.

[rijkvanzanten]

the only thing that changed is that the docker image now uses whatever default value is set in directus itself. you can still set it to PUBLIC_URL="/"

[helge000]

Thanks @rijkvanzanten , this works great for me

[rijkvanzanten]

Sweet! I've also opened a PR to set the actual default value of PUBLIC_URL to / (which mimics the previous docker behavior) #6860, and we've already merged a PR that will show a little warning in stdout when a non-URL public_url is used #6840, which together should take care of the confusion, while still maintaining enough heads-up for prod users that the env var has to be set 👍🏻