Gord

Hi Michael,

Hmm, seems that most of the issues are related to the deletion of the WooCommerce plugin without removing all of the products. Because they are custom post formats, they aren’t visible in the normal admin panel.

There may have been issues with attachment pages being left behind with the parent post deleted. With the “Redirect Attachments to Post Parent” feature enabled, this would have sent a 301 to a 404. I’m no longer able to reproduce this so I can’t be certain.

I reinstalled the WooCommerce plugin and followed the official uninstall directions, and this seems to have cleared it up.

I’m not sure whether there was anything AIOSEO could have tested for in either of these cases to avoid this situation. Thanks for your help.

@oyda,

The If-Modified-Since header is a request header, not a response header. As such, it is sent from the browser with the request and should not appear in the response. It would make no sense for @zinoui to implement this in a server-side plugin. The browser would simply ignore it.

This is essentially how it works in the client-server dialogue:

Browser:
I have a cached copy of this asset that has exceeded its expiry time. Send me the latest version, but only if it’s newer than my copy.
If-Modified-Since: <timestamp of my cached object>

Server:
304 Not Modified (continue using your cached copy for now; I’ll save time and bandwidth by not sending you what you already have)
or
200 OK (the asset was changed since then, so here’s the new version)

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since

As a update, I was able to get it working.

The author changed the data format between 1.12.1 and 1.12.2. If you load the settings from a previous version, the only thing that gets loaded is 1 character from the textbox, maybe. None of the checkboxes are enabled and the strings are all truncated.

To fix it,

1. make a backup (just in case)
2. delete everything (including the textboxes)
3. enter everything from scratch.
4. use “inspect headers” (or securityheaders.com) to verify the correct header output
5. test everything

I did this and it started working right away.

IMHO, this is way too big of a change to slip into a bug-fix release. Bug fixes should not, except in extreme circumstances, break backward compatibility. Also see the author’s comments here
that he has intention to correct it.

I hope you are able to able to regenerate your policy in the new version and get it working again because you don’t want to get stuck not being to get future updates.

Before I get into my reply, I will mention that I finally got it working today after giving up on waiting. In a nutshell, I had to spend a couple of hours recreating my policy from scratch and re-testing everything. As such, I’m changing my rating from * (“Poor”) to ** (“Works”).

That said:

The rating is not based on one header. It’s based on the lack of testing, the lack of documentation, and mostly the lack of responsiveness of the author. Posting a negative review elicits more of a response than reporting a broken security header. People considering this plugin need to know what they’re getting into.

made a feature request (a transform feature) that I do not plan to implement for now, and I do not have to.

You told me to “try to transform the CSP settings” to make it compatible with the new version. I didn’t ask for a new feature; I simply asked for instructions on how to use the transformation feature you mentioned. If you haven’t implemented this feature and don’t plan to do so, then asking me to try it makes no sense.

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.

–Wikipedia
Seems like one of the more important headers out of the 30+ to me.

I will grant you that there are topics in the support forum that are beyond the scope of this plugin. But that doesn’t let you off the hook for acknowledging the tickets that are legitimate bug reports in a timely manner.

If you had simply taken a minute to acknowledge that there was a problem with the plugin and that you were looking into it, this would have played out very differently. But you ignored it, and now you are getting defensive when the plugin gets a negative review.

• This reply was modified 5 years, 6 months ago by Gord.

Any news on a fix for this issue? It’s been 5 business days with no reply, so I am following up.

You mentioned in this thread that there is some sort of transformation that I should try, but you didn’t provide any details on how to accomplish that.

• This reply was modified 5 years, 7 months ago by Gord. Reason: Updated link to point to specific comment

Acknowledged, the Feature-Policy now works “as expected”. It simply needs documentation or a more intuitive interface so that the end user knows what the expectation is.

As an enhancement request, a Header Preview feature on the configuration page would show what the header would look like before saving the changes. This would be very helpful for troubleshooting and for avoiding downtime like what @jessner experienced.

Feature Policy
Alright. I found the problem by looking at your source code. The problem is not technical; it’s poor UI design. It is not sufficient to put a value in each option, you must also click the checkbox next to it. After clicking the checkboxes, I now see the Feature-Policy header and get a green check mark on securityheaders.com. I have to say that the old UI was far more intuitive. This one is excessively long and not at all helpful.

Content-Security-Policy

Please provide more details on how to use the transform feature. Or even better, make the transformation automatic.

This is vital because right now I have to choose between:

1. Moving forward without CSP
2. Rolling back to 1.12.1 to get CSP working but giving up on FP and any future updates
3. Switching to a different plugin

Notes
For future reference, if you’re going to break backward compatibility, this should be done in a major version number (or at most a minor version number). This way people are more prepared for things breaking. And you need to call attention to this new transformation requirement before making the change to their production sites.

For further information, I also tried it in Apache mode and got the following lines added to my .htaccess file (with both CSP and FP enabled):

# BEGIN HttpHeaders
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  <FilesMatch "\.(php|html)$">
    Header set X-XSS-Protection "1; mode=block"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
    Header set Referrer-Policy "strict-origin"
    Header set Expect-CT 'max-age=3600, report-uri="https://[REDACTED]"'
  </FilesMatch>
</IfModule>
# END HttpHeaders

@zinoui,

== Feature-Policy ==
With respect to the Feature-Policy, for me the expected behaviour is:

• that the site will inject a Feature-Policy header into the responses.
• that the “inspect headers” feature of your plug=in will list Feature-Policy with its value in the “Response headers” section and omit it from the “Missing headers” section.

I am not observing either of these.

== Content-Security-Policy ==
With respect to the CSP policy, I didn’t see a “transform” option anywhere. I have an “Edit” link on the security dashboard. That link takes me to the new UI, but I don’t see a “transform” button or link on that page, either. Please provide more details on how to use the transform feature. Or even better, make the transformation automatic.

• This reply was modified 5 years, 7 months ago by Gord. Reason: Fixed formatting errors

@zinoui, it’s been 3 days. Can you post a link to the 1.12.1 version so that I can re-install that and get my CSP header working again while you fix all the problems introduced in 1.12.2?

Thanks for the warning @jessner. I’m using PHP mode, but that doesn’t mean it wouldn’t wipe the data from the database on me. I’ll hold off on saving any changes until @zinoui fixes the new issues. In fact, I think I’ll take a snapshot of the database and my .htaccess file, just for my own peace of mind.

Dimitar, Here is some more good news: it appears that the CSP settings are not “gone” as I previously reported. I found the original settings are still in the database. The settings are simply not being used.

I just realized that you marked this as resolved. Should I be opening a new thread to continue with these 3 issues?

• This reply was modified 5 years, 7 months ago by Gord. Reason: Marked ticket as not resolved

Hi @zinoui,

Thanks for releasing an update to address the error messages. The good news is that the “fix” makes the errors disappear. The bad news is that it still does not insert a Feature-Policy header into the responses.

Also, after updating to 1.12.2, I no longer have any settings in my Content-Security-Policy header control panel. In the new UI, all of the checkboxes are deselected and the textboxes are empty; my previous settings are all gone. The only thing retained was the “on” radio button setting.

Furthermore (because of the missing settings?) there is no longer a CSP header in the responses.

You could try script-src 'self' 'unsafe-inline'. It’s less secure, but there’s a lot of WordPress that uses inline Javascript and, in my experience, it won’t work properly without that. It’s still more secure than allowing Javascript to be loaded from anywhere in the world.

• This reply was modified 5 years, 8 months ago by Gord.