Open gc-ss opened 2 years ago
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?
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.
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:
caddy-docker-proxy
, again, without "risking" exposing a TCP port
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:
generates the expected JSON on load:
but very quickly updated by
caddy-docker-proxy
to: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 theenforce_origin
andorigins
be respected.let me know what you think about this :eyes: