2.5.0 enforce_origin bug

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:

1 Like

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

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

1 Like

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. :frowning:

Thank you for your help and insights.

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

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.

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!

This worked when added to axios header content:

Origin: http://localhost:2019

Thank you :heart:

1 Like

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.

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!

2 Likes

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

Yeah, because of the above bug.

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.

2 Likes

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?

This topic was automatically closed after 30 days. New replies are no longer allowed.