search

laurent22 / joplin

Joplin - the secure note taking and to-do app with synchronisation capabilities for Windows, macOS, Linux, Android and iOS.
https://joplinapp.org
Other
44.1k stars 4.77k forks source link

iOS app does not work with WebDAV plain HTTP #5321

Open Kommander78 opened 2 years ago

Kommander78 commented 2 years ago

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 commented 2 years ago

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

Also did you perform the sync target upgrade?

Kommander78 commented 2 years ago

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 commented 2 years ago

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

Kommander78 commented 2 years ago

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

Kommander78 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

laurent22 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

hevjay commented 2 years ago

Same here.

banigithub-2 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

IMG_2771

Fruzzle commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Fruzzle commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

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:

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

iPad/ Joplin that syncs successfully: Settings -> Joplin image

-

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

banigithub-2 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 1 year ago

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

gotoorder commented 6 months ago

Same problem, is there a perfect solution now?

sasukebinbin commented 6 months ago

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

sasukebinbin commented 6 months ago

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 commented 6 months ago

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

sasukebinbin commented 6 months ago

@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 commented 6 months ago

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).