So I'm putting a plugin together that will allow me to connect multiple client sites with an online service.

I can get the service vendors snippet to load, but once you interact with it, that's where things get tricky and it refuses to load an (I guess) iframe... ...it's pretty poorly documented.

Refused to load https://www.service-domain.com/ because it does not appear in the frame-ancestors directive of the Content Security Policy.

That's the console log error I was receiving.

So I jumped back into my plugin and added the following:

function bbti_send_headers() {
    header( "Content-Security-Policy: frame-ancestors https://www.service-domain.com/; frame-src https://www.service-domain.com/;" );
add_action( 'send_headers', 'bbti_send_headers' );

Now, when I reload the page I'm still getting the same error Refused to load https://www.service-domain.com/... etc...

However, if I look at the network panel and check the page's headers this is what I get:

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Security-Policy: frame-ancestors https://www.service-domain.com/; frame-src https://www.service-domain.com/;

So the header is there but still getting the same error from the script.

Anyone know what it is I missed?

  • 1
    If the error says "Refused to load https://www.service-domain.com/", then it's probably because the resource/page at service-domain.com is disallowing itself from being put in an iframe or frame (within certain pages). So basically, you'd need to contact the service vendor for guidance on fixing the issue.. (or the proper way to load their snippet on your plugin page). And actually, it's them who would add the header (in your bbti_send_headers()) and not your plugin.. I mean, if the header was actually needed. – Sally CJ Mar 16 at 11:49
  • 1
    Sally CJ, this is part of what I figured out the day after posting the question. The embed code used is what's provided by a 'builder' from the vendor, so I assumed that was correct as they had generated it. What's really going on is that the individual who set the account up, set it up for the client's LIVE url, even though we're doing all our work in a staging environment with a different URL. So our staging/development URL isn't recognized and thus blocked. :-/ Sadly the vendor doesn't provide a means to change it, so we're stuck waiting for them to do it. – Tony Djukic Mar 16 at 14:16
  • There is a secondary issue though in that the script they generate/provide via their 'builder' utility ends up generating an incorrect url to make it's call... it runs a search at service-domain.com/Client%20Company%20Name/?search which returns a 404, but if you edit the string manually and drop it into your browser as service-domain.com/clientcompanyname/?search you get the expected result. (Troubleshooting is exponentially more difficult when you've got multiple errors and you don't know if they're separate or if one is the cause of the other.) – Tony Djukic Mar 16 at 14:19
  • "so we're stuck waiting for them to do it" - well then, I have no further comments on that.. But as for the secondary issue, although it seems easily fixable (programmatically), you should notify the vendor so that they could fix the issue ASAP. (Maybe their 'builder' is still in beta or something like that?) 🙂 – Sally CJ Mar 16 at 15:53
  • Lol! The biggest frustration as a developer is when you build up a head of steam, make tons of progress and get halted in your tracks as you have to "wait" for a third-party to patch something. Lol! I've notified them of everything though and well... twiddles thumbs – Tony Djukic Mar 16 at 15:57

After tons of digging it appears that the way the error message is worded was a bit misleading.

Refused to load https://www.service-domain.com/ because it does not appear in the frame-ancestors directive of the Content Security Policy.

What isn't clarified above is that it wasn't the server/site I was working on that Refused to load from the vendor's domain, but rather that it was the vendor's property that Refused to load itself into the domain I was working on.

The header snippet above does work in case anyone ever needs it, but if you see that specific error message be aware that it's the other domain, not yours' that is restricted.

As an aside, the issue stems from the fact that the work is being done on a development/staging domain, but when the account/profile was set up with the vendor the current Live/Production domain was used - so the domain I'm calling from isn't listed as being authenticated and is thus being blocked.

Hope this helps someone that comes across a similar issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.