Stop settings X-Frame-Options on SUMO

VERIFIED WORKSFORME

Status

Infrastructure & Operations
WebOps: Other
VERIFIED WORKSFORME
3 years ago
3 years ago

People

(Reporter: mythmon, Assigned: atoll)

Tracking

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/726])

(Reporter)

Description

3 years ago
In bug 1136599 we are debugging why a particular view in SUMO can't be framed. We have a middleware that ensures that X-Frame-Options is set appropriately, and on almost the entire site it should be set to "Deny". However, on this one particular view we want to allow framing (since we made this view specifically for iframes).

We changed the framing policy in kitsune, and it works locally, but when deployed, the view is still blocked from iframes. This leads me to believe that there is something in Zeus or Apache adding this header.

Since we manage this in Django, can we remove any assertions about X-Frame-Options from Zeus and Apache?
(Assignee)

Updated

3 years ago
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/726]
(Assignee)

Comment 1

3 years ago
I wasn't able to find any instances in Puppet that would be deploying this header for 'support.mozilla.org'. It's present for other sites (nightly, planet, wiki-dev/stage, activations, blog, forums, hacks, quality, wiki, pulse-dev).

I wasn't able to find any Zeus configs on zlb9 (hosting vservers for sumo dev/stage/prod) that reference this header.

Verified first that the URL provided returns the XFO header:

$ curl 'https://support.allizom.org/fr/kb/comment-passer-appel?mobile=1&minimal=1'
X-Frame-Options: DENY

And then verified that the *prod* sumo backend nodes are setting that header:

$ curl -I -H 'Host: support.mozilla.org' 'http://10.8.81.40:81/fr/kb/comment-passer-appel?mobile=1&minimal=1'
X-Frame-Options: DENY

And then verified that the *stage* sumo backend node still does, too:

$ curl -I -H 'Host: support.allizom.org' 'http://10.8.81.80:81/fr/kb/comment-passer-appel?mobile=1&minimal=1'

X-Frame-Options: DENY
X-Backend-Server: support1.stage.webapp.phx1.mozilla.com

And then verified that the *dev* sumo backend node still does, too:

$ curl -I -H 'Host: support-dev.allizom.org' 'http://10.8.81.75:81/fr/kb/comment-passer-appel?mobile=1&minimal=1'

X-Frame-Options: DENY
X-Backend-Server: support1.dev.webapp.phx1.mozilla.com

I checked on disk on support1.dev and it has no matches for X-Frame-Options of any case:

$ sudo grep -ri x-frame-options /etc/httpd/conf* /etc/httpd/mozilla* | wc -l
0

And there are no SetEnv or WSGI directives in the configs that are setting this.

On -dev, I strace'd kitsune-ssl and captured it sending the XFO header:

[pid 16484] writev(11, [{"Status: 405 METHOD NOT ALLOWED\r\nX-XSS-Protection: 1; mode=block\r\n [BLAH BLAH BLAH] X-Frame-Options: DENY\r\nSet-Cookie:  msumo=on; httponly; [BLAH BLAH BLAH]", 410}], 1) = 410

So I'm not sure we can do anything more to help you here - but you're welcome to have me or anyone in webops/MOC run those curl commands for testing, or you should be able to run them from supportadm yourself.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Updated

3 years ago
Assignee: server-ops-webops → rsoderberg
(Reporter)

Comment 2

3 years ago
Thanks for looking into this so in-depthly. I looked at this again today and noticed something new in Kitsune: We have a caching layer for this page, and the cache does not include the X-Frame-Options header. So any time the result came from the cache, it was broken, but any time there was a cache miss it worked. That's why I couldn't reproduce this in my local dev environment: the cache was always cold when I tested.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.