Embedded comments not displayed due to X-Frame-Options DENY

Support

AI-generated summary

The discussion revolves around a problem with embedded comments not displaying due to an X-Frame-Options DENY error. The original poster, guiniol, set up comments on their blog using a Discourse guide but encountered the issue.

After troubleshooting, guiniol discovered that the problem was caused by their nginx configuration, which added a DENY header to the end of the X-Frame-Options field. To resolve the issue, guiniol initially added add_header X-Frame-Options "ALLOWALL"; to the nginx configuration. However, this resulted in two ALLOWALL headers, so they set it to add_header X-Frame-Options ""; to resolve the issue.

Later, guiniol realized that they had previously added the X-Frame-Options DENY header as a security measure when setting up SSL.

Ultimately, guiniol provided a solution using a map directive in the nginx configuration to set X-Frame-Options to ALLOW-FROM for specific embed URLs while maintaining DENY as the default.

1

Hello,

I setup comments on my blog using this guide: Embed Discourse comments on another website via Javascript

It worked at some point, but now the comments are not displayed. In the firefox console, I see:

Load denied by X-Frame-Options: https://... does not permit framing.

And in the network section, for this resource, I see that:

X-Frame-Options: "ALLOWALL, DENY"

I have no idea what’s going on, but I think it may be related to SSL.
Both the blog and the discourse instance are behind a reverse proxy which does the actual SSL.

The blog is here: https://avril4th.com
and the discourse instance: https://discourse.avril4th.com

I’m not sure what other information could be relevant.

Cheers,

2

Is “force https” set in your Discourse settings?

3

That is… extremely weird. I don’t think there’s any point in an ALLOWALL, DENY record as “ALLOWALL” doesn’t actually mean anything to the browser, just analysis tools (checking if the X-FO is missing, i.e. you didn’t think about it).

I’m guessing the proxy is adding , DENY to the end?

4

No. Since discourse talks http with the reverse proxy and the reverse proxy does the ssl, I wasn’t sure this wouldn’t break my setup.

5

I don’t think so. I’m using nginx, and I added X-Forwarded-For, X-Real-IP and X-Forwarded-Proto, but that’s only on the way to discourse I think.

6

I’m running such a setup with that option checked, so it should be working fine :slight_smile:

7

Alright. Tried it. Discourse still works, but it didn’t change anything to the embedding.

8

Just to make sure, I added add_header X-Frame-Options "ALLOWALL"; to the nginx configuration. The comments are displayed properly in this case. So the question is what is adding DENY at the end, and why?

9

So… it seems it was nginx adding the DENY at the end. Not sure why exactly, but I think it may have to do with proxy_set_header X-Forwarded-Proto $scheme;. When I added add_header X-Frame-Options "ALLOWALL", I ended up with two ALLOWALL so I set it to add_header X-Frame-Options "" and now I only have one (like I should).

10

For anyone else having the same problem, this is what I added inside the location for discourse:

if ($args ~ "embed_url=https%3A%2F%2Favril4th.com%2F") {
    add_header X-Frame-Options "";
}

Not an nginx expert, so maybe there are better ways to do it.
EDIT: talked to experts in nginx. See solution below

11

Well, it was me all along. When I added ssl, I also added a few lines for security, one of which was the X-Frame-Options DENY. Mistery solved on that front.

12

In case someone stumbles upon this thread and wants X-Frame-Options DENY as defaults but still wants to embed comments, here is the solution direct from nginx (apparently ifs should be avoided where possible:

outside of the server clause:

map $arg_embed_url $xfo {
        default DENY;
        ~^https%3A%2F%2Favril4th.com%2F.* "ALLOW-FROM https://avril4th.com/";
}

and then inside the location where you want to allow embeding:

add_header X-Frame-Options $xfo;