Server refuses connection

[m4xr1s]

Server (frame) refuses connection when accessing a whiteboard file

Nextcloud 21 running with nginx + fpm

whiteboard integration 0.0.13

[julien-nc]

There can be many reasons for that.
Let's find out what happens.

1. Where is this message displayed? In the frame itself?
2. Was Spacedeck successfully launched? If you've got access to your Nextcloud's server system, check that with ps aux | grep spacedeck
3. If it's not running, are you running a 64 bits GNU/Linux?
4. If it is running, I would need to know if the frame target address (accessible with browser inspection tools) matches the Spacedeck endpoint config value. The config file can be found in /.../data/appdata_XXXXXXX/spacedeck/config/default.json
5. Is there any error message in nextcloud.log when you get this message?

[m4xr1s]

1. message is displayed in the frame itself

2. www-data 21298 0.0 0.2 914376 77056 ? SNl 15:46 0:01 ./spacedeck.nexe.bin

3. running 64bit Debian

4. Request goes to /index.php/apps/integration_whiteboard/proxy/spaces/32408?spaceAuth=59d49b6&nickname=maxris&spaceName=32408 (returns 400)

   endpoint in default.json: "endpoint": "[...]/index.php/apps/integration_whiteboard/proxy",

5. no errors in nextcloud.log when trying to access a whiteboard file

[davidramiro]

Reporting back the same issue on my end. Also Debian, Nextcloud 21, nginx, php-fpm 8.0.

From the browser console, it seems like it's a CSP issue:

Refused to frame 'https://nextcloud.mydomain.com' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'".

I use the Nextcloud default nginx config, which does not include any CSP directives like that, still, the HTTP CSP headers include default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none'.

[julien-nc]

Ok let's see if adding 'self' to allowed frame ancestors is enough. v0.0.14-1-nightly has been released. Could you try it?

You can get it with occ app:update --allow-unstable integration_whiteboard

[davidramiro]

The update via OCC didn't work, although extracting the tarball from releases did. The issue still persists though and the browser still reports back the same CSP directive. Anything else I can check to help debug?

[julien-nc]

@davidramiro Thanks for the feedback. Yes you can show me the CSP included in the main request (first GET) when you load the Files app page. It's in the network tab of browser dev tools. Select the https://blabla/index.php/apps/files/?dir=/ GET request and copy the "content-security-policy" of the response in "headers" tab.

[davidramiro]

Sure, here you go:

content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';script-src 'nonce-bWRNMlI5SlZGSDc5QmM4bnovYk5ndWQwdTR0ejJGYmNtVFYweG51RWU5bz06MDR0TUlQa3pKaGEvWEpacW44V3YwNHROeWNCQ2lSaUlxbVpBa0EvUURhcz0=';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self' data:;connect-src 'self';media-src 'self';frame-src 'self';frame-ancestors 'self';worker-src 'self' blob:;form-action 'self'

Interestingly, here it does include self.

Not sure if it's relevant, but one of the few GET requests that includes none when actually viewing a whiteboard file, comes from https://nextcloud.mydomain.com/apps/integration_whiteboard/space/1677402

[julien-nc]

one of the few GET requests that includes none when actually viewing a whiteboard file, comes from https://nextcloud.mydomain.com/apps/integration_whiteboard/space/1677402

This request is not done in the frame so it does not matter.

It's weird that the frame can't be loaded although you have expected CSP (frame-src 'self';frame-ancestors 'self';) in Files main page response.

In the refused requests, are all the domains matching nextcloud.mydomain.com?
Could you also check that the endpoint value in /.../data/appdata_XXXXXX/spacedeck/config/default.json is https://nextcloud.mydomain.com/apps/integration_whiteboard/proxy?

[davidramiro]

Yes, the blocked request does match the domain. This is the only request that the browser console shows as blocked:

And the value in default.json matches your string too.

[Rid]

@davidramiro I think maybe the 400 error in your last screenshot could be linked to #12.

[julien-nc]

@davidramiro @m4xr1s v0.0.14-2-nightly is out including #13. Could you give it a try?

[davidramiro]

Wow, that release came fast! I just tested the changes from #13 myself and it works now. Will test the release later, but if that's the only change, I'd consider this fixed.

[m4xr1s]

v0.0.14-2-nightly works for me
Thanks and good job!

[julien-nc]

@davidramiro @m4xr1s Thanks for the blazing fast feedback.

Let's go for v0.0.14.

[davidramiro]

Yup, the release works here too. Thanks a lot!