Thread Starter
sunb1
(@sunb1)
Just to add, its happening in other url fields also.
What web browser are you using? I cannot replicate the issue, so it seems like there is something going on with the Javascript of the site likely.
In your browser, open the Developer Tools, and look under ‘Console’.
Welll there’s something you don’t see everyday… https://prnt.sc/Gce906E85hPJ
I added the *.cloudflare.com and hit save and it did indeed disappear from the field as shown… however, if you look at the source… it’s in the value of the field!?
That shouldn’t be happening at all… all “values” should be shown in the text field, per HTML specifications.
I’ll see what I can do, and hopefully have a fix out today
-
This reply was modified 3 months, 2 weeks ago by
Kevin Pirnie.
I’ll have a fix for this published soon. Need to check on a few more things.
It ended up being a bit of an update to the functionality that controls the “Include WordPress Defaults”
@sunb1
Just pushed the fix for this, along with a couple other updates. Wait until it shows then update. You will likely need to clear your browsers caches after updating.
Thread Starter
sunb1
(@sunb1)
@kevp75 Thank you for the quick response and fast fix — much appreciated. It looks like I need to update my PHP version, as the latest update isn’t compatible with 8.1. I’ll update both and let you know if I run into any issues.
I’ve updated my review as well — the plugin and your support definitely deserve 5 stars. (actually for whatever reason it won’t save my edit. I’ll keep trying)
🙂 @sunb1
Keep me posted how it goes for ya
Thread Starter
sunb1
(@sunb1)
So updated php and no longer getting incompatible message. Updated, cleared cache and tried the ‘font source’ field and for me it’s still doing the same thing:
Original entry: data: https: *.gstatic.com fonts.gstatic.com cdn.jsdelivr.net *.bootstrapcdn.com
Tested by adding a font source url and after hitting save it dissapeared from the field but source did show it updated but also shows https: and *.gstatic.com duplicated. But the url field does not show them duplicated so not sure how to get rid of them:
font-src ‘self’ data: https: *.gstatic.com fonts.gstatic.com cdn.jsdelivr.net *.bootstrapcdn.com https: *.gstatic.com ;
Deleting the whole field also results in them coming back after save lol. Will test more tomorrow but can you confirm it’s no longer doing this in your testing?
Can you try a different browser?
Something that you haven’t been to the site in yet preferably… or can you hard clear your caches. (https://clear-my-cache.com/)
I do not have that issue any more, but I did have to clear out my caches
Thread Starter
sunb1
(@sunb1)
I always clear all caches (browser, litespeed etc) between each change but i’ll dig deeper. Will let you know what i find. Thanks
Thread Starter
sunb1
(@sunb1)
Well, after a few hours of testing (it’s become a challenge lol), I’m still seeing the same issue. When I add a custom source (e.g example-csp-test.website.com) to a directive and save, the value is stored in the database (confirmed this) and correctly appears in the CSP header, but it still disappears from the URL field on reload after saving. No caching is being used now (admin not cached; LiteSpeed/Cloudflare bypassed), and this is the same across different browsers. The duplicates are probably harmless since they’ll be ignored, but the disappearing value is a major problem as if I press save again for any reason, the custom entry gets removed because it’s no longer in the field.
I think since the entry shows up correctly in the database and on the front end, the plugin is working as it should, but there may be an issue in the UI. Could also be due to differences in configuration or our environments, which might explain why it works for you but not for me.
Do you have “Include WordPress Defaults?” on or off? Actually… as a quick test… can you put
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
In your wp-config.php and test again?
I think I’ve got it all corrected in my test areas, and my personal site. Before I push the fix, I’d like to know if it starts working for you once you enable WP_DEBUG though. Seems there may be an issue with Node/NPM’s gulp functionality that may not be minizing the javascript properly.
Also… noticed your comment about “reporting”.
CSP doesn’t work that way unfortunately… there is a “report-to” directive, but it isn’t intended to send email reports. Instead it generates a report and sends it to a specified URL endpoint. (I’m adding it in the next version). For more context: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-to
You’d have to develop something to continually monitor your site for valid headers and then email you for violations. Could I do it, sure, but since this plugin is going to remain free, I am not willing to maintain the necessary hardware and maintenance costs to do that. 😉
If I had to guess, the “old plugin” only emailed on structural inconsitencies, and not real violations. Real violations require at least a HEAD request to the site being tested, and then comparing the configured CSP headers against a full recursive scan of the site for the external resources and their types.
-
This reply was modified 3 months, 2 weeks ago by Kevin Pirnie.
Thread Starter
sunb1
(@sunb1)
Sorry about the delay, holiday stuff got in the way.
I got curious after my comment about possible differences in configuration or environment so I tested your plugin on another site of mine (different server), and the issue did not occur there.
Went back to the original site, I did some cleanup, so I can’t say with 100% certainty which step resolved it, but one key change was deleting all plugin-related entries from the database and then uninstalling and reinstalling the plugin. After doing that, the custom source now stays in the field correctly after saving.
It’s possible your last update already fixed the underlying issue and it just needed a clean install rather than an update over existing data, Not totally sure about that, but things look good so far.
I’ll test more when I have time, but for now everything seems stable.
Thanks again for all your help, and happy holidays / happy new year.
Sorry about the delay, holiday stuff got in the way.
No worries at all mate, hopefully they were good for ya 🙂
That’s pretty odd… unless there was some REALLL heavy duty caching going on, it should have updated fine. Maybe a real long term transient? Unfortunately, I did not come across that (post update)
I’ll keep an eye out, and keep this open for awhile in case I do happen to run into it… or anyone else does as well.
