My phone recently rebooted itself and afterwards my accounts were gone, including my DavDroid-Sync (probably not a DavDroid problem though). So I tried to reattach it to the OwnCloud installation I was using before - in the meantime I received an update to version 0.6.11, so the error might be related to that update.
What I did: entered correct server info, user name and password.
What happened: “401 Unauthorized”, no log entry on the server (neither in access.log nor in owncloud log) so apparently no connection attempt happened.
Things I tried: changing the folder, using HTTP, installing the server’s root cert. Nothing helped.
Thanks for your report. Please read Reporting issues and provide all information mentioned there, including detailled steps to reproduce the issue, client and server software details, and verbose logs.
Any news on this?
Good evening. I’m quite busy with work and stuff, sorry for not getting any more specific yet.
I have updated to 0.6.12, uninstalled, reinstalled and the error still happens. The server is OwnCloud 7.0.4 on a Debian root server. WebDAV and CalDAV work using other apps.
Reproducibility: as I already said, when I try to add a DAVDroid account (at least with this server) I always get “401 Unauthorized”.
Sorry again, but your “how to view the logs” link leads to an empty page.
My DAVDroid is installed from F-Droid, I am using a Samsung Galaxy S running Cyanogenmod 10.1.3, Android 4.2.2.
Sorry, some vandalizing user has deleted the page (we had it open for everyone to edit since we hoped that users would adapt and improve the tutorial, but it seems that’s not the case ^^). The user has been reported and the page has been recovered.
If you can post the logs when the error occurs we’ll be happy to look at it. If it contains privacy information please refrain from posting it here but send it to play@bitfire.at. Thank you!
I’ve done some log-reading… and found the problem: the server hosts not only OwnCloud (which I’m trying to use), but also another groupware application. I’m entering the URL https://mydomain.org/owncloud, but according to the logs DAVDroid simply ignores that and goes to mydomain.org/.well-known, which redirects to the other application, where I don’t have an account, ergo Error 401.
The logs don’t show what URL I entered, they just look like I entered the wrong password, so I’ll spare you a few hundred lines of HTTP, unless you really want to read them.
So, the probable steps to reproduce: install a DAV server in a subdirectory of a web server, put a .well-known into the root directory that redirects to a different DAV server somewhere else, try to login to the first DAV server with DAVDroid.
This is intended behavior. The reason for having well-known paths is that you don’t have to enter the path yourself. so I guess this is not an issue but server misconfiguration? If you don’t want .well-known, why do you have it?
The server owner wants .well-known to point to the other app because he prefers it. I didn’t want to migrate because I like OwnCloud… wouldn’t it be more intuitive to only use .well-known when no path was provided, or maybe add a checkbox to enable/disable it so the app can work even in special scenarios such as this one?
It seems that DavDroid currently issues a .well-known request to the server, and only falls back to the user-given URL. I think it should be the other way around.
Currently:
1.) well-known request to server – if that fails, use user-given URL
2.) PROPFIND requesting current-user-principal to found URL
Proposed to fix this issue:
1.) PROPFIND requesting current-user-principal to user-given URL
2.) If that fails, well-known request to server, then issue PROPFIND against the found URL
This is slower but allows the user to deal with “wrong” well-known setups.
#528 could be fixed “on-the-go” by prepending a check if the user-given URL is a collection.
Unfortunately, I had to revert this commit.
It can’t be solved by just switching the order of the detection because getCurrentUserPrincipal needs to be able to choose an URL that doesn’t provide the current-user-principal property as user-given principal as a last fallback (required for servers which don’t provide current-user-principal like Synology).
Implementing this will take much more work and will be done with PR #558.
