Hi, folks.
There is an example configuration on how to use Wordpress with Caddy V1, available here: examples/wordpress at master · caddyserver/examples · GitHub
Based on that tutorial, I was able to run Wordpress with Caddy V2. I’m using a “generic” Caddyfile config to run Wordpress:
Is everything working, including the admin panel, clean “slugs” / post URLs, and pages? If so, you might be good to go, I guess?
Your config missing the rewrite on this condition: if {path} not_match ^\/wp-admin – but it just does a try_files, which php_fastcgi in v2 does for you anyway.
The only other thing missing is # Prevent malicious PHP uploads from running – but I do not understand what the threat model is there, unless people are allowed to upload executable scripts to your server (!! in which case, that’s the real problem here !!).
This is amusingly true, but in the sad-cry kind of way… most CMS’s have/had such bad security (at least defaults) that they are associated with “allowing uploads == RCE vuln” but it doesn’t have to be that way just because files can be uploaded. They just don’t care or something. Sigh.
Anyway yes, if that is in fact a real problem with modern WordPress, then you’ll want to block that somehow.
But how would benign uploads be accessed? I assume they are uploading things to also serve/access them.
Only if you want to terminate the TCP connection with the client. It can slow down future requests, so probably not in this case? We use it when redirecting HTTP->HTTPS because HTTPS is on a different port, so the connection to the HTTP port is no longer needed.
Laugh as instead of producing the PHP file as a download, the server renders it
I might propose a better solution would be:
respond /uploads/*.php 404
We don’t need to 404 every single upload - that would break uploaded pictures and the like attached to blog pages etc. Just 404 any uploaded PHP files specifically.