Changes have been made in Git (master):

commit d4d1334f55c3c704e70eaabbc4669109649c7958
Author: Jan Schneider <jan@horde.org>
Date:   Fri Nov 21 18:48:57 2014 +0100

     [jan] Fix DAV client always using Digest authentication (Bug #13319).

  framework/Dav/lib/Horde/Dav/Client.php |   11 ++++++++---
  framework/Dav/package.xml              |    2 ++
  2 files changed, 10 insertions(+), 3 deletions(-)

http://github.com/horde/horde/commit/d4d1334f55c3c704e70eaabbc4669109649c7958

Confirm this problem after upgrade to kronolith-4.2.2 / Horde_Dav-1.0.7.

External SabreDav (Basic Auth) calenders are not more accessible. Error logs:
Sep 28 08:12:05 X HORDE: [kronolith] Not authenticated [pid 7969 on 
line 124 of "/usr/share/php/Horde/Dav/Client.php"]
Sep 28 08:12:05 X HORDE: [kronolith] Failed to retrieve remote 
calendar: url = "https://..."", status = 401 [pid 7969 on line 593 of 
"/var/www/ebert.pw.443/horde/kronolith/lib/Driver/Ical.php"]

Hello,

I think I've implemented a fix for http://bugs.horde.org/ticket/13319.
The main problem is that external calendars are no longer working if 
they expect HTTP Basic Auth.

The problem is that in kronolith/lib/Driver/Ical.php the variable 
$sabreOptions['userName'] is set, but this breaks the request method in
pear/php/Horde/Dav/Client.php because the authType of the SabreDAV 
client is AUTH_BASIC | AUTH_DIGEST. That leads to the DIGEST method 
being used in the Horde_Dav_Client class.

My idea is to use the HTTP 401 response from the external calendar 
provider when the user is adding the external calendar, because that's 
the place where the provider tells us which authentication mode is 
required.

In my (AFAI can tell, working) solution, this information is collected 
in Horde/Dav/Client.php and passed along using the Horde_Dav_Exception 
and the following Kronolith_Exception back to the Browser.

Then the user enters his credentials and the desired authentication 
mode is sent back to the horde server as well. There it is used to 
access the calendar provider and finally stored in the database.

I don't know why the user name is set in the sabreOptions in the first 
place (the change was introduced here 
https://github.com/horde/horde/commit/477f2c46041bde1b3bfa572d7fbac535046c3be6#diff-2a209d195528a6339e273da67af8fd86), but now something has to be done to fix this. If my approach is not completely wrong, I could provide a patch. Should I attach it to the bug tracker 
ticket?

Or are there other, better ways to get the external calendars working again?

I assume this has to do with the class Horde_Dav_Client. In Horde 
5.1.6, the $settings in the constructor do not contain the user name, 
but in H5.2, they do. This finally leads to this line

$this->_http->{'request.authenticationScheme'} = Horde_Http::AUTH_DIGEST;

in the request() function to be executed. The correct setting would be 
AUTH_BASIC (or not changing it from the default, probably 
corresponding to CURLAUTH_ANY; this happens in H5.1.6, because 
$this-userName is null).

I hope this helps to track down the real cause for this error.

I just realised that the problem is not connected to the 
google-account. It also occurs with a horde-caldav-URL of another 
external Horde-installation. There seems to be a problem in handling 
the user credentials  (username/password) when adding an external 
calendar.

Andreas

Yes, it worked, and it is still working on my production system with 
Kronolith 4.1.5 (Horde 5.1.6)

Andreas

Are you sure this worked with Kronolith 4.1? Google now requires 
OAuth2 authentication which we never supported in Kronolith.

Hello,

with upgrading Horde from 5.1.6 to 5.2RC2 and Kronolith from 4.1.5 to 
4.2.0RC2 access to external google-calendars ceased to work.
As URL for the external calendar I use:
  https://www.google.com/calendar/dav/username@googlemail.com/events
Username-entry is respectively:
username@googlemail.com
The corresponding password is given.
All these entries work fine with Horde-5.1.6/Kronolith-4.1.5, but with 
Horde5.2RC2/Kronolith-4.2.0RC2 I only get the message "The 
authentication information you specified wasn't accepted."

Thanks for any hints,
Andreas