Feat: support for service deployments behind PathPrefix proxy rules

Deploying a service behind a reverse proxy matching a PathPrefix requires that all paths in the service respect the PathPrefix. When deploying a service with such a rule, you must strip the prefix and add it as the X-Forwarded-Prefix header to the request.

Example

Lets say you deploy a service on your host and expose it on port 8001. Taking traefik as our reverse proxy would work like this: The following file provider shows a service route with a PathPrefix as routing rule.

dynamic file provider config _/etc/traefik/dynamicconf/my-service-config.yml

http:
  routers:
    my-service-route:
      rule: PathPrefix(`/my-service`)
      entryPoints:
        - web
      service: my-service
      middlewares:
        - strip-prefix
  services:
    my-service:
      loadBalancer:
        servers:
          - url: http://127.0.0.1:8001
  middlewares:
    strip-prefix:
      stripprefix:
        prefixes: /my-service

static config /etc/traefik/traefik.yml

providers:
  file:
    filename: /etc/traefik/dynamic_conf/my-service-config.yml
entrypoints:
  web:
    address: ":80"

The stripprefix middleware strips this prefix, adding it as X-Forwarded-Prefix header to the request. Pydase can act on this passed prefix! The backend registers this prefix and writes it to the index HTML, like so:

<head>
...
</head>
<script>
    window.__FORWARDED_PREFIX__ = "";  // this will be set by the python backend if the service is behind a proxy which strips a prefix. The frontend can use this to build the paths to the resources.
</script>`
<body>
</body>

The frontend can use this global variable to build the resource paths.

tiqi-group / pydase

Feat: support for service deployments behind PathPrefix proxy rules #167

Example