Hi all,
We have a Discourse instance embedded in an iframe within our application, and it’s working fine as such. However, when an unauthenticated user tries to access a page that they do not have access to (either doesn’t exist or is group-restricted), the response now mysteriously includes X-Frame-Options: SAMEORIGIN and browsers block the frame from rendering.
I checked on different versions starting with 3.3.1 stable to almost current bleeding edge (last tested mid-last-week).
It’s running on a different subdomain than the parent app and configured for embedding with allow_embedding_site_in_an_iframe: true and by debugging a clean instance, I noticed that in such a case, conditionally_allow_site_embedding method in ApplicationController is not called, thus leaving the header in response (GH link), and tracked it to throwing an exception at some point and thus breaking out of the flow.
Reproduction:
- Run a clean instance of Discourse (or any instance actually – this happened in local, test and production environments) and configure it with
allow_embedding_site_in_an_iframe: true. - Embed it into an iframe in a website served over HTTPS using a non-existent path to trigger a 404 error.
Expected: Browser allows Discourse to render.
Actual: Browser prevents Discourse from rendering due to X-Frame-Options: SAMEORIGIN present in the response.
Sidenote: It’s running through a DNS-only Cloudflare and we tried to delete the header in proxy-mode, however, we cannot put it in proxy mode due to CF filtering out cookies which are required for our custom SSO implementation, so this is a no-option for us right now.