Unable to Ajax save

Bloke · Today 00:21:49

This is weird. All admin-side actions that involve Ajax requests failed on a site of mine. Loading panels is fine, saving Categories and Users and Languages and Sections, etc: all good. But if I go to save a Form, Page, Stylesheet, Article, Upload an image, perform a search, export a theme to disk… anything that involves an Ajax request, I get “Sorry, the form could not be submitted. Please try again later.”

No additional info is available if I switch Debugging on. The request still fails immediately.

The Inspector’s Network panel shows: Blocked … CSP

The Console panel throws the error message: Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) and, sure enough, in the site root .htaccess file is a connect-src CSP directive to allow google-analytics.com and a couple of other third party URLs to hook in.

The fix was simple: add 'self' to the connect-src directive. Then everything admin-side began working again.

But why?

This is a 4.9.x installation, and this behaviour didn’t manifest itself on 4.8.8. So I presume it’s something to do with our core CSP directive handling, but I’ve no idea how to go about debugging or fixing it. Anyone got any ideas what’s going on or suggest a solution?

I didn’t even think the root .htaccess file had any say in what went on admin-side from a CSP perspective. I thought the textpattern/.htaccess governed that? I’m guessing, like regular .htaccess rules, the ones from the root .htaccess file are being propagated forward to the /textpattern sub-directory.

So maybe we should add a connect-src 'self' CSP rule to our default .htaccess / .htaccess-dist files to override any setting that someone may have employed for the front-of-house?

But this begs the question: are there any other rules that people might employ that could potentially break the admin interface and we should override them by default in textpattern/.htaccess?

Last edited by Bloke (Today 00:24:13)

Bloke · Today 00:42:36

Update: I trawled through the old site backup files and think I’ve found what’s going on. When I uploaded Txp 4.9.x, I overwrote any files that were newer with their 4.9 counterparts. This included textpattern/.htaccess, which reverted it to the stock .htaccess file.

However, in the backup files (thank goodness I downloaded them before upgrade!) the textpattern/.htaccess file contained this rule:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

So I reinstated that rule at the end of the stock textpattern/.htaccess file, removed the connect-src 'self' from the root .htaccess file… and everything continued to work.

I’m happier with that solution than allowing the public-facing site to access 'self', and clearly this is something that would have affected 4.8.8 but I honestly don’t remember ever putting this directive in place, so I presume some other developer must have done it before me. Or my memory has holes in it.

My question still remains: is this something we could/should mitigate against – or at least document in the textpattern/.htaccess file (maybe even add the CSP directive above, commented out, in case people need it?). And if so, how should we communicate this for the best? CSP is rather outside my sphere of knowledge so I’ve no idea if the above “solution” is indeed the best route. Advice welcome.

phiw13 · Today 01:02:33

Bloke wrote #342384:

My question still remains: is this something we could/should mitigate against – or at least document in the textpattern/.htaccess file (maybe even add the CSP directive above, commented out, in case people need it?). And if so, how should we communicate this for the best? CSP is rather outside my sphere of knowledge so I’ve no idea if the above “solution” is indeed the best route. Advice welcome.

Documenting what type of CSP rules are needed by /textpattern/: probably yes. The rules are sort of documented in the default config-dist.php. It wouldn’t hurt adding a basic CSP set commented out to the /textpattern/.htaccess file.

That said: adding 'self' to your connect-src directive at the root won’t make your site less secure.

Bloke · Today 01:27:58

phiw13 wrote #342385:

Documenting what type of CSP rules are needed by /textpattern/: probably yes. The rules are sort of documented in the default config-dist.php. It wouldn’t hurt adding a basic CSP set commented out to the /textpattern/.htaccess file.

Cool, do you have any idea what exactly we need here so I can add them? Just bare minimum rules that might be helpful if people experience weird behaviour like I saw.

adding 'self' to your connect-src directive at the root won’t make your site less secure.

Okay, that’s good to know, thank you. I’m always a bit nervous adding stuff to the root .htaccess. I’ll stick with the kludge in the textpattern/.htaccess for now and hope I remember not to overwrite it when I upgrade to 4.9.1 final!

phiw13 · Today 01:42:53

I have this block in /textpattern/.htaccess

Header set Content-Security-Policy "base-uri 'none';connect-src 'self';default-src 'self';font-src 'self';form-action 'self';frame-ancestors 'self';frame-src 'self';img-src  data: blob: 'self'; media-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';"

For documentation purposes (docs.textpattern.com … ?) perhaps a reference to this part of the h5bp project htaccess file, and the canonical MDN page.

Textpattern CMS

Textpattern CMS support forum

#1 Today 00:21:49