The discussion revolves around whether the Find & Replace feature in Discourse can modify text within iFrames, specifically for fixing Vidyard embeds that use protocol-relative URLs (//play.vidyard.com/) instead of https://. putty attempts to use watched-words to auto-correct the URL but finds it ineffective, suspecting the feature doesn’t process code inside iFrames. Bas explains that protocol-relative URLs are standard for avoiding mixed-content warnings and suggests the issue lies in Discourse’s iframe whitelist, which only accepts https:// URLs. putty confirms the whitelist doesn’t accept the non-https version and plans to open a support ticket for a workaround. Bas recommends contacting the Discourse host to hardcode the //play.vidyard.com domain in the whitelist.
Simply updating src="//play... → src="https://play... fixes this. I brought it up to the Vidyard team that all other embed options have https except for the iFrame route. Until they fix it on their end, I’m trying to have it auto-correct in Discourse. My thought is to use watched-words Replace with the above strings, but it doesn’t seem to be working. My guess is that Watched Words doesn’t look inside the code. Is that correct?
Using the double slash is a common and valid way of making sure that the embed uses the same secure/non-secure protocol as the embedding page. This avoids various warnings that the browser throws when mixing secure and non-secure content.
You have whitelisted https://play.vidyard.com/ in the allowed iframes settings. But because the embed code doesn’t specify the protocol.. the embeds don’t work?
If so, I think the best way forward would be for you to raise a support ticket with your Discourse-host (maybe that’s us), see if we can hardcode //play.vidyard.com in the whitelist; bypassing the input check or something similarly creative.
You are correct—the existing whitelisted path is https://play.vidyard.com/. I just tried adding the non-https version, and it doesn’t look like the settings accepted it:
Thank you for your help