I have been using DAV with my Android phone with DAVx5 for quite a while now.
Everything worked fine until I updated to 2.18.0 today.
Since then I get authentication errors.
The user account and password are correct, I double checked...
Neither synching with an existing account that worked with 2.17 nor creating a new account work with 2.18
access.log:
192.168.1.66 - @ [02/Jun/2020:11:50:46 +0200] "PROPFIND /dav/ HTTP/1.1" 401 1925 "-" "DAVx5/2.6.6-ose (2020/04/15; dav4jvm; okhttp/3.12.10) Android/10"
192.168.1.66 - @ [02/Jun/2020:11:50:56 +0200] "PROPFIND /dav/addressbooks/@/contacts/ HTTP/1.1" 401 3955 "-" "DAVx5/2.6.6-ose (2020/04/15; dav4jvm; okhttp/3.12.10) Android/10"
192.168.1.66 - @ [02/Jun/2020:11:50:56 +0200] "PROPFIND /dav/calendars/@/birthdays/ HTTP/1.1" 401 3955 "-" "DAVx5/2.6.6-ose (2020/04/15; dav4jvm; okhttp/3.12.10) Android/10"
client log:*
2020-06-02 11:46:00 2392 [ui.setup.DavResourceFinder] Finding initial carddav service configuration
2020-06-02 11:46:00 2392 [ui.setup.DavResourceFinder] Checking user-given URL: https://...:81/dav
2020-06-02 11:46:00 2392 [HttpClient] --> PROPFIND https://...:81/dav
2020-06-02 11:46:00 2392 [HttpClient] Content-Type: application/xml; charset=utf-8
2020-06-02 11:46:00 2392 [HttpClient] Content-Length: 290
2020-06-02 11:46:00 2392 [HttpClient] Depth: 0
2020-06-02 11:46:00 2392 [HttpClient]
2020-06-02 11:46:00 2392 [HttpClient]
2020-06-02 11:46:00 2392 [HttpClient] --> END PROPFIND (290-byte body)
2020-06-02 11:46:00 2392 [HttpClient] <-- 401 Unauthorized https://...:81/dav (405ms)
2020-06-02 11:46:00 2392 [HttpClient] Date: Tue, 02 Jun 2020 09:45:59 GMT
2020-06-02 11:46:00 2392 [HttpClient] Server: Apache/2.4.41 (Ubuntu)
2020-06-02 11:46:00 2392 [HttpClient] Vary: Authorization
2020-06-02 11:46:00 2392 [HttpClient] www-authenticate: Basic
2020-06-02 11:46:00 2392 [HttpClient] Cache-Control: no-cache, private
2020-06-02 11:46:00 2392 [HttpClient] X-RateLimit-Limit: 60
2020-06-02 11:46:00 2392 [HttpClient] X-RateLimit-Remaining: 59
2020-06-02 11:46:00 2392 [HttpClient] Content-Length: 1558
2020-06-02 11:46:00 2392 [HttpClient] Keep-Alive: timeout=5, max=100
2020-06-02 11:46:00 2392 [HttpClient] Connection: Keep-Alive
2020-06-02 11:46:00 2392 [HttpClient] Content-Type: text/html; charset=UTF-8
Hello, thanks for your feedback.
There is indeed a change in 2.18.0, and it was not fully documented in the release note.
I've added this paragraph in the release note:
DAV Connection
CardDAV or CalDAV client connection now requires an API token as the password. Using login+password directly will not work anymore.
Go to/settings/apito generate a new token and use it as the password.See also this documentation about CardDAV client.
Related to #3830
Works again. Thanks a lot!
I seem to still be having an issue like this one. The dav endpoint returns a 401 when any of my carddav clients try and connect to it. I'm using an API Key, and am using the v2.18.0-alpine-apache image, but I can't seem to validate with the endpoint with any clients. there's no errors from the logs in the container and nothing in the audit log from what I've seen:
~~.~.~.~~ - ~~~~@~~~.~~~ [09/Jul/2020:17:18:12 +0000] "PROPFIND /dav/addressbooks/~~~~@~~~.~~~/contacts HTTP/1.1" 401 1558 "https://monica.~~~~.~~~/dav" "Thunderbird CardBook/44.6 Lightning/68.10.0"
~~.~.~.~~ - - [09/Jul/2020:17:18:13 +0000] "PROPFIND /dav/addressbooks/~~~~~~~@~~~.~~~/contacts/.well-known/carddav HTTP/1.1" 301 318 "https://monica.~~~~.~~~/dav" "Thunderbird CardBook/44.6 Lightning/68.10.0"
~~.~.~.~~ - ~~~~@~~~.~~~ [09/Jul/2020:17:18:14 +0000] "PROPFIND /dav/addressbooks/~~~~@~~~.~~~ HTTP/1.1" 401 1558 "https://monica.~~~~.~~~/dav" "Thunderbird CardBook/44.6 Lightning/68.10.0"
(hid some sensitive info with ~)
and from Thunderbird itself I get a "Validation Failed"
Does anything look strange?
Nevermind, after troubleshooting some more, I didn't realize the email was case-sensitive. Although that brought up a different kind of issue: if you want to change the case of the email only then Monica throws an error that the email is already taken.
I'm guessing the authentication library and the script that checks for a user existing aren't following the same rules regarding case.
Thanks for the feedback @LuminousPath
About the case sensitive problem, would you create another issue?