I have added a codesandbox iframe with different attributes but Discourse is just getting the src. Should I change something in Discourse Settings? I have already allowed this iframe and it is showing, but not correctly.
Just to be sure, did you add the iframe url (https://codesandbox.io/embed/codesandbox-frontity-rnclp) in whitelist? If not, search the site setting allowed iframes.
I have this domain: https://codesandbox.io/. Shouldnât be enough? I have found this code at Discourse where it whitelists just some iframe attributes:
If I include the attributes height and weight the iframe works fine, but I would like to allow the other attributes too.
Is there a way of allowing all codesandbox iframes? I thought including just the domain it would work.
Thank you!
EDIT:
I have tried adding this url in whitelist but it is not working neither.
I am also running into this problem. I would like to add a class on the IFRAME that I am embedding in my policy privacy post, which embeds the privacy tracking settings from our self-hosted Matomo installation. This would allow me to add a better border and some color to differentiate it from the rest of the privacy policy.
Despite having a class="foo" in my IFRAME element, it is being stripped out, apparently by the white-lister code above. Any chance this could be expanded to have a few more attributes allowed?
Rafael thanks for the statement, it clarifies my observed behaviour.
I would like to know whether you have any plans of releasing that lock for audio/video attributes of an iframe. Modern browsers manage accessibility quite good for those allowances, and there are increasingly interesting service offerings which would be great to integrate by users but just lack this type of accessibility.
Thanks.
This would be useful, but weâd also be happy with the allow attribute being whitelisted for all. Weâre currently running into audio playback issues with embedded Apple and Spotify podcast players. As others have mentioned, the issue is that the allow attribute is being stripped, which contains an important encrypted-media directive.
Since we are already strict about which domains can be used in iframes, having yet another setting where we set the allow string for each iframe and parsing the weird allow content format seems a bit much for me.
I made a PR that simply allows using anything in the allow attribute for already allowed iframes: