Understanding/working with CSP, iframes, ancestors

support
1

We have Discourse installed on site1. We own/admin site2.tld and want to access the forum via an iFrame from a page there. I am not skilled in the art of CSP-fu, so assistance is appreciated.

I don’t want to disable ancestor restrictions, but temporarily, I unchecked the frame ancestor CSP:

image

The HTML so far is:

<iframe
  style="position:absolute;width:100vw;height:100vh"
  src="https://forum.site1.tld">
</iframe>

This still results in

Firefox Can’t Open This Page
To protect your security, forum.site1.org will not allow Firefox to display the page if another site has embedded it. To see this page, you need to open it in a new window.

I looked at Embedding but that feature seems to serve a different purpose. We don’t want to limit to a single topic, and the user will not be logged-in. Initially it’s OK if the user doesn’t login and the entire forum is available as read-only.

Suggestions? Questions?

Thanks!

2

Is anyone else embedding their site1 Discourse into their site2? Thanks!

3

We don’t recommend, nor test, using Discourse fully embedded in another site via iframes.

Instead we recommend having each site on it’s own domain, using links, single sign-on, and styling Discourse to match the visual of your main site.

2 Likes
4

Got it. Thanks!

5

Understanding the long-term consequences we’ve temporarily disabled CSP but still get a CSP warning from Firefox. Is a restart required?

image
image722×316 10.1 KB

Here’s the application/challenge. Maybe there’s an easy solution…

There is one Discourse server and, as usual, any number of user accounts and guests. Registered users have an app that hosts a local webserver. A web page is created in this app and accessed from a local browser as http://192.168.1.1:8080. That web page offers the forum via an IFrame.

We have no control over the subnets serving the content, so the IP can be from any common NAT/DHCP. But we do have full control over the following:

  • The Discourse installation and server.
  • The content that is served.
  • The port# is generally 8080, configurable by the user, but will never be 80 or 443.
  • Because this is local content and not mission-critical, it is not SSL-secured.
  • Users must have a Discourse account and must login to Discourse for write-access

As to security:

  • The public forum is net-accessible via hostname.
  • Net access is of course always SSL-secured
  • No one can create forum content unless they are logged-in.
  • So yes, the local page with the IFrame is served as HTTP: but the IFrame source is HTTPS://forum.site.tld. (This protocol difference might be what’s causing the failure to access the forum even with CSP disabled.)
  • Once the user launches their browser, to access the local server they must enter a password. We could SSL-enable that page if required in order to keep consistency between that ancestor page and the the IFrame to the SSL-enabled forum site.
  • We do not have or have intent to script through the IFrame into Discourse. All we want to do is to host the forum in a container.

Here are some random ideas that might not have any merit:

  1. Allow users to get an API key from their Discourse account page, which they can put into the app, which will then get passed to Discourse in a cookie or some other way. This confirms that while the user is not CORS or CSP-compliant, they do have authorization to access the resources.
  2. Have the app inject a token into the IFrame URI to Discourse. Simultaneously use an API call to get Discourse to allow inbound connections with that token. (Yeah, that would need to be coded)
  3. Getting even more cringe… Create a page on a community site that opens an IFrame for the subnet content, and another IFrame to the forum. This one site can be authorized for cross-origin access.
  4. Give up on trying to get around the policies and use target=window to open Discourse outside of the application window.

Without resorting immediately to option 4 … any ideas? Thanks!