iOS app does not work with WebDAV plain HTTP

[Kommander78]

After uodating the iOS-App of Joplin to version 12.3.1 I can not sync with WebDav-Target. I checked the destination, username and password. It s all right.
I get the error message when I test the connection: Network request fail.
E2EE ist disabled.

[laurent22]

Can you check on the server log what might be the error?

Also did you perform the sync target upgrade?

[Kommander78]

There are no new entries on /var/log/apache2/access.log when I start a sync from iOS device.
It seems that the iOS device can not connect to or reach the WebDav server.

[laurent22]

What's your WebDAV server? Do you use a self-signed certificate?

[Kommander78]

I only use a http connection, no https.
The server is apache2 (2.4.38) on Raspbian 10.

[Kommander78]

When I use same URL (http://.../joplin), username and password with Safari on this iOS device I get a list of all files on WebDav share.
Before updating iOS client (old version 12.2.1) there were no sync problems.

[laurent22]

Hmm, I thought http hasn't been working for a while on the iOS app due to the security policy so I'm surprised it was working in 12.2. Perhaps you could switch your server to https to solve the issue? Otherwise maybe there's a way to fix the app but it might take a while, assuming it's ever done.

[Kommander78]

Same problem with self-signed https connection. There no new entries on log file (/var/log/apache2/https_access.log) when I try to sync with Joplin. When I open the same URL with Safari there an warning page and after confirm I see all files in directory.

On client log there is a red error message with the text "08-16T22:42:29: Synchronizer: "TypeError: Network request failed. ...
"TypeError" sounds not good.
Do you need the full log entry?

[Kommander78]

Maybe can this help you: When I use IP address instead of hostname in URL it works perfectly with http.

[laurent22]

Self-signed certificate would also give this error. I assume it's not possible to install something like Let's Encrypt? As for the IP address trick, I didn't know about this, so I guess you can do that for now in any case.

I'll keep the bug opened in case others have the same issue.

[techloghub]

I had the same problem with joplin in the same version 12.3.1. I couldn't use WebDAV server. My server was built by nginx, and when I replaced http domain by the ip of my server, it worked successfully. Maybe the problem is about DNS?

[haowenwu]

Same here. Only IP address works for me after upgrading.

[hevjay]

Same here.

[banigithub-2]

Is this the new iOS 14 Local Network Permission? I think iOS apps now need to request local network access from OS, which then prompts the user to allow. Joplin App will then appear in iOS Settings -> Privacy -> Local Network

IP doesn’t work for me as Joplin Server throws invalid origin error as it’s expecting the client to call the APP BASE URL.

I’m also running iOS Joplin client 12.3.1, syncing against Joplin Server 2.2.10 running as Docker on MacOS

[banigithub-2]

Scratch that - if I entered the IP address it added the Local Network Permission! Still get invalid origin on IP address though.
Reverted back to hostname, and get the Network Request Failed error when ‘Check synchronisation configuration’.

I’ve got an app that allows me to use curl on the iOS device, and that can connect to the Joplin Server. Mysterious!

[Fruzzle]

Bug in iOS app v12.3.1 confirmed. Running iOS 12, using WebDAV server over http. Worked fine under previous app v12.2.1, but synchronization fails after upgrading to v12.3.1 with the attached log entries.

I switched the URL to use an IP address as suggested, and that works. This is not a good solution, however, because IP's are often dynamic, hence the use of DNS names. Also verified that no connection is established with the WebDAV server when using a DNS name in the URL.

[Fruzzle]

I wanted to mention that this is a duplicate of bug #5350, which I accidentally posted some additional info to. Maybe 5350 should be closed as a dupe. There may be other duplicates as well, as it seems to be a pretty ubiquitous bug affecting all iOS users who sync over WebDAV. Although the IP address workaround does work, it is hardly a solution, so I'd like to suggest maybe remove the Solution label from this one, so it doesn't get overlooked. Just sayin'...

[Fruzzle]

@laurent22: My apologies if this issue is already being worked on, but one suggestion that might give iOS users a bit of "breathing room" would be to resubmit Joplin app v12.2.1 to the app store (probably as v12.4.1), so that once it gets re-approved by Apple, people can essentially 'downgrade' to the prior release while a fix is being worked out.

[laurent22]

I don't know if anybody is working on this. I'd accept a PR if it's not too risky (making the app less secure) or hard to maintain.

Personally I won't look into it because OS vendors like Apple or Google constantly deprecate or stop supporting things they consider insecure, such as plain http or self-signed certificate. So it's a lot of work to keep up with all this, and the long term benefits aren't obvious.

In any case, the message from these vendors is clear - don't use http, don't use self-signed certificates, etc. and I think it's easier to go along with this. All this stuff will only get more and more difficult to use anyway.

[Fruzzle]

Thanks, @laurent22, but in this particular case, I'm not using HTTP, nor am I using a self-signed certificate. The iOS app simply stopped syncing over WebDAV when I upgraded it from v1.22.1 to v1.23.1. Nothing else changed, just the Joplin app itself. Most of my dev experience is on the back-end, so I may not be able to find a solution to this. I suspect it may be the fault of an upgraded library that krept in with v1.23.1, given that 1.22.1 still works perfectly.

[laurent22]

Is there some error on the server log when this Network Request Failed error happens?

[Fruzzle]

@laurent22: No, the app never attempts to make an outbound connection at all, so the server never sees any incoming connection attempts. It appears that the Synchronizer fails very early in the process, as it is unhappy with the WebDAV URL (which contains a DNS name, e.g. https://my.webdavserver.com/etc/etc). If I replace (in this example) my.webdavserver.com with the actual IP address that the DNS name resolves to, then the synchronizer successfully connects and works fine.

[Kommander78]

After updating to new version (12.4.1) I can now use short server names (e.g. http://server/joplin) but not fully qualified names (e.g. http://server.net.work/joplin).

[Fruzzle]

The most recent version of the iOS app (v12.5.3) now seems to connect and work properly for WebDAV endpoints, as long as they are HTTPS. The last version that worked with HTTP appears to be v12.2.1.
Given recent iOS security tightening, it may not be feasible to use insecure HTTP URLs going forward, with the possible exception of local non-fully-qualified hostnames, as mentioned by @Kommander78 above. Given this, I believe this issue can now be closed.

[adenoz]

I agree with @Fruzzle . I was previously not able to connect or sync my iOS version of Joplin at all. I tried all variations of names and webdav and nextcloud etc. Today, I finally got Let's Encrypt certificates on all my services, including Nextcloud, and when I then attempted to sync to Joplin, it worked right away.
The only thing I could suggest for the iOS app, is a checkbox to ignore TLS errors like there is in the desktop versions. I'm not sure if this is possible in iOS. If not, this seems a hard iOS limitation rather than the Joplin app limitation.

[sylvertom]

I'm using the v12.5.3 of the iOS app too and I still have the same issue.

The server is a Synology NAS (DSM 7) with a DNS name and a valid Letsencrypt certificate.

[banigithub-2]

So I have an iPad pro running ios 15.0.2, with Joplin app 12.5.3 successfully syncing with a docker Joplin server at version 2.4.8, using a Joplin server URL http://(hostname):22300.
I've not got any certificates or proxy making TLS work.
Is that surprising?

[LaurentFough]

So I have an iPad pro running ios 15.0.2, with Joplin app 12.5.3 successfully syncing with a docker Joplin server at version 2.4.8, using a Joplin server URL http://(hostname):22300.

I've not got any certificates or proxy making TLS work.

(Almost )Exactly the same setup.

• my joplin-server endpoint is:

http://joplin.DOCKER_HOST.LOCAL_DOMAIN:22300
-—-

Error: "Network request failed"
-—-

Though: this iPad(iPad Pro) doesn't sync, while an iPad6 does.

The only real difference appears to be that on the iPad Pro, Joplin isn't listed (as a requester app) in: 'Settings → Privacy → Local Network'

Notes:

• I've tried several versions of the joplin-server: 2.4.8,... 2.5.1 ... latest

• Resetting Location & Privacy Settings, doesn't help.

• Uninstalling and reinstalling Joplin, prior to the step above doesn't work either... Joplin simply does not request "Local Network Access".

• I can access the joplin-server Web-UI, from the iPadPro, in multiple browsers (access= successfully visit & login with same credentials)

• I've checked and confirmed the credentials

• I've also checked the ability of the iPadOS itself to see/communicate with the joplin-server (ping, curl, etc) via blink-shell or other local terminals and they can all ping: IP & Hostname the joplin-server.
  -—-

curl'ing joplin-server from within blink-shell:

$ curl -v -X POST -H "X-API-MIN-VERSION: 2.1.4" -H "Content-Type: application/json" -H "Content-Length: 51" --data '{"email":"USER_EMAIL","password":"PASSWORD"}' http://joplin.HOST.domain:22300/api/sessions

*   Trying <IP>... (note: correct reverse IP of joplin-server)
* TCP_NODELAY set
* Connected to joplin.HOST.domain (IP) port 22300 (#0)
> POST /api/sessions HTTP/1.1
> Host: joplin.HOST.domain:22300
> User-Agent: curl/7.54.0
> Accept: */*
> X-API-MIN-VERSION: 2.1.4
> Content-Type: application/json
> Content-Length: 51
> 
* upload completely sent off: 51 out of 51 bytes
< HTTP/1.1 200 OK
< Vary: Origin
< Content-Security-Policy: frame-ancestors 'none'
< X-Frame-Options: DENY
< Content-Type: application/json; charset=utf-8
< Content-Length: 86
< Date: Fri, 19 Nov 2021 06:10:21 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host joplin.HOST.domain left intact
{"id":"_REDACTED_","user_id":"_REDACTED_"}

---

iPad/ Joplin that syncs successfully: Settings -> Joplin

iPad/ Joplin that does not sync: Settings -> Joplin

[banigithub-2]

Ooh - mine did that for a while, but has now requested access and worked. I don't know for sure what triggered it, but I think it is using just a hostname, unqualified, rather than a local fqdn. I don't know if you can arrange that?

[LaurentFough]

Ooh - mine did that for a while, but has now requested access and worked. I don't know for sure what triggered it, but I think it is using just a hostname, unqualified, rather than a local fqdn. I don't know if you can arrange that?

Weird.
Ok - I'd tried that before... even tried the IP of the server, as well (= no luck).

I had also tried, changing up the endpoint, and not using the "joplin." portion of the url... no luck... got the "Invalid Origin" message...

---

I just tried a couple of valid(=live) hosts on my network (not running joplin), but within the same subnet (& VLAN) that the iPadPro is on, and I was finally prompted for "Local Network" Access privileges.

Note:

• trying invalid(=non-live) hosts, just hangs the attempt to sync
• trying valid hosts on different subnets(or VLANs) does not create the "Local Network" access prompt.

I'm guessing that maybe having the joplin-server on a different VLAN could've been a part of that issue.
-—-

The real fun starts now.
So joplin has "Local Networks" privs., in iOS... but...

Edit+Update:

Still no luck syncing - pretty sure the fault's in iOS+, my VLANs... in the sense of not misconfiguration, but more how iOS networking handles request.

I may dig further in Xcode later this weekend.

[LaurentFough]

No luck.
Also did some testing with traefik (so connecting to joplin-server @ subdomain sans port).
That works on several platforms (all save iOS)

[lizhiwei8061]

遇到同样问题，域名改了ip同步测试是成功 的；但是同步数据还是报同样的错误

[gotoorder]

Same problem, is there a perfect solution now?

[sasukebinbin]

Same problem here.
Https with IP or Domain same issue.
Only Http with internal IP no issue.

[sasukebinbin]

Same problem here. Https with IP or Domain same issue. Only Http with internal IP no issue.

Just resolve the issue. The issue is because the cert was expired. Because DSM6 has a bug.
Cert config in Control panel will not take effect for Webdav.
Need to manually copy over in ssh or using script.
Details explained here
https://community.synology.com/enu/forum/17/post/96758
After updating cert for Webdav iOS works like charm.

[gotoorder]

@sasukebinbin How can I solve this problem with WebDav set up by the IIS service on Windows 11?

[sasukebinbin]

@sasukebinbin How can I solve this problem with WebDav set up by the IIS service on Windows 11?

Sorry I'm not sure about Win11. My WebDav was set up on a NAS.

[personalizedrefrigerator]

A similar (or the same) issue (sync over http) seems to be mentioned in the React Native documentation for fetch:

By default, iOS 9.0 or later enforce App Transport Secruity (ATS). ATS requires any HTTP connection to use HTTPS. If you need to fetch from a cleartext URL (one that begins with http) you will first need to add an ATS exception. If you know ahead of time what domains you will need access to, it is more secure to add exceptions only for those domains; if the domains are not known until runtime you can disable ATS completely. Note however that from January 2017, Apple's App Store review will require reasonable justification for disabling ATS. See Apple's documentation for more information.

On Android, as of API Level 28, clear text traffic is also blocked by default. This behaviour can be overridden by setting android:usesCleartextTraffic in the app manifest file.

(Emphasis added).

[etjz]

I agree with @Fruzzle . I was previously not able to connect or sync my iOS version of Joplin at all. I tried all variations of names and webdav and nextcloud etc. Today, I finally got Let's Encrypt certificates on all my services, including Nextcloud, and when I then attempted to sync to Joplin, it worked right away. The only thing I could suggest for the iOS app, is a checkbox to ignore TLS errors like there is in the desktop versions. I'm not sure if this is possible in iOS. If not, this seems a hard iOS limitation rather than the Joplin app limitation.

iOS Joplin 13.0.7, same problem. need a checkbox to ignore TLS errors!

[Fiary-Tale]

Developers are advised to discard the app url