Snippet Issue, works outside snippet

dulanic · April 22, 2021, 3:11pm

1. Caddy version (`caddy version`):

v2.4.0-beta.2

2. How I run Caddy:

a. System environment:

Docker

b. Command:

N/A - Docker

c. Service/unit/compose file:

See above, use docker.

d. My complete Caddyfile or JSON config:

	default_sni dulanic.com
	acme_ca https://acme-v02.api.letsencrypt.org/directory
	email {$ACMEEMAIL}
	# debug
}
(proxyheaders) {
	flush_interval -1
	header_up X-Real-IP {http.request.header.CF-Connecting-IP}
	header_up X-Forwarded-For {http.request.header.CF-Connecting-IP}
	header_up X-Forwarded-Host {hostport}
}
(main) {
	tls {
		on_demand
		dns cloudflare {env.CLOUDFLARE_API_TOKEN}
	}
	header {
		Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
		Content-Security-Policy "upgrade-insecure-requests"
		X-Frame-Options "SAMEORIGIN"
		X-Content-Type-Options "nosniff"
		X-XSS-Protection "1; mode=block"
		Referrer-Policy "strict-origin-when-cross-origin"
	}
	log {
		output file /logs/caddy.json {
			roll_size 100MiB
			roll_keep 20
			roll_keep_for 365d
		}
		level INFO
		format filter {
			wrap json
			fields {
				size delete
				duration delete
				request>headers>Sec-Fetch-Site delete
				request>headers>Sec-Fetch-Mode delete
				request>headers>Connection delete
				request>headers>Authorization delete
				request>headers>Cf-Ray delete
				request>headers>Accept delete
				request>headers>Accept-Encoding delete
				request>headers>Cookie delete
				request>headers>Cf-Request-Id delete
				request>headers>Sec-Fetch-Site delete
				request>headers>Sec-Fetch-User delete
				request>headers>Content-Length delete
				request>headers>Sec-Fetch-Dest delete
				request>headers>Cdn-Loop delete
				request>headers>Cf-Visitor delete
				request>headers>Accept-Language delete
				request>headers>X-Forwarded-Proto delete
				request>headers>Sec-Ch-Ua delete
				request>headers>Dnt delete
				request>tls delete
				resp_headers delete
			}
		}
	}
}
(jwt_protected) {
	route {
		jwt {
			trusted_tokens {
				static_secret {
					token_secret {env.token_shared_secret}
				}
			}
			allow roles verified
			auth_url https://auth.dulanic.com/auth/
		}
	}
}
https://subdomain.dulanic.com {
	import main
	import jwt_protected
	reverse_proxy test:4000 {
		import proxyheaders
	}
}

3. The problem I’m having:

This code works placed directly before the reverse_proxy, but not as import jwt_protected. I’d prefer it to be a import as I want to reuuse the snippet in multiple subdomains.

	route {
		jwt {
			trusted_tokens {
				static_secret {
					token_secret {env.token_shared_secret}
				}
			}
			allow roles verified
			auth_url https://auth.dulanic.com/auth/
		}
	}

4. Error messages and/or full log output:

{"level":"error","ts":1619101882.4429889,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"jwt","error":"jwt-87: token keys and secrets must be defined either via environment variables or via token_ configuration element"}

5. What I already tried:

It works if I put the snippet directly under the path, but not as a snippet. I worked /w @greenpau here. https://github.com/greenpau/caddy-auth-portal/issues/122#issuecomment-824913704

6. Links to relevant resources:

francislavoie · April 22, 2021, 3:57pm

I’m confused. Could you compare the adapted JSON to see where it differs?

Run caddy adapt --pretty on your Caddyfile and compare.

dulanic · April 22, 2021, 5:50pm

Looks like it isn’t pulling in the token when it’s in the snippet.

This is the diff between the 2, just moved to the snippet.

francislavoie · April 22, 2021, 6:12pm

Interesting, I can replicate the issue.

I think this was a side effect of this feature:

github.com/caddyserver/caddy

caddyfile: Add support for args on imports

caddyserver:master ← francislavoie:import-args

opened 07:04AM - 18 May 20 UTC

francislavoie

+168 -8

Stems from the discussion in https://caddy.community/t/logging-snippet-using-hos…t-placeholder-for-log-filename/8218 The idea here is that it's common for users to want to have one element of an imported snippet or file be replaced with a context-specific value. This PR adds support for `{args.*}` placeholders at Caddyfile-parse time when importing tokens from either a snippet or file, where `*` is the positional argument number. The `import` syntax becomes: ``` import <pattern> <args...> ``` --- For example, consider this Caddyfile, where a user wants to enable logging using a common config for each of their sites. You'll see that the log filename is expanded to `/var/log/caddy/a.example.com.access.log`: ``` (logging) { log { output file /var/log/caddy/{args.0}.access.log } } a.example.com { import logging a.example.com } b.example.com { import logging b.example.com } ``` Adapted JSON output: ```json { "logging": { "logs": { "default": { "exclude": [ "http.log.access.log0", "http.log.access.log1" ] }, "log0": { "writer": { "filename": "/var/log/caddy/a.example.com.access.log", "output": "file" }, "include": [ "http.log.access.log0" ] }, "log1": { "writer": { "filename": "/var/log/caddy/b.example.com.access.log", "output": "file" }, "include": [ "http.log.access.log1" ] } } }, "apps": { "http": { "servers": { "srv0": { "listen": [ ":443" ], "routes": [ { "match": [ { "host": [ "a.example.com" ] } ], "terminal": true }, { "match": [ { "host": [ "b.example.com" ] } ], "terminal": true } ], "logs": { "logger_names": { "a.example.com": "log0", "b.example.com": "log1" } } } } } } } ``` --- This also supports an arbitrary number of arguments, and supports imported files. The file `respond.txt` ``` respond "I am {args.0}, hears {args.1}" ``` Caddyfile: ``` example.com import respond.txt Groot Rocket import respond.txt you "the confused man" ``` Adapted JSON: ```json { "apps": { "http": { "servers": { "srv0": { "listen": [ ":443" ], "routes": [ { "match": [ { "host": [ "example.com" ] } ], "handle": [ { "handler": "subroute", "routes": [ { "handle": [ { "body": "I am groot, hears rocket", "handler": "static_response" }, { "body": "I am you, hears the confused man", "handler": "static_response" } ] } ] } ], "terminal": true } ] } } } } } ```

I think {env.*} is being replaced here when it shouldn’t be, so if you don’t have the environment variable set when you’re adapting/running Caddy, import replaces it with an empty string. I’ll take a look at fixing it.

francislavoie · April 22, 2021, 6:20pm

Easy enough:

dulanic · April 22, 2021, 6:21pm

That was a fast fix

dulanic · April 28, 2021, 2:04pm

So I’m not sure that fixed it. It is passing the env var name instyead of the value of the env value. This is from the autosave.json, all other env variables show the value except this one.

francislavoie · April 28, 2021, 2:49pm

As I wrote on the PR, that’s working as intended:

system · May 22, 2021, 3:12pm

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