I always get a 401 error in configuring the DAVCal resource (when I click on "fetch"). I cannot click OK to continue. After inspecting the logs, it seems like the DAVCal resource is never sending the password in the header when it attempts to do a "PROPFIND" on the URL. Since I am already giving you the username and password, then it should be sent in the header always correct? Or at least when it sees a permission denied, another request should be sent automatically with the supplied username and password. Note I am using DAVMail as the server, and the same server with the same settings works fine for Lightning in Thunderbird, and various other Caldav clients. Reproducible: Always Steps to Reproduce: Here are my steps in korganizer: 1) Settings -> Configure KOrganizer 2) General -> Calendars -> Add ... 3) Dav groupware resource 4) billg@hotmail.com / password (it's an o365 account) 5) Next -> Configure the Resource Manually -> Next 6) Display name: AcmeExample 7) Leave everything else filled in as is. 8) Click on Add 9) Select CalDAV 10) Remote URL: http://127.0.0.1:1080/users/billg@hotmail.com/calendar Actual Results: I receive a dialog box which states: There was a problem with the request. (401). Expected Results: Populated discovered collections box. I am using DAVMail running on port 1080 which is translating caldav, imap, cardav, etc speak into exchange speak. I have attached (or will once it's filed) the wireshark logs of the communication, and a plain text debug logs from the server communicating with the client. I have noted this as Grave, because I cannot use akonadi's "DAV Resource" at all until you send the username/password in the headers.
Created attachment 91434 [details] From the davmail server running on localhost, client/server sniff/debug
Created attachment 91435 [details] From wireshark sniffing on loopback port 1080
Hey, Actually KIO does a first round-trip without the username / password, as is recommended and unless a previous authentication with this web site succeeded. Do you mean that the username / password are never added or they're not present in the first request? Cheers, Grégory
I'm seeing the same behaviour here: we use owncloud to share calendars and it seems that ALL requests are made without username/password. Since the connection is encrypted (https) it is a bit difficult to send a wireshark dump, but I clearly see on the apache side that all PROPFIND requests are made without credentials: I only see 401 requests. Simulating the same request via curl, but providing the credential, it works.
For the record, I'm using archlinux, akonadi version is 15.08.0-2. A previous (before last update, can't remember exact number) version worked without this issue.
I'm pretty certain that the resource still sends the passwords :) Does your password contain non-ASCII characters? There's a problem in KIO with HTTP authentication in this scenario.
Broken for me too. I have a password consisting only of ASCII letters and digits. Akonadi always sends the first PROPFIND request without authorization headers, as gets logged by Apache. this is the version: akonadi (1.12.1-0ubuntu1.1) trusty
(In reply to Olaf Titz from comment #7) > Akonadi always sends the first PROPFIND request without authorization > headers, as gets logged by Apache. OK, but this is how it's supposed to work: first request is made without the Authorization header to ensure that authentication is needed, but the second one should have it. Is that not the case?
There is a recurring issue in support fora related to owncloud and iOS/Android CalDAV sync apps. I still don't understand it completely, but it seems to be related to two or three potential reasons. All of them have to do with the fact that PROPFIND is treated differently from GET (at least by Apache). 1. Sure: a number of misconfigurations of Apache can cause Apache and/or Owncloud to misunderstand the initial PROPFIND request. There is plenty of documentation about that. (Everything here applies not to owncloud exclusively but to all Apache/PHP-based DAV services.) 2. Confirmed: When the requested resource is not known (wrong URL), Apache responds 405 instead of 404 to PROPFIND, so the end user gets a misleading technical error message instead of a plain "URL not found". 3. Speculative: it looks like Apache responds 405 instead of 401 too in certain circumstances, but I'm not exactly sure what causes this. This is what really can cause breakage to the authorization protocol. The DAVdroid app has an option to always send an Authorization header with the first request to work around these kind of problems (at least the #3 one) and the recommendation could be that Akonadi get such an option too. (Now I don't have the problem any more since I fixed my setup on all three sides (owncloud, android, akonadi) but getting it right everywhere was much harder than it should be...)
Good news I guess :) Do you have the link to the thread that mention this problem?
I have exactly the same issue using nginx, but I recall it used to work few months ago. And it works with my Android phone with DAVdroid. I am running Akonadi 15.12.3 on Arch Linux. I enclose log from nginx and journal.
Created attachment 98277 [details] nginx access.log
Created attachment 98278 [details] journal log
Is this big https://github.com/nextcloud/server/issues/5326 related? I opened the bug report at nextcloud, but they refer to KDE. The message I get in logfiles is: No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured in logfile
Are there any updates on this? I'm having the same issue with my nextcloud server. Accessing the ressource via dolphin works. The caldav ressource works but not the carddav ressulting in the error below: {webdav} {"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","Code":0,"Trace":[{"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->","args":[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/99999\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php","line":105,"function":"call_user_func_array","args":[[{"autoRequireLogin":true,"__class__":"Sabre\\DAV\\Auth\\Plugin"},"beforeMethod"],[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/99999\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":466,"function":"emit","class":"Sabre\\Event\\EventEmitter","type":"->","args":["beforeMethod",[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/99999\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":254,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[{"absoluteUrl":"https:\/\/cloud.thaodan.de\/remote.php\/dav\/addressbooks\/users\/99999\/kontakte\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/usr\/share\/webapps\/nextcloud\/apps\/dav\/lib\/Server.php","line":316,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"\/usr\/share\/webapps\/nextcloud\/apps\/dav\/appinfo\/v2\/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"\/usr\/share\/webapps\/nextcloud\/remote.php","line":163,"args":["\/usr\/share\/webapps\/nextcloud\/apps\/dav\/appinfo\/v2\/remote.php"],"function":"require_once"}],"File":"\/usr\/share\/webapps\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php","Line":168,"CustomMessage":"--"}
> I'm having the same issue with my nextcloud server. I tried adding a dav resource pointing to demo.owncloud.com a couple days ago without seeing any issue. I could create an event and a contact without anything complaining.
also no issue on demo.nextcloud.com, I see the test event I just created on the recent activities tab
I tried the demo instance and this one works. But still some requests are send without login parameters and return 401 (as expected). Should I set nextcloud to ignore unauthiated requests or something?
Is there a way to always send auth headers?