@notplants why is there an iframe? Where is it defined

I think the problem is caused by the iframe, not the tunnel or the TLS.

These apps are just configured to refuse to run inside iframes, it looks like. So getting rid of the iframe should fix it

@forestjohnson the iframe seems to just be how the cryptpad software was written -- I didn't add anything to it.

you can see it by inspecting https://crypt.commoninternet.net

there is an iframe with the src of https://sandbox-crypt.commoninternet.net

if you go directly to https://sandbox-crypt.commoninternet.net then it says this sandbox app was not meant to be used directly

-

I'm not sure why cryptpad uses this iframe design, but maybe there is a reason?

the case with the onlyoffice iframe within nextcloud is also just part of how the integration is written

@notplants oh wtf. Interesting. Sorry, can't check out the sites rn, I'll take look later. Maybe browser origin issues then? Are they on different domains inside vs outside the tunnel ?

<3 @forestjohnson for both of my tests i've been using the same domain names on both sides of the tunnel

@notplants ugh wtf is this software doing. U really nerd sniped me here, I thought it would be simple but obviously its not

@forestjohnson im still head-scratching over here too

@notplants i think this header is the problem. maybe the tunnel is adding that ?

You can check by viewing the HTTP traffic at various different points. Its easy to do if its plain http with no tls. my favorite tool to do it: https://git.sequentialread.com/forest/httpflow

watch the response headers coming out of the http server and also watch the response headers on the VPS server.

httpflow should work on the app server.
If the tunnel connects to the app server via HTTPS, you might not be able to use httpflow there.

then in the browser you just use the network tab instead of httpflow.

@forestjohnson need to go now, but going to dig more into this later. ty for the ideas

@notplants btw for context, im just guessing again here, but i know that `X-Frame-Options: SAMEORIGIN` is a common "security hardening" header that a lot of things will just blanket apply to everything. It just happens to break cryptpad. IDK why the hell cryptpad uses an iframe tho. IMO thats probably a bad idea, it makes the software more complex. I guess maybe they have to in order to easily integrate onlyoffice or whatever it is ?

@forestjohnson your intuition about someone tacking on `X-Frame-Options: SAMEORIGIN` as a general security hardening thing was correct and enough for me to figure out the issue :)

I ran `grep -r "X-Frame-Options" /etc/nginx` on the VPS and found an additional nginx config in /etc/nginx/conf.d/security.conf.inc where this header was being tacked on

I commented this out, as well as a few other headers it was tacking on, and now cryptpad and nextcloud+onlyoffice are working just fine

I assume this security.conf.inc config is created by yunohost on the VPS, even though I don't actually want it for my usecase

I guess this a downside of my setup using yunohost on the VPS as the gateway, which is really more multi-purpose than my specific usecase and has extra junk

cc @j12i @alive

@notplants @j12i @alive

Github Issue https://github.com/cryptpad/cryptpad/issues/1732

@notplants @j12i @alive

And issue on yunohost repo as well

https://github.com/YunoHost/issues/issues/2498

@forestjohnson @j12i @alive

I think this issue might be a little unfair to yunohost because my setup is kind of unusual and maybe not entirely what they are building for

if you just install cryptpad on a yunohost server directly it will work

the issue is my setup was yunohost (vps) with a reverse proxy to a tunnel to cryptpad running on my homeserver

although could see this as not ideal (?) specifically for the "redirect_ynh application for yunohost" ... maybe the reverseproxy/redirect app shouldn't be adding any of those headers if they are explicitly set

https://github.com/yunohost-apps/redirect_ynh