Support: How to debug WebDAV sync issues to Nextcloud instance

[bentolor]

What is the problem?

I can successfully connect to a webdav endpoint of a nextcloud instance with Nautilus, but fail to use it with violentmonkey.

How can I learn more about the error.

It displays Syncing (1/2) and the failed.

How to reproduce it?

1. Have a WebDAV endpoint i.e. a nextcloud instance like https://github.com/bentolor/docker-nextcloud-collabora-postgresql-letsencrypt
2. Set WebDAV and davs://SERVERNAME/remote.php/dav/files/USERNAME/ as target
3. Press save

What is the expected result?

Some syncing happening and files appearing on the webdav target

What is the actual result?

Only a Failed is displayed.

F12 console in Firefox does not provide any output.

[tophf]

The background script has its own devtools console and network panel, please check those.

I thought only web URLs like http/https/ftp are supported by fetch and XMLHttpRequest so I doubt yours will work but I'm not an expert on this...

[bentolor]

Thanks @tophf for you feedback: Yes davs:// is the officical protocol. I also tried https://

1. The debugging does not work as documented: I had to change/enable an option inside the dev tools to see violentmonkey at all. Unfortunately it does not reveal any error messages

2. Unfortunately I'm also unable to debug the extension due to the minimized source.

3. On a second look I did found a new Violentmonkey folder on the target. But the error message/handling stays more or less the same and it does not pull the scripts on a second pc.

4. I could provide you a temporary account if this helps. Does any developer have this feature in active use?

[tophf]

I hoped you would see the network request in the network panel of devtools. Anyway, like I said browsers can't make requests to custom protocols at least according to the specification of fetch and XMLHttpRequest...

P.S. You can write me an email, see my profile.
P.P.S. attaching a debug build of Violentmonkey: vm-debug.zip

[bentolor]

TL;DR: It is working in vanilla configurations!

Okay : I invested some time but did not achieve any significant results:

• After temporarily loading your debug script the syncing started to work on one Firefox reliably though in two other, identically configured FF not. After some tickling & playing and deletion of the created folder it failed there, again. On the other instances it fails continuously.

• I'm unable to see any network requests, only messages like

onMessage#46 
Object { cmd: "UpdateSync", data: (4) […] }
 
Object { frameId: undefined, tab: undefined, url: "moz-extension://df055bd3-8e3b-4f2c-acb8-93b2f635cda4/background/index.html" }
browser.js:119:54

I'm also unaware where to put the breakpoint, because

violentmonkey/src/options/views/tab-settings/vm-sync.vue

Line 171 in 15eae94

if (service.syncState === 'error') return this.i18n('msgSyncError');

seems to interpret the return code of another source i did not find.

• I was able to reliably get it working with a vanilla firefox configuration. So obviously it has to to something with my configuration/additional extensions.
  • Interestingly I sync all my settings over all instances, so it should have not worked at all
  • I disabled all the extensions and retried without any luck

So unless you can give me any further hint where to set a breakpoint I'm afraid that this functionality won't work for me and it's unreasonable that you waste any time on my issue.

Thanks for your support!

[tophf]

Looks like you're still looking at the console (and network panel) of the tab, not of the background script.

[bentolor]

Okay: Can you help me: I puzzled over 10 Minutes on you original script how to access the background script debugging.

What I'm doing is:

1. Open violent Monkey Extension Settings
2. Press F12
3. Press F1: Tick "Debugging tools for Browser-Chrome and Extensions"
4. Go to debugger panel. There select Violentmonkey node.

What am I doing wrong?

[tophf]

See my first comment, it links to the instruction.

[tophf]

Maybe it's not obvious that you need to open about:debugging first. I blame Firefox documentation for that.

[bentolor]

I did not see it. Relooking now I found the culprit:

enter about:debugging in the URL bar.
in the left-hand menu, click This Firefox (or This Nightly).
click Inspect next to your extension.

[bentolor]

Ah... there it is!

GET https://myserver/remote.php/dav/files/ben/Violentmonkey/Violentmonkey
[HTTP/2 200 OK 107ms]

PROPFIND https://myserver/remote.php/dav/files/ben/Violentmonkey/
[HTTP/2 401 Unauthorized 90ms]
Object { url: "https://myserver/remote.php/dav/files/ben/Violentmonkey/", data: "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre\\DAV\\Exception\\NotAuthenticated</s:exception>\n  <s:message>CSRF check not passed.</s:message>\n</d:error>\n", xhr: XMLHttpRequest, status: 401 }
index.js:1:17690

[tophf]

@gera2ld is there something you can do about this? Does the error above look like something we can/should extract from the response and show in the UI?

[bentolor]

TL;DR The culprit are those extra cookies sent with the request: Obviously those are invalid and seem to override the basic authentification sent with the request

Ok: At least now I better understand why it is working sometimes and why not.

A typical requests looks like this. NOTE: It looks more or less exactly the same for the successful GET as well as for the failing PROPFIND:

Host: myserver
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: */*
Accept-Language: de-DE,de;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Authorization: Basic fooobarstring
Connection: keep-alive
Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; nc_username=ben; nc_token=fooo; nc_session_id=09452317926c9090e08f1d83ed0da1e7; oc3x8sg7kmlk=09452317926c9090e08f1d83ed0; oc_sessionPassphrase=wFZFnzt7pHuzlklTElongcryptigstringC
TE: Trailers

1. The Basic authentification which is sent by violentmonkey does not work at all: If I curl the second request with the cookies I get that 401 with the message <s:message>CSRF check not passed.</s:message>
2. . If I curl PROPFIND request without the cookies, it succeeds!
3. It seems that Nextcloud prefers those auth Cookies before any basic authentication. They keep reappearing although I tried to delete them with all means I know: Storageerazor, manually in "Storage Tab", etc.. Really: I do not know where they are coming from and where those are stored.
4. Entering a wrong password in VM settings does not break the sync! It looks like: If those session cookies are valid: Sync is working. If those cookies are invalid: Requests is breaking. Regardless of the Basic credentials.

This is all so FUBAR!

My proposals:

1. Always send requests without any cookies.
2. Preserver the HTTP status code and present to the user

[gera2ld]

Seems to be prevented by Nextcloud/Owncloud's protection against logout CSRF.