Jane_Jojo is experiencing an issue where comments from her Discourse-powered commenting system are not displaying on her food blog, with an error indicating the page was refused to be displayed in a frame due to an X-Frame-Options header set to ALLOWALL. She checks the headers and confirms the x-frame-options: ALLOWALL is set on her site, but the issue persists. Codinghorror suggests checking the header settings and notes that their blog, which also uses Discourse, works correctly. Jane_Jojo observes that her blog does not have the x-frame-options header, which is confusing. Sam suggests the header may be coming from her blogging software rather than Discourse, possibly due to a recent upgrade. Bobhy shares a solution, explaining that the issue can be resolved by modifying the Nginx configuration for Discourse to hide the x-frame-options header and set it to ALLOWALL instead bobhy.
What are the x-frame-options headers returning on your parent domain? You can inspect headers in the browser F12 console.
Per the docs
SAMEORIGINThe page can only be displayed in a frame on the same origin as the page itself. The spec leaves it up to browser vendors to decide whether this option applies to the top level, the parent, or the whole chain, although it is argued that the option is not very useful unless all ancestors are also in the same origin.
This is the response. It says ALLOWALL but no luck..
curl -X HEAD -I https://www.alittlebitofspice.com/indian-tandoori-chicken-in-oven-recipe
HTTP/2 200
date: Fri, 11 May 2018 21:05:18 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d9f19aff1bfc853cdb31d03b2f1813b8b1526072718; expires=Sat, 11-May-19 21:05:18 GMT; path=/; domain=.alittlebitofspice.com; HttpOnly
vary: Accept-Encoding
vary: Accept-Encoding
link: <https://www.alittlebitofspice.com/wp-json/>; rel="https://api.w.org/"
link: <https://wp.me/p90p7a-r6v>; rel=shortlink
x-frame-options: ALLOWALL
x-content-type-options: nosniff
age: 0
x-cache: uncached
cache-control: public
x-nginx-cache-status: HIT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 41979a5a5ee2a02e-SLC
Not sure. You should compare with my blog, which is working fine on the latest version of Discourse, and showing comments below the blog post: To Serve Man, with Software
Strange. You don’t have a x-frame-options. Maybe I should just hide it. But that does not seem right.
curl -X HEAD -I https://blog.codinghorror.com/to-serve-man-with-software/
HTTP/2 200
date: Fri, 11 May 2018 21:29:45 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d7dbb0eaab840a338093436369c32d7c91526074185; expires=Sat, 11-May-19 21:29:45 GMT; path=/; domain=.codinghorror.com; HttpOnly
status: 200 OK
x-powered-by: Express,Phusion Passenger 5.2.3
cache-control: public, max-age=0
vary: Accept-Encoding
last-modified: Fri, 11 May 2018 21:30:58 GMT
x-ghost-cache-status: From Cache
x-request-id: c61b67b333b14f47e359c57135e73eb7
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4197be29698da022-SLC
I am pretty sure that header is coming from your blogging software, not Discourse. So my guess is that you upgraded it recently and someone added the extra header.
I was having this same problem (right now, with up-to-the-moment Ghost and Discourse), and fixed it by changing the Discourse site, not the parent Ghost site.
And it was a struggle to get rid of the x-frame-options headers coming from Discourse! I ended up with this in my Nginx site configuration:
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_hide_header 'x-frame-options';
add_header x-frame-options ALLOWALL;