[regression] iframe embedding broken with allowed src domain

Hi there, I have added https://www.tickcounter.com to my allowed_iframes, but this script still doesn’t appear:

<div style="left:0; width:100%; height:0; position:relative; padding-bottom:25%; margin:0 auto"><iframe src="https://www.tickcounter.com/widget/countdown/5847336" style="top:0; left:0; width:100%; height:100%; position:absolute; border:0; overflow:hidden" title="My countdown"></iframe></div>

Nothing in the error logs as far as I can see.

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:

<iframe src="https://www.tickcounter.com/widget/countdown/5847336" width="100%"></iframe>

What do you see when you navigate to the post and then open the “elements” tab of your browser’s developer tools?

How about if you open the “console” tab on the developer tools? Are there any errors?

:thinking: hmmm. This seems to be working as expected for me too.

admin - all site settings - allowed iframes:

previewer:

cooked post:

1 Like

Thanks a lot for the replies.

<div class="regular contents"><div class="cooked"></div><section class="post-menu-area clearfix"><nav class="post-controls expanded">

Hmm there are some errors:

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.

OK Firefox shows me another console message:

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.

2 Likes

Hi there, no, I don’t use Cloudflare.

2 Likes

yes I can get the iframe to work. something is blocking it on your forum.

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.

You seem to say that you’re using a dns block list and it’s breaking things, so don’t use it?

2 Likes

Did you add

or

https://www.tickcounter.com/ to the allowed iframes setting?

3 Likes

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:

<!DOCTYPE html>
<html lang="en">

<head>
  <meta name="description" content="Webpage description goes here" />
  <meta charset="utf-8">
  <title>Change_me</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="author" content="">
</head>

<body>

<div style="left:0; width:100%; height:0; position:relative; padding-bottom:25%; margin:0 auto"><iframe src="https://www.tickcounter.com/widget/countdown/5847336" style="top:0; left:0; width:100%; height:100%; position:absolute; border:0; overflow:hidden" title="My countdown"></iframe></div>

</body>
</html>

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

3 Likes

when you add the link, it should be showing you an error message below the field that you needed another forward slash

image

3 Likes

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

3 Likes

yea I was wondering if that was the case - that existing links broke somewhere along the way. :thinking:

1 Like

Is it possible to check the existing input and notify admins about links that don’t work anymore?

3 Likes

For me I think the biggest source of confusion was the fact that it’s called a “domain” when it’s actually a URL.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.