PW 3.0.135 – Core updates

[ryan]

Version 3.0.135 of ProcessWire on the dev branch focuses on adding additional layers of security via .htaccess updates, adds clarity to debug mode, and improves upon the installer—

https://processwire.com/blog/posts/pw-3.0.135/

[Robin S]

Hi @ryan,

Thanks for the update. The section 15B update to .htaccess is nice.

Quote

15B blocks download of any archive files (like ZIPs and such) outside of /site/assets/files/.

I'm keen to enable that on my sites as it's a good bit of extra security. But I just want to check: does this blocking only apply to files that are accessed directly by the browser and not those served by PW via $files->send()? Because on several sites I offer downloads of a set of CSV files that I build and bundle into a ZIP file on-the-fly. I create the ZIP in a WireTempDir and then send the file for download via $files->send(). So would this be affected by section 15B? I did a quick test and it seems to work okay but just want to confirm that I don't need to adjust that section of .htaccess to allow WireTempDir paths.

[adrian]

I know Section 18 isn't new, but it seems like it doesn't work as expected. I feel like it is missing the actual RewriteRule after the conditions, or maybe I am misunderstanding what it's meant to do?

[teppo]

8 hours ago, Robin S said:

I'm keen to enable that on my sites as it's a good bit of extra security. But I just want to check: does this blocking only apply to files that are accessed directly by the browser and not those served by PW via $files->send()? Because on several sites I offer downloads of a set of CSV files that I build and bundle into a ZIP file on-the-fly. I create the ZIP in a WireTempDir and then send the file for download via $files->send(). So would this be affected by section 15B? I did a quick test and it seems to work okay but just want to confirm that I don't need to adjust that section of .htaccess to allow WireTempDir paths.

$files->send() (WireFileTools::send()) makes use of WireHttp::sendFile(), which in turn reads the file contents using readfile() and outputs it with applicable headers. So no, this wouldn't be affected.

Only exception would be the case where you're serving those files from (faked) URLs that match rule 15B – which seems quite unlikely. In that case you'd have to add a -f check here to make sure that a) if it's a real file it won't be downloaded, but b) if it's not the query can be passed to ProcessWire and served from there. But again, I'm guessing that's not a problem for your use case ?

[teppo]

8 hours ago, adrian said:

I know Section 18 isn't new, but it seems like it doesn't work as expected. I feel like it is missing the actual RewriteRule after the conditions, or maybe I am misunderstanding what it's meant to do?

There's no need for a RewriteRule here. The point of these rules is that if they fail (don't match), the request won't be passed to (or "continue to") index.php, which in turn means that ProcessWire won't attempt to serve the file. Instead Apache will try to serve whatever was requested directly from the disk. We'd only need a RewriteRule here if we wanted to divert the request to some other location, or something along those lines ?

[adrian]

@teppo - that is what I thought, but I was thrown by the comment for that rule:

"After uncommenting, test a URL like domain.com/site/assets/files/test.jpg to make sure you are getting a 404 and not your homepage."

Those conditions don't seem to prevent apache from serving up a test.jpg at that path, although it occurs to me just now that Ryan's intention was for test.jpg to be a file that doesn't actually exist - makes sense now!

I was also confused by the "prevent PW from attempting to serve images or anything in /site/assets/" - I thought he was talking about subfolders of assets as well. My initial thought was that this rile was actually about preventing hotlinking, so I think I got the intention backwards, hence my confusion ?

[nbcommunication]

I've been doing a little rejigging of our default htaccess file after yesterday's dev release, and trying to understand Section 18 a bit better too...

In section 18 we use a rule based on what is outlined here:  https://processwire.com/blog/posts/optimizing-404s-in-processwire/

RewriteCond %{REQUEST_URI} !\.(jpg|jpeg|gif|png|ico|webp|svg|php|cgi|pl|asp|rar|zip)$ [NC]

This is entered after the existing section 18 rules, which are left commented out.

After the end of ProcessWire's htaccess rules we have:

<FilesMatch "\.(jpg|jpeg|gif|png|ico|webp|svg|php|cgi|pl|asp|rar|zip)$">
  ErrorDocument 404 "The requested file was not found.
</FilesMatch>

Without that rule, I get the ProcessWire 404 page when accessing a non-existent file matching one of those types.

On a different htaccess-related note, I recommend the 6G htaccess Firewall https://perishablepress.com/6g/. We have this at the start of our default .htaccess file, followed by:

ErrorDocument 403 "Sorry, you are not permitted to access this resource.

The only issue I've come across after a few years of use is with the autocomplete Page field, when using OR selectors (e.g. template=home|default). I wrote this hook as a remedy:

<?php
// Replace pipes (|) with %7C in PageAutocomplete data-url attribute
// This gets around 6G htaccess rules which disallows pipes in urls
$wire->addHookAfter("InputfieldPageAutocomplete::render", function(HookEvent $event) {
	$out = $event->return;
	if(strpos($out, "data-url") === false) return;
	$url = explode("'", ltrim(explode("data-url=", $out)[1], "'"))[0];
	$event->return = str_replace($url, str_replace(" ", "+", str_replace("|", "%7C", $url)), $out);
});

Cheers,

Chris

[spoetnik]

Any Nginx guru out there that can translate those enhancements to a nginx-config?