Interest in enabling `enforce_origin` and `origins`?

[gc-ss]

There's some interest over at the caddy forum about enabling enforce_origin: https://caddy.community/t/2-5-0-enforce-origin-bug/15764

(EDIT: Now fixed in caddy https://caddy.community/t/should-enforce-origin-and-origins-work-over-the-unix-socket/15849)

However, a set of annotations for caddy-docker-proxy like:

    labels:
      caddy.admin: "unix//tmp/http.sock"
      # origins configures the list of remotes/origins that are allowed to connect to the endpoint.
      caddy.admin.origins: "unixsocket"  # https://github.com/caddyserver/caddy/commit/c2327161f725c820826587381f37d651a2b9736d#diff-308a4ab4e9e209d390d0cb79a9301a0f7e9768564a3b3489055bf1f0a3f8a775L655
      # enforce_origin enables enforcement of the Origin header. (This is different from enforcing origins generally, which is always done)
      caddy.admin.enforce_origin: ""

generates the expected JSON on load:

       "admin":{
          "listen":"unix//tmp/http.sock",
          "enforce_origin":true,
          "origins":[
             "unixsocket"
          ]
       },

but very quickly updated by caddy-docker-proxy to:

        "admin":{
          "listen":"tcp/localhost:2019"
        },

While it would be awesome to support unix sockets in caddy-docker-proxy (how do you feel about it?), my immediate interest is in having the enforce_origin and origins be respected.

let me know what you think about this :eyes:

[lucaslorentz]

caddy-docker-proxy uses admin API to update caddy with new caddyfile Before updating, it patches the caddyfile admin section, so it cannot lose the permission to update again.

My first thought would be to stop using admin API when caddy needs to update itself when running in standalone mode. That would allow you to configure the admin API however you want.

What is your use case? Do you have a single caddy instance (standalone) running and want to expose the caddy admin API to some frontend application?

[tylergets]

I am not OP but I am running into this right now as well, I am attempting to expose the Caddy API for an application which will be grabbing info about the SSL certificates for our internal web portal.

Update: After taking a small looking at the code, I think a good medium here could be to introduce a new enviroment variable that allows additional origins.

[gc-ss]

I think a good medium here could be to introduce a new enviroment variable that allows additional origins.

Like the idea!

Before updating, it patches the caddyfile admin section, so it cannot lose the permission to update again

@lucaslorentz First, thank you for building this. Great project

Makes sense - although, "listen":"unix//tmp/http.sock", won't make you lose the permission to update either.

Are you aware of where the changes would need to be made? I know you're busy, so happy to shoot a PR your way in 2 weeks or so, if you can guide.

What is your use case? Do you have a single caddy instance (standalone) running and want to expose the caddy admin API to some frontend application?

No:

• to pull in the caddy config and ensure it's as expected (i.e. detect any unintended drift and during CI) without "risking" exposing a TCP port
• to push out changes that won't be managed by caddy-docker-proxy, again, without "risking" exposing a TCP port