Yes that's probably it. I wonder if this test cookie is some kind of security measure - maybe it's testing that it's being sent back, but normally we shouldn't have to send anything back other than the auth credentials.
I think it's not the test cookie that is the problem, it's another one, not sure which.
Joplin shouldn't send any cookies at all, not sure how easy it is to do though.
Thank you @Coffee – Very happy to see my enquiry generated such a vividly dedicated line of responses. I wish I lnew more about the inner workings of both Joplin and Nextcloud, so I could contribute some more valuable details.
One addendum I have is that apparently I jumped to conclusions about the failure pattern in regard to which one of the accounts syncs and which don't. So I think I need to summarise the situation once more:
I have these accounts:
Joplin user 0 (default profile) sync set up with Nextcloud user 0
Joplin user 1 sync set up with Nextcloud user 1
Joplin user 2 sync set up with Nextcloud user 2
Joplin user 3 sync set up with Nextcloud user 3
All accounts sync fine on the Joplin client for macOS. When setting up sync on the Android client, hitting the button for testing the configuration button produces a positive result, and during my first attempts the user 0 default profile synced alright, while user 1, user 2, and user 3 produced the errors from the screenshot of my original post. Then the profile that synced fine was all of a sudden user 1, while user 0, user 2, and user 3 began to generate the aforementioned errors. I thought the switch to a different profile working was caused by a reboot, but I know now that that can be ruled out. Currently the working sync is on the user 3 profile, but I have no idea what I did to effect this.
Thank you kindly for helping me get to the bottom of this issue!
1 Like
I think that's because those cookies have a timeout. So after a while they become invalid and from that point whichever account syncs first works, all the others do not.
By the way, how do you connect to your account @moontan @Coffee, is that with email/password or with an application password? Do you have MFA enabled in Nextcloud?
email/password
MFA not enabled
Clearing cookies before each request (using react-native-cookies · GitHub) seems to fix the issue. Although this alone may not be enough because some requests are done using rn-fetch-blob - this may need to be handled separately.
But at least now it seems pretty clear what the issue was.
1 Like
Application password generated by NC.
MFA enabled.
I love good news!
Or am I being too optimistic again and getting my hopes up too soon?
I only did a quick check but it seemed that deleting cookies before every request has solved the issue.
Someone still need to implement the fix properly, unfortunately I don't have the time to do it myself at this time.
I also assume that it is the behaviour of an underlying network library of Android.
My words as a layman for it were WebDAV Stack.
I wonder if the bug should be reported to Nextcloud. It looks like it's looking at the cookies (that we didn't set) and reject the request based on this, even though we provide valid Auth credentials with that same request.
Also cookies have nothing to do with WebDAV as far as I know, at least I can't think of any implementation that uses them.
It's not OS-level, just a 3rd party lib used by React Native called okhttp
But from their point we do set them. Or rather okhttp does.
I guess whether it's a bug or not isn't entirely clear. I don't remember if WebDAV specification says anything about cookies at all.
Also, it depends on whether this cookies requirement is specified anywhere in their docs. If it is, then I'd argue it's a bug in Joplin, otherwise it's less clear.
In my opinion, the important thing in this case is whose decision it was to install this library on our Android.
Was it Google's or Samsung's decision to deliver this component with the operating system, or was it Joplin's decision to deliver this library with Joplin?
Is it a matter of https ://square.github.io/okhttp/ ?
More generally I can't think of any WebDAV API that uses cookies for authentication, that's normally something meant for browsers.
It seems like they have some code somewhere that says "if invalid cookie => error". While they should actually check the headers for authentication, especially since it's how the connection was initiated.
1 Like
In my opinion, it would be a good idea to report the issue to NextCloud. However, this would have to be done by one of the Joplin experts. I would be willing to take part in the dialogue. However, I do not see myself in a position to represent this issue at NextCloud myself.
However, two aspects must be taken into account:
First:
Should the workaround suggested by roman_r_m, which could probably be implemented relatively easily in Joplin, be implemented relatively quickly at the same time?
Second:
Could it be that it is not the NextCloud people who have to solve the problem in their own code, because it could also be a 3rd-party library on the server side?
A quick google search shows it's possible:
1 Like
The dependency chain goes like this: Joplin - React Native - okhttp
But what does it matter? It's not like this is a bug in okhttp.
1 Like
Then, in this case, it doesn't matter.