An iframe in a post reports not HTTPs

Support

AI-generated summary

The issue is about an iframe in a post reporting “not HTTPs” despite all content being served over HTTPS. cogdog shares that a specific H5P content type embedding an audio recorder is reporting this error. After checking with the developers, they suspect it’s not an HTTPS issue, but rather a feature policy issue related to granting access to the microphone. cogdog notes that adding allow="microphone *" did not help. Further investigation reveals that the allow parameter is stripped from iframe tags in Discourse, as reported elsewhere cogdog.

1

Our education community allows users to use iframes to insert H5P (HTML5) content which works great as an allowed iframe URL.

But one content type that embeds an audio recorder is reporting this error:

not-https
not-https1424×214 50.2 KB

All of our discourse content is served as HTTPs, and all urls in the embed are HTTPs.

This is the place where the error is reported in our discourse:

https://connect.oeglobal.org/t/contribute-your-voice-to-oeg-voices-opening-segment/3213/19

The same embed works as expected in a WordPress site Is This Thing On? – The H5P Kitchen

I realize this may be an issue with the way the source content tests the connection, but am trying to isolate what is different when iframe embedded in discourse.

2

Have you upgraded from the command line recently? Is force_https enabled?

3

There’s been a command line upgrade in the last 3 weeks. I am finding references to enabling force_https but not how to do this. As not a full on sys admin type but someone with all the keys, can you 'splain it to me?

4

If you search the admin settings for “force” and don’t see force_https, then it’s set already.

FWIW, I don’t see any http errors on the page you link.

5

Okay thanks, it’s not there.

The developers of the software indicate its probably not an HTTPS issue after all (they acknowledge a poorly worded error message) and more likely an issue of the iframe not granting the feature policy to request access to the microphone (adding allow=“microphone *” did not help.

This is hardly critical I am more curious than anything.

6

The issue is to grant access to the microphone via an iframe allow= parameter is stripped from iframe tags in discourse, as reported elsewhere.