1. Caddy version (caddy version):
2.2.2
2. How I run Caddy:
Using caddy on a raspberry pi lite OS 32bit (based on debian), its run as a service that is setup and configured via a deployment script.
a. System environment:
raspbian lite OS. using systemd to start/manage custom build of caddy with plugins (caddy-auth-portal, caddy-auth-awt)
uname -a
Linux pidev 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
systemd managing custom build of caddy with (via xcaddy) with plugins caddy-auth-portal, caddy-auth-awt, caddy-trace
b. Command:
systemctl start caddy
c. Service/unit/compose file:
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
User=caddy
Group=caddy
#plugin modified caddy build for auth-portal and associated plugins
#/usr/bin/caddy now linked to /opt/caddy/releases/[current build]
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
#ExecStart=/opt/caddy/bin/caddy_linux_arm7_custom run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
#ExecReload=/opt/caddy/bin/caddy_linux_arm7_custom reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
{
storage file_system {
root /opt/caddy/storage
}
local_certs
http_port 80
https_port 443
}
https://elite-pidev.emdemo.int.elite-env.com, https://10.252.252.20 {
# caddy-auth-portal with local db config
log {
level INFO
format console
output file /var/log/caddy/caddy.log
}
# caddy auth portal login
route /auth* {
auth_portal {
path /auth
backends {
local_backend {
method local
path /opt/caddy/assets/conf/local/auth/user_db.json
realm local
}
}
}
}
# custom webapp running on port 1080 route
route /* {
jwt {
primary yes
trusted_tokens {
static_secret {
token_name access_token
token_secret AnExampleSecretString123
}
}
enable claim headers
}
reverse_proxy http://localhost:1080
}
route /version* {
respond * "2.0.0-a" 200
}
route {
redir https://host.example.com/auth 302
}
}
3. The problem I’m having:
I’m trying to figure out how to use the caddy “respond” or any other function to display header information within the browser for the connected user’s request.
I’m well aware of dev tools and logging solutions, for our situation we need to have a simpler method (troubleshooting training) to quickly check what currently is being presented in a client connection.
The idea is to have caddy serve a route, “debug” for example that can be used to in real time display the current authenticated user’s header information.
I’m imagining that the entry in the Caddyfile under the server instance would look something like:
route /debug* {
jwt {
enable claim headers
}
respond "[some magic string for expanding specific header values]" 200
{
The jwt directive is providing the headers for the authenticated user, the question is does caddy have a way to display them or do we need to fall back to a web page programatically doing it behind the proxy?
4. Error messages and/or full log output:
I’ve not tested yet as I cant find reference other than the “Respond” documentation page. It indicates static content, I’m hoping there is a way to provide the info dynamically, or there is some other directive I’m not realizing is useful…
5. What I already tried:
Its not clear if there is some form of macro expansion for caddy that can be expressed from this configuration. If not we can fall back to a web page behind caddy to do it.