Pomerium: Destination (To:) path not followed since v0.9.X

Created on 2 Jul 2020  路  5Comments  路  Source: pomerium/pomerium

What happened?

Pomerium is no longer respecting paths in the destination (To:) of the proxied request. This was working fine with v0.8.3.
Currently I dont see another way of providing destination paths. (as far as I can see I can only specify incoming paths)

Example:

# Some Policy
  - from: https://some.domain.com
    to: http://192.178.198.25:8887/folder
    allow_public_unauthenticated_access: true
    allow_websockets: true

In version 0.8.3 this is linking https://some.domain.com to http://192.178.198.25:8887/folder.
So when requesting https://some.domain.com/test/picture.jpg it should link to http://192.178.198.25:8887/folder/test/picture.jpg

Version bigger 0.8.3:
Insted it is linking to http://192.178.198.25:8887/test/picture.jpg without folder.
Or the other way around I have to open https://some.domain.com/folder/test/picture.jpg to get to https://some.policy.com/test/picture.jpg

What did you expect to happen?

The proxied request should be forwarded to the specified URL including the path.

How'd it happen?

  1. Updated my pomerium installation from v0.8.3 to 0.10rc1

What's your environment like?

  • v0.10.0-rc1
  • Ubuntu 20.04, Pomerium inside docker

What's your config.yaml?

docker compose
version: "2"
services:
  pomerium:
    container_name: pomerium
    image: pomerium/pomerium:latest
    environment:
      - AUTHENTICATE_SERVICE_URL=https://authenticate.domain.com
      - AUTOCERT=true
      - AUTOCERT_USE_STAGING=false
      - AUTOCERT_DIR=/pomerium/certs/
      - IDP_PROVIDER=google
      - IDP_CLIENT_ID=XXX.apps.googleusercontent.com
      - IDP_CLIENT_SECRET=XXX
      - COOKIE_SECRET=XXX
      - ADMINISTRATORS="[email protected]"
      - HTTP_REDIRECT_ADDR=:80
    volumes:
      - pomerium_config:/pomerium/
    ports:
      - 80:80
      - 443:443
    restart: always

What did you see in the logs?

Are these needed?

Additional context

As far as I can see this happens since the v0.9.X release.

backport 0-9-0 bug

Most helpful comment

@fightforlife Thanks for reporting, this should be fixed in #1034

All 5 comments

@fightforlife Thanks for reporting, this should be fixed in #1034

@cuonglm I have another issue/question quite close to this. I just tested this with the :master tag.

A note to #1034: one needs to add a final "/" in the to: to get it working. This could be misleading I guess.

# Some Policy
  - from: https://some.domain.com
    to: http://192.178.198.25:8887/folder/  <- final / needed

Here is another usecase which is not working for me (Nextcloud with Onlyoffice). Onlyoffice should be available in the /office/ directory since SAMEORIGIN is enforced.

I want http://192.168.1.2:47112/healthcheck to be available under https://cloud.domain.com/office/healthcheck with the following policy.

#Onlyoffice+Nextcloud
  - from: https://cloud.domain.com
    to: http://192.168.1.2:47112  <- Onlyoffice
    prefix: /office
  - from: https://cloud.domain.com
    to: http://192.168.1.2:8888 <- Nextcloud

But when opening https://cloud.domain.com/office/healthcheck it links to http://192.168.1.2:47112/editors/healthcheck (so it passes the /office/ path. Is there a way to not use the original request or translate it to the destination?

Thanks in advance!
best regards

Edit: I got it working with this. So I guess the final / is really important

#Onlyoffice+Nextcloud
  - from: https://cloud.domain.com
    to: http://192.168.1.2:47112/  <- Onlyoffice
    prefix: /office/
  - from: https://cloud.domain.com
    to: http://192.168.1.2:8888 <- Nextcloud

@fightforlife the trailing slash is working as expected, since when you can't rewrite /prefix to / and /prefix/foo to /foo in one route.

You need 2 rules to do that.

Maybe a documentation is necessary.

About your 2nd problem, would you mind trying with prefix /office/ instead? If it won鈥檛 work, please open another issue with redacted configuration.

For anyone finding this via google while setting up Nextcloud + Onlyoffice + Pomerium.

Normally one should not specify the host in X-Forwarded-Host: but instead use a variable. But for me this was not working with $the_host/office and $host/office. The redirect was corrupted.

#Nextcloud OnlyOffice
  - from: https://cloud.domain.com
    to: http://192.168.1.2:47112/
    prefix: /office/
    set_request_headers:
        X-Forwarded-Host: cloud.domain.com/office
        X-Forwarded-For: $proxy_add_x_forwarded_for
        X-Forwarded-Proto: https
        X-Forwarded-Port: 443

  - from: https://cloud.domain.com
    to: http://192.168.1.2:8888

@fightforlife See https://github.com/pomerium/pomerium/pull/1040

Edit: I got it working with this. So I guess the final / is really important

Yes, in case you don't use prefix or your destination path is root. If you use prefix, then the trailing slash is not necessary. Or if your destination path is not empty, like in:

  - from: https://httpbin.localhost.pomerium.io
    prefix: /foo
    to: https://httpbin.org/anything

Then:

  • https://httpbin.localhost.pomerium.io/foo -> https://httpbin.org/anything
  • https://httpbin.localhost.pomerium.io/foo/bar -> https://httpbin.org/anything/bar
Was this page helpful?
0 / 5 - 0 ratings