I will look at offering this as an option in a future update.
The above Working Copy scenario is working as beorg is communicating with localhost (even in my example as the 192.168.1.102 is the IP address of the iPhone itself). Currently http with anything other than localhost doesn't work. In order to make that happen ATS (App Transport Security) has to be turned off for the entire app. I'm in two minds whether that is worth it, but happy to take for and against opinions. Apple however can question why an app is being submitted with ATS turned off on a blanket basis. In the case of WebDAV you are transmitting user credentials and potentially sensitive information (in your org files) - and doing so over an insecure connection isn't advised.
I'm not sure why it using using installed profiles to be honest, however I'm going to look at providing a setting to allow for self-signed certificates as that is probably the quickest route to resolving this issue for most people.
Allowing http-schemed webdav links (by disabling App Transport Security) would be really cool for users of Working Copy too, as the app has its own built-in webdav server that beorg could sync from... but only from http://localhost, no ssl.
I'd love to get my org files that live in git to be on my phone that way - I use working copy for all sorts of other documents, too, after all (:
I see that you added support for untrusted certificates in 3.6.1. Thanks for that!
I also wanted to follow-up and let you know that there was also an issue with my self-signed certificates that I only discovered after trying to dig back into this problem after trying to get 3.6.1 working. It appears that with iOS 13 and macOS 10.15 (Catalina) that Apple introduced new requirements for "trusted certificates", including a max validity period of 825 days or fewer, are now required to have "Subject Alternative Name (SAN)" and not just "Common Name" and must have "Extended Key Usage" (EKU) set for serverAuth. My original certificates did not comply with some of these requirements and thus I think that is where my issues actually stemmed from (because I had a Configuration Profile with my custom CA certificate).
https://support.apple.com/en-us/HT210176
Generating a new compliant Root certificate and adding it to my Configuration Profiles and generating and signing new a new cert for my Nextcloud server solved the problem and I'm now able to use Beorg with my Nextcloud with SSL (and without having to use the new "untrusted" setting)!.
I'm not sure if using self-signed certificates generated without Apples new requirements would work without trying to setup a Configuration Profile (which is explicitly for "trusting") would work with the new "untrusted" setting but if you get more reports about issues with self-signed SSL certs it may be worth looking into.
Hopefully this helps somebody else.
Thanks for adding this, I'm sure this will be helpful to others.
You can use http WebDAV links already. I've just tried using beorg with Working Copy and it's built-in web server and got it working.
The trick is to configure beorg correctly. In my case I created a new repository in Working Copy called testorg. I then configured beorg as follows:
+ Sync method - WebDAV
+ Org directory - /testorg
+ WebDAV URL - http://192.168.1.102:8080/
+ Username - webdav
The important thing here is not to include the repository name in the WebDAV URL - but instead set as the Org directory - and not to include the WebDAV username in the URL itself.
I'll be interested to hear if this works for you. If it does then I'll add a learning article to the beorg website so that others can take advantage of this setup (at least on an iPad!)
Agh, I made one crucial mistake in setting this up: I didn't put the name of the repository on the "Org directory" setting. In my setup, after finally setting that correct directory, it was not necessary to drop the username from the URL.
Here's a screenshot from my iPhone's working setup (I turned off "remote server" in working copy, hoping to not allow random strangers on the local network to access these, hence the @localhost):
Thanks for this & yes, I am sure a lot of people would appreciate a knowledge base article about this!
(I guess the other really cool thing would be a pre-sync script that ensures the working copy webdav server is running, via some url scheme hack?)
I just tried mine again with a plain WebDAV server and beorg still fails with "... App Transport Security policy requires the use of a secure connection."
Yes, I just got that too: Turns out you have to use the IP address in the webdav URL instead of "localhost": `http://webdav@127.0.0.1:8080/` does it for me
Agreed - I would never want to transmit those credentials over any kind of cable (:
What I think would be extremely helpful (if working copy has that kind of support via url handlers), I think, would be a way to set up webdav with WC's webdav server automatically; pretty much all the steps (except entering the repo name) involve copying data back and forth, and editing some text (so the "localhost" turns into "127.0.0.1").
+1 to the request for self-signed support. I host Nextcloud locally with no direct access to the internet and remote access only over a WireGuard VPN.
I use self-signed certs and have profiles setup on my iOS devices with my own CA so that my signed certificates are trusted.
I use non-routable IPs, a custom TLD, and no firewall exceptions or port-forwarding to make sure my data is only available over VPN or the local LAN.
Beorg has access to the Nextcloud server over Webdav when connected to the LAN or the VPN but the restriction on self-signed certificates appears to limit my access. Is there a reason that Beorg isn't relying on installed Profiles for certificate validation?
kevin@colyar.net
It would be nice to have an option on the WebDAV configuration to allow plain http or non-verified/self-signed cert. I'd like to setup an internal webdav server that would be accessed remotely via vpn. I can't use letsencrypt because it wouldn't be publicly accessible.
1 person likes this idea