Incorrect base url paths being used on different pages

[PylotLight]

While this is similar to #94 I wanted to highlight specific behaviours which are not working properly.
I was able to rebuild frontend to get assets working via relative ./ path.
Pages like collections or the run actions on quickstart use or need their own path different from the current url pathing however, which currently isn't working.
e.g
https://subdomain.company.com/subpath1/subpath2/dashboard/#/welcome works for loading assets via ./
However clicking RUN uses */dashboard/collections/star_charts instead of /collections/star_charts and fails.
*/dashboard/#/collections api in the background should also be loading from */collections instead of root path /collections.

[ozdreamwalk]

I'm seeing a similar issue with my docker / traefik installation:
When loading the dashboard console or collections it seems fine (you also see the GET issued correctly

2024-11-15T23:10:25.037495Z  INFO actix_web::middleware::logger: 172.19.0.2 "GET /dashboard/ HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0" 0.000266

But when using the dashboard console RUN with for instance that command:
GET collections
It uses /dashboard/ as a prefix somehow and fails

2024-11-15T23:10:25.356176Z DEBUG actix_files::service: error handling /dashboard/issues: No such file or directory (os error 2)
2024-11-15T23:10:25.356223Z  INFO actix_web::middleware::logger: 172.19.0.2 "GET /dashboard/issues HTTP/1.1" 404 0 "https://qdrant.n8n-myserver.de/dashboard/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0" 0.000184
2024-11-15T23:10:25.599541Z  INFO actix_web::middleware::logger: 172.19.0.2 "GET /collections HTTP/1.1" 200 109 "https://qdrant.n8n-myserver.de/dashboard/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0" 0.000355
2024-11-15T23:10:37.970900Z DEBUG actix_files::service: error handling /dashboard/collections: No such file or directory (os error 2)
2024-11-15T23:10:37.970964Z  INFO actix_web::middleware::logger: 172.19.0.2 "GET /dashboard/collections HTTP/1.1" 404 0 "https://qdrant.n8n-myserver.de/dashboard/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0" 0.000275

Interestingly, it seem to work on different browsers (Edge/Chrome not working, BRAVE working) and different networks (Homenetwork/Office)
I can not rule out my setup, as I'm also using Docker with traefik and Cloudflare. But the mentioned bug seems fit.

[PylotLight]

I've already implemented workarounds for our company platform with some custom code changes and building from source to resolve this issue internally.. so it's definitely possible, hopefully the team can sort it out for everyone..

[ozdreamwalk]

OK; seems a quick fix with the config worked well.

in docker-compose.yml

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.qdrant.rule=Host(`qdrant.n8n-myserver.de`) && PathPrefix(`/qdrant`,`/cluster`,`/dashboard`,`/collections`,`/telemetry`)"
      - "traefik.http.routers.qdrant.entrypoints=websecure"
      - "traefik.http.routers.qdrant.tls.certresolver=cloudflare"
      - "traefik.http.services.qdrant.loadbalancer.server.port=6333"
      - "traefik.http.routers.qdrant.middlewares=qdrant-auth"
      - "traefik.http.routers.qdrant.middlewares=secureHeaders@file"

in traefiks config.yml:

  middlewares:
......  
    secureHeaders:
      headers:
        stsSeconds: 31536000
        browserXssFilter: true
        contentTypeNosniff: false 
        forceSTSHeader: true
        stsIncludeSubdomains: true
        stsPreload: true
        frameDeny: false  
        customFrameOptionsValue: "SAMEORIGIN"
        contentSecurityPolicy: "frame-ancestors 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"

This seems to do the trick