Rewrite v1 IF blocks to v2 Matchers?

[jbmanos (John B Manos)]

I’ve got this block in v1 caddyfile that I wrote into a snippet for v2, but I can’t get my head around converting this to paths and matchers… HELP!

    (wordpress_sec) {
      rewrite {
	    if_op or
	    if {file} is readme.md 
	    if {file} is readme.txt 
	    if {file} is readme.html
	    if {file} is changelog.html
	    if {file} is chagelog.md
	    if {file} is changelog.txt
	to /blackhole.html
    }

rewrite { 
   if {path} not_match ^\/wp-admin
    to {path} {path}/ /index.php?{query}
    }

respond 403 {
	/wp-config.php
	/wp-admin/install.php
	/wp-admin/includes/comment.php
	/wp-admin/network/menu.php
	/wp-admin/user/menu.php
	/wp-includes/admin-bar.php
	/readme.html
	/blackhole.html
  }
}

[francislavoie]

It’ll probably be something along these lines:

@exludedFiles {
	path /readme.md /readme.txt /readme.html /changelog.html /changelog.md /changelog.txt
}
rewrite @excludedFiles /blackhole.html

Your second rewrite is not necessary in v2, the default behaviour of php_fastcgi will already cover that for you.

For your 403 respond, it’ll be like this:

@accessDenied {
	path /wp-config.php \
		/wp-admin/install.php \
		/wp-admin/includes/comment.php \
		/wp-admin/network/menu.php \
		/wp-admin/user/menu.php \
		/wp-includes/admin-bar.php \
		/readme.html \
		/blackhole.html
}
respond @accessDenied 403

[jbmanos (John B Manos)]

Thank you!!!

Speaking of php-FastCGI …

The v2 docs mention using a block and that you can set the env

How would I set $_Server[‘Server_Port’]? Php-INFO shows a blank. I’m expecting it to say 443

Passing to a sock connection for php-fpm

[francislavoie]

Yeah so that’s a good question regarding SERVER_PORT. It’s tricky and I’ll probably write a more technical answer than is necessary but anyways…

So, CGI has an spec, RFC3875, that dictates how servers and apps should use it. Specifically here’s the section about SERVER_PORT: RFC 3875 - The Common Gateway Interface (CGI) Version 1.1

Currently, there’s a bug in Caddy v2.1 in how that variable is handled. If Caddy doesn’t know the port, it should omit the variable entirely, but currently Caddy is leaving it as an empty string. I opened a PR a couple days ago to fix this behaviour:

https://github.com/caddyserver/caddy/pull/3570

That doesn’t solve the whole problem though – the reason Caddy doesn’t know the port in some cases is because right now we’re only looking at the Host in the http.Request that the Golang stdlib provides to us, and that doesn’t always include the port.

What we actually want is the local address of the network connection, but Golang doesn’t provide that via the http.Request API. I spoke with @matt just now and I think we figured out a workaround using a newer API that was added in Go 1.13 (release in Sept 2019, but we weren’t aware of it until just now, having done a bit of digging) as suggested by this StackOverflow answer:

Accessing the underlying socket of a net/http response

So in other words, for now, Caddy doesn’t actually have the facility to populate the SERVER_PORT variable reliably and correctly because it relies on a piece of information that isn’t normally exposed.

Frankly, no PHP app should rely on that, it’s just not necessary because there are better ways of determining if the server is using HTTPS, such as the HTTPS variable which will be set to the value of on, or REQUEST_SCHEME which will be https or http.

If you must have SERVER_PORT set because the framework you’re using requires it, then you can explicitly set it in the Caddyfile config to override the value Caddy sets:

php_fastcgi unix//run/php/php.sock {
	env SERVER_PORT 443
}

Anyways, I wanted to elaborate because I don’t consider overriding it in the config as the right solution, because it’s just a hack. Caddy should be setting it correctly (and will at some point in the future when we implement a change to do so), and your PHP app should probably use some other mechanism instead.

[jbmanos (John B Manos)]

This. Thank you. I was going batty because phpinfo() was showing me a blank for $_Server[‘Server_Port]!!! I knew the php-fpm setup worked in the past.

So then I was thinking it was a v2 issue. I had to take a hiatus from caddy for a bit because one of the Mac security releases refused to allow it to attach to privileges ports. So I missed out on most of v1 but was a long time user of pre-v1 releases and loved it.

That’s all resolved and meanwhile I have my old environment all running again - but this pesky bug is playing games with Wordpress and specifically jetpack connectivity and the Rest API. Wordpress core took some weird turns over the years to guess port numbers and in this case, I’m getting a weird security trigger because it can’t figure the port out.

I’ll use the hack you provided for now because it’ll settle all the site health issues and connectivity security for now. I’ll try it and let you know if it works!

Cheers,

John

Who now has to update all the cache control stuff for v2 also!!!

[matt (Matt Holt)]

@jbmanos

I had to take a hiatus from caddy for a bit because one of the Mac security releases refused to allow it to attach to privileges ports

Huh? I’ve (obviously) used Caddy v1 without any problems on low ports, and I use macOS (probably not for much longer though, sigh). Am curious what you mean here.

[jbmanos (John B Manos)]

My old threads. I was never able to get it to work. V2 does it though ! Hooray!!

Isn’t binding ports but not logging error either

Thanks @matt. All the vhosts have bind with the IP4 host address in them. That’s what is driving me up a wall! This has worked fine for two years through countless caddy updates (I was using the homebrew build) Now, all of a sudden it doesn’t want to work.

[jbmanos (John B Manos)]

@francislavoie

If you must have SERVER_PORT set because the framework you’re using requires it, then you can explicitly set it in the Caddyfile config to override the value Caddy sets:

Okay… in order to make Jetpack and Wordpress happy, I had to hack this a bit further. Once I got the env SERVER_PORT set, it showed in phpinfo, but wordpress was still complaining…

So I noticed that the forwarded_port was still blank. so, I went one further on the hack scale, and I changed the header_up directive in the php-fastcgi block to be a static 443, also. So this:

header_up X-Forwarded-Port 443

Now, it’s all happy for now. wordpress core lifts what it does from that header info. Because it was also coming up blank, everything was complaining that they could not communicate. Setting a static value has hackingly made it work for now.

THANK YOU!!!

[francislavoie]

I find that surprising frankly. Other users have had wordpress working with a config as simple as this:

example.com

root * /var/www/html
encode gzip
php_fastcgi unix//run/php/php-version-fpm.sock
file_server

[jbmanos (John B Manos)]

it would run, no doubt! And autoupdate would work. It was mostly Jetpack that was complaining – and the REST API.

I doubt most wordpress users care about any of that. If you have jetpack on the site, and connected to wp.com, run the site health Tools >Site Health, and it was displaying a few “non critical” issues, one was the Jetpack Server Port, and the other was that site connectivity was showing “not connected” – this was an issue in the loopback on API calls and the reliance in core to use the server port value.

with it hacked in there as 443, all that is working as expected now.

Now that all of that is working as expected, I can get updates by TLS and SFTP and some of my API callbacks will work right also.

So, yes, not all wordpress is wordpress.