> I have had it with standalone web servers: they're all over-complicated and I always end up with an awkward bifurcation of logic between my app's code and the web server's config
Personally I've grown really fond of letting nginx terminate TLS and proxy to the web app. It's a clean separation of concerns, not very complicated and upgrading the cert is easy (certbot).
Let me know if you need me to clarify, if you have any concerns.
I also expect that as setups age, one is likely to miss mod_rewrite - but at that point/style of setup, maybe apache traffic server start to make sense. Or, just apache httpd of course.
@needs-auth not remote_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
basicauth @needs-auth {
Bob JDJhJDEwJEVCNmdaNEg2Ti5iejRMYkF3MFZhZ3VtV3E1SzBWZEZ5Q3VWc0tzOEJwZE9TaFlZdEVkZDhX
}
[0] https://caddyserver.com/docs/caddyfile/matchers#remote-ip
[1] https://caddyserver.com/docs/caddyfile/directives/basicauth
[2] https://caddyserver.com/docs/caddyfile/directives/rewrite
Take the basicauth portion for example. If you had been reading the docs like a book, started in the references/tutorial sections, understood all there is to know about how request matcher syntax works as a result, and then read the basicauth page you would have a rock solid understanding of how to make basicauth do what you want here. If you land at the basicauth page from a Google search trying to stand up a quick file-server weekend project in a way your friends can access you either are really on top of it and notice "[<matcher>]" (not even mentioned in the Syntax breakdowns of the page) is what's used in the single example below and happens to be a path but might be a lot more or you leave without a hint of how to do basicauth the way you wanted. It'd be great if the syntax section breakouts just mentioned something that triggered more or less a "and hey dumbass, if you haven't learned how matchers work yet you need to go do that to fully utilized this directive".
I realize this is awfully needy, the docs have everything you need if you read them carefully, and I absolutely LOVE using Caddy so it's not an attempt to say it's bad overall by any means. I wanted to point it out though since this exact example is something I ran into a few weekends ago. I think the problem is exacerbated by v2 syntax being new, as well as the competing JSON syntax, making it harder for people to find use case examples outside of what's in the official docs.
It would be redundant to write on every page what you can use as a matcher. The Caddyfile reference docs assume you've read https://caddyserver.com/docs/caddyfile/concepts which walks you through how the Caddyfile is structured, and it'll give you the fundamentals you need to understand the rest of the docs (I think, anyway).
If you think we need more examples for a specific usecase, we can definitely include those. Feel free to propose some changes on https://github.com/caddyserver/website, we could always use the help!
Yeah I wouldn't say necessarily every page needs examples of different matchers and certainly not about what all of the matcher options are. More a "if the token is shown in the syntax it should have a bullet in the syntax section" kind of approach which in the case of [<matcher>] could be as plain and short as "[<matcher>] is a token which allows you to control the scope a directive applies to. For details on how see Request Matchers." to raise the "you probably want to know more about this first" flag to anyone that just jumped in from Google or what have you to go read about matchers before trying to understand the directive.
If that makes any sense I'd be glad to raise it more formally over on the GitHub!
In the above, access is implied, then revoked without a valid username/password, then login is excepted for certain conditions (IPs in this case) - and access is implied (again).
IMNHO one of the strengths of apache is how authentication providers and authorization is separated and allow for easy(ish) combinations.
That said, there's something to be said for doubling down on a single type of handling for access and rewrites (matchers).
I still prefer matchers (which resource) combined with action/policy (allow/deny/rewrite).
@first <whatever matcher>
handle @first {
do_something
}
@second <whatever matcher>
handle @second {
do_something_else
}
handle {
error "Unauthorized" 403
}
I'm not totally sure I follow how you'd like for it to be structured. Could you give a config example? I think one of the issues is `basicauth` needs to write a response header to work correctly (i.e. WWW-Authenticate to tell the browser to prompt) so it can't only act as a matcher.
Besides that Caddy is indeed amazing and very well thought out!
Yes, including your server, because you're probably forwarding that port to your workstation via ssh.
It's an unnecessary security risk is all I'm saying, and I personally would have preferred it was authenticated or off by default.
I really love Caddy, you've built an amazing piece of software, I just disagree with your design decision on this one little thing. It's good that you put that notice in the docs at least!
If the host is popped, I'm not sure what Caddy can do to save you. Even authentication has to be stored on the machine... that was popped.
I'm just worried that Caddy will be the source of "security misconfiguration" (1) findings in penetration test reports. It's my opinion that we as software engineers should strive not to leave our software insecure by default, is what I'm saying, and that's how I see Caddy 2's admin API.
1: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
I've managed to do this with openresty (nginx not supporting oidc out of the box), but it doesn't fill me with confidence, I guess it's all the lua. A quick glance at caddy shows it likewise doesn't support oidc integration out of the box, but instead I have to use another module that's no longer maintained ( https://github.com/thspinto/caddy-oidc )
The caddy-oidc plugin you linked was written for Caddy v1, so it's no longer compatible. The most complete auth plugin for Caddy v2 is https://github.com/greenpau/caddy-security, and I think it probably does what you need.
www.example.com {
redir https://example.com{uri}
}
example.com {
# tell Caddy where your favicon files are
@favicon {
path /favicon.ico
# + other favicon files...
# ...
# ...
}
# serve your static files
route /static/* {
root * /var/cache/example.com
header Cache-Control max-age=31536000 # 1 year
file_server
}
# serve your favicon files from your favicon route
route @favicon {
root * /var/cache/example.com/favicons
file_server
}
encode zstd gzip
# reverse proxy to your app
reverse_proxy 127.0.0.1:8080
# do some logging
log {
format json
output file /var/log/caddy/example.com/access.log {
roll_size 100MiB
roll_keep 10
roll_keep_for 2160h # 90 days
}
}
}