2.5.0 enforce_origin bug

[Jeff_Galbraith]

1. Caddy version (caddy version):

v2.5.0 h1:eRHzZ4l3X6Ag3kUt8nj5IxATprhqKq/wToP7OHlXWA0=

2. How I run Caddy:

systemd

a. System environment:

Ubuntu 20.04.3

b. Command:

Paste command here.

n/a

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

  "admin": {
    "enforce_origin": true,
    "listen": "localhost:2019"
  },
  "apps": {
    "http": {
      "servers": {
        "ivt_https": {
          "automatic_https": {
            "disable_redirects": true
          },
          "listen": [
            ":443"
          ],
          "routes": [
...

3. The problem I’m having:

Cannot connect to caddy on the admin url

4. Error messages and/or full log output:

From the command line:

$ curl localhost:2019/config/
{"error":"client is not allowed to access from origin ''"}

5. What I already tried:

Tried restarting caddy

Found this for 2.5.0-beta.1 and supposedly fixed: Bug in enforce_origin?
But it’s not…

I just upgraded today and after a reboot, this is happening.

6. Links to relevant resources:

[Jeff_Galbraith]

If I try to access the admin endpoint from a different computer, I get a “Connection refused” error as expected.

[matt (Matt Holt)]

Isn’t that working as expected? You have origin enforcement enabled, but you didn’t set any Origin header.

[Jeff_Galbraith]

Is that supposed to happen in the JSON file or the originating request?

This was working as expected until 2.5.0

If it’s the JSON file, are we now locked out until we fix it on each machine? To fix, would we have to have it load a generic Caddy file, then re-insert our JSON with the fixes?

Looking for the solution with the path of least resistance.

Thank you for your help and insights.

[matt (Matt Holt)]

Sorry for the inconvenience. We fixed bugs related to origin enforcement, so unfortunately the expectation apparently relied on buggy behavior.

@Jeff_Galbraith

Is that supposed to happen in the JSON file or the originating request?

In the request. Origin enforcement is documented as:

If true, CORS headers will be emitted, and requests to the API will be rejected if their Host and Origin headers do not match the expected value(s). Use origins to customize which origins/hosts are allowed. If origins is not set, the listen address is the only value allowed by default. Enforced only on local (plaintext) endpoint.

So set the Origin header on your request: Origin: http://localhost:2019.

@Jeff_Galbraith

If it’s the JSON file, are we now locked out until we fix it on each machine? To fix, would we have to have it load a generic Caddy file, then re-insert our JSON with the fixes?

You’re not locked out. You can use caddy load for example. Or just set the Origin header in your request to the proper value.

Hope that helps!

[Jeff_Galbraith]

This worked when added to axios header content:

Origin: http://localhost:2019

Thank you

[Jeff_Galbraith]

I have found one more issue in regards to this.

We have an installer, and it calls “sudo caddy trust” and if this is the first time run, where we have not added our JSON, this works. But, once JSON is added, running a new installer instance is having an issue.

$ sudo caddy trust --address "http://localhost:2019"
trust: requesting CA info: performing request: Get "http:///localhost:2019/pki/local/certificates": http: no Host in request URL

I am not sure if this is a visual display or if it actually added 3 forward slashes here: http:/// and tried to use that.

Or, maybe, I am just doing it wrong.

[francislavoie]

Well, two things. First, the address should just be the domain/port, should not include the scheme. It’s the same thing as you would have in your config.

Second, we only noticed right after releasing v2.5.0 that we had a bug with caddy trust that broke it completely. We fixed it here caddypki: Fix `caddy trust` command to use the correct API endpoint (… · caddyserver/caddy@d543ad1 · GitHub so for now, build from that commit. Sorry!

[Jeff_Galbraith]

Thanks for the update. Any idea on release availability?

About the scheme, I tried it first without and it comes back with 404 not found

[francislavoie]

@Jeff_Galbraith

About the scheme, I tried it first without and it comes back with 404 not found

Yeah, because of the above bug.

@Jeff_Galbraith

Any idea on release availability?

We don’t schedule our releases. You’re best off to build from source for now. It’s really just v2.5.0 plus that one commit; there’s no concern of instability.

[gcss (Carl Drechsel)]

@Jeff_Galbraith

Found this for 2.5.0-beta.1 and supposedly fixed: Bug in enforce_origin?
But it’s not…

This is a very interesting thread. It feels like on that thread SSH was being used (instead of HTTP as in here) and enforce_origin does not (yet?) work on SSH.

It’s possible enforce_origin will never work on SSH (and if it should not, Caddy should reject that configuration) - but should we discuss this there or should I open a new thread?