It also failed for a different embedded iframe from a different src domain that I allowed.
The exact same sort of embedded iframe from the same src domain worked the last time I tried it, maybe 6 months or a year ago. Now I’m on Discourse v3.3.1 +5 (stable branch).
On the latest version of the tests-passed branch, the iframe embeds without issues. Note that the style and title attributes that you have set will be stripped by Discourse. You can set width and height attributes though. For example:
Failed to load resource: net::ERR_CONNECTION_REFUSED beacon.min.js:1
But that appears to be a DNS blacklist that I’m using. When I connect over a VPN there are no errors. And it seems more than a coincidence that a different user with a completely different computer and network originally reported this same issue to me.
Partitioned cookie or storage access was provided to “https://www.tickcounter.com/widget/countdown/4471981” because it is loaded in the third-party context and dynamic state partitioning is enabled. [Learn more]
I should also mention that I pasted the iframe code into a skeleton static HTML file and opened it in the browser and it properly loaded the iframe.
ok this iframe used to work for you… Are you on Cloudflare by chance? if so, perhaps take a look and see if disabling the speed brain thing does anything? (if it is enabled) I know that it is relatively new thing.
Hmm yep that’s what it looks like. But shouldn’t Discourse have an error in /logs/ ?
I’m not running anything that I can think of on the server that would block that. I was using the hosting provider’s DNS in my /etc/resolv.conf, and I tried switching it to 8.8.8.8 with no change in this issue.
only if it causes an error. something might be blocking it as a matter of proper functionality. my guess is to try to figure out if/what changed around the time this stopped working. I wonder if a Content Security Policy change could have affected it.
It’s a DNS service that blocks domains with a bad reputation. But that’s not the issue because 1) when I connect over a VPN it uses a different DNS and this issue continues, and 2) the user that reported this issue to me is using a completely different setup, 3) the DNS configuration is only for my LAN and not on the Discourse server which is failing to generate the proper HTML server-side, and 4) this HTML file properly loads the iframe:
Oh wow, that was it, it was missing the final /
Thanks very much!
Something has changed in Discourse, because I added https://www.tickcounter.com the last time I tried this and at that time it worked. In my opinion either the regexp logic it is using or the description of the setting needs to be adjusted, because it says:
A list of iframe src domain prefixes that discourse can safely allow in posts
When I think of a “domain prefix” I think of a domain name and/or a subdomain, both of which do not include a / . Or if it’s supposed to be using more precise logic for complex iframe src URLs then it should say something like:
A list of iframe src URL prefixes that Discourse can safely allow in posts
The links that were added more than 2 months ago (before the security fix was merged) are the problem, back then you did not receive an error message and even the default links didn’t contain a third ‘/’.
This is at least the second support topic because of that
hmmm. This seems to be working as expected for me too.
