X-Frame-Options in nginx to allow certain subdomain
Francis Daly
francis at daoine.org
Fri Nov 26 23:30:56 UTC 2021
On Fri, Nov 26, 2021 at 04:04:46PM -0300, Daniel Armando Rodriguez wrote:
> El 2021-11-26 11:19, Francis Daly escribió:
> > On Fri, Nov 26, 2021 at 08:43:58AM -0300, Daniel Armando Rodriguez
> > wrote:
Hi there,
> > > One of them is a NextCloud + WOPI based LibreOffice Online Solution,
> > > as such
> > > it needs to access resources in WOPI server subdomain. What I need
> > > is my
> > > nginx to allow X-Frame-Options for WOPI server subdomain.
> >
> > It sounds like you want a request from the client, to have a specific
> > header with a specific value in the response when being proxy_pass'ed
> > through nginx.
>
> Well, it's not a browser request but OxOffice Online one. Whith
> X-Frame-Options set to SAMEORIGIN I can work, can edit documents,
> spreadsheets and so on. The issue raises when doing a presentation as a new
> browser window is displayed. And console says
>
> chromewebdata/:1 Refused to display 'https://wopi.dominio.edu.ar/' in a
> frame because it set 'X-Frame-Options' to 'sameorigin'.
Ok, so a request to "wopi" currently includes 'X-Frame-Options sameorigin'
in the response; and you don't want that.
> Nextcloud is hosted on it's own subdomain (cloud.dominio.edu.ar) and WOPI
> web services are consumed from wopi.dominio.edu.ar
>
> > Can you show one request that you make, and the response that you get,
> > and the response that you want to get instead?
>
> If I disable X-Frame-Options set to SAMEORIGIN presentation appears as it
> should, but I don't like the idea to dissallow X-Frame-Options just for one
> service.
I think that says that when you turn off X-Frame-Options for all servers,
the response from wopi does not include the header, and things work
for you.
Does "disable X-Frame-Options set to SAMEORIGIN" mean "have no
X-Frame-Options at all"; or "have X-Frame-Options set to allow-from
cloud"? (Or: something else?)
But you don't want to turn off X-Frame-Options for all servers. Are you
happy to turn off X-Frame-Options for the wopi server?
(I'm trying to find out, what is the specific response you want nginx
to provide.)
> > I suspect it is "the browser did not end up doing what I want"; but from
> > an nginx perspective it would be easier if you could say "I want *this*
> > response but I get *that* response". (What the browser does with the
> > response is less interesting, from this viewpoint.)
> > If you can show a complete-minimal config that shows the problem that
> > you see, it may become clearer what changes are needed on the nginx
> > side.
> NextCloud Server =
> https://pad.unau.edu.ar/p/r.12c074621fc8c7a6ab900a0899872dbf
> Wopi Server =
> https://pad.unau.edu.ar/p/r.9b59663162dd956d7fe6604ba9e0870c
> Nginx SSL =
> https://pad.unau.edu.ar/p/r.861b2c17a9ad10e0c741a0588065e317
Based on the current words there, I think that any request to "wopi"
will include the 5 response headers listed as "add_header" in the third
link (including X-Frame-Options SAMEORIGIN); and any request to "cloud"
will not include those 5 headers, but will include Front-End-Https and
Strict-Transport-Security.
Is that what you currently see; and is that what you want to see?
(That is: X-Frame-Options is already turned off for "cloud".)
(For example: "curl -I https://cloud.dominio.edu.ar/" will show the headers.)
Based on that... I'm not sure what nginx behaviour you actually want.
One possible suggestion is:
* remove the add_header X-Frame-Options line from ssl-params.conf
* wherever you currently have "include ssl-params.conf", add the line
'add_header X-Frame-Options SAMEORIGIN;'
* except in the "wopi" server, add the line 'add_header X-Frame-Options
"allow-from whatever";'. Or maybe omit the line entirely.
(I suspect that "whatever" will be "the cloud url"; but it is "whatever
chromewebdata wants to see". The header is irrelevant to nginx; only
the thing reading it cares what it says.)
Hopefully this will help point you towards the config that you want.
Cheers,
f
--
Francis Daly francis at daoine.org
More information about the nginx
mailing list