Sorry, but you are wrong at least for my Installation. The last step 
you described didn't fail. I can always store the password with the 
password manager. The bug occurs always and only when restarting TB.

Kind regars
Torsten

Hi Jan,

and why did this bug start to occur after updating Horde? With the old 
Horde version everything was fine...

Kind regards
Torsten

It most definitely is that bug I already posted.
I saw that exact behaviour at one of my customers installations.

BTW Sogo doesn't even use the password manager to store it's 
connection passwords. BUT: Sogo does use existing authenticated SSL 
connections to a DAV Server it needs to connect to.

Please try the following:

- delete all http or https entries for your horde server form TB 
password manager.
- restart TB. enter your credentials and DON'T store them in password 
manager. all calendars and address books (for that user) should start 
to work.

- now restart TB. enter your credentials and store them with password manager
- it will instantly fail.

"TB randomly askes for the passwords" pretty much sounds like a bug in TB.

Hi all,

I don't think that the behavior described for TB (31.2.0) and Horde is 
caused by  the above TB bug. I have the same problem described already 
in the ticket since I updated Horde to 5.2.3. Before the update I can 
access two Horde calendars and two Horde addressbooks (SoGo connector) 
from TB. The passwords had been stored with the password manager in TB 
(mutliream=true).

After the update of Horde, TB randomly askes for the passwords 
(sometimes for just one calendar, sometimes for a calendar and a 
addressbook, etc.), even they are stored in the TB password  manager. 
Before the password dialog opens in TB, there is already the log 
entriy as described in the ticket before. The log with DEBUG enabled:

Nov 20 21:00:43  HORDE: [imp] [login] No password provided. [pid 2934 
on line 730 of "/usr/share/horde/imp/lib/Imap.php"]
Nov 20 21:00:43  HORDE:  1. require() 
/usr/share/horde/rpc/index.php:14#012 2. 
Horde_Rpc_Webdav->getResponse() /usr/share/horde/rpc.php:159#012 3. 
Sabre\DAV\Server->exec() /usr/share/php/Horde/Rpc/Webdav.php:67#012 4. 
Sabre\DAV\Server->invokeMethod() 
/usr/share/php/Sabre/DAV/Server.php:214#012 5. 
Sabre\DAV\Server->broadcastEvent() 
/usr/share/php/Sabre/DAV/Server.php:455#012 6. call_user_func_array() 
/usr/share/php/Sabre/DAV/Server.php:433#012 7. 
Sabre\DAV\Auth\Plugin->beforeMethod()#012 8. 
Sabre\DAV\Auth\Backend\AbstractBasic->authenticate() 
/usr/share/php/Sabre/DAV/Auth/Plugin.php:108#012 9. 
Horde_Dav_Auth->validateUserPass() 
/usr/share/php/Sabre/DAV/Auth/Backend/AbstractBasic.php:77#01210. 
Horde_Core_Auth_Application->authenticate() 
/usr/share/php/Horde/Dav/Auth.php:54#01211. 
Horde_Core_Auth_Application->authenticate() 
/usr/share/php/Horde/Core/Auth/Application.php:126#01212. 
Horde_Auth_Base->authenticate() 
/usr/share/php/Horde/Core/Auth/Application.php:129#01213. 
Horde_Core_Auth_Application->_authenticate() 
/usr/share/php/Horde/Auth/Base.php:160#01214. 
Horde_Registry->callAppMethod() 
/usr/share/php/Horde/Core/Auth/Application.php:158#01215. 
call_user_func_array() /usr/share/php/Horde/Registry.php:1201#01216. 
IMP_Application->authAuthenticate()#01217. IMP_Auth::authenticate() 
/usr/share/horde/imp/lib/Application.php:371#01218. IMP_Imap->login() 
/usr/share/horde/imp/lib/Auth.php:86#01219. IMP_Imap->__call() 
/usr/share/horde/imp/lib/Auth.php:86#01220. require() 
/usr/share/horde/rpc/index.php:14#01221. 
Horde_Rpc_Webdav->getResponse() /usr/share/horde/rpc.php:159#01222. 
Sabre\DAV\Server->exec() /usr/share/php/Horde/Rpc/Webdav.php:67#01223. 
Sabre\DAV\Server->invokeMethod() 
/usr/share/php/Sabre/DAV/Server.php:214#01224. 
Sabre\DAV\Server->broadcastEvent() 
/usr/share/php/Sabre/DAV/Server.php:455#01225. call_user_func_array() 
/usr/share/php/Sabre/DAV/Server.php:433#01226. 
Sabre\DAV\Auth\Plugin->beforeMethod()#01227. 
Sabre\DAV\Auth\Backend\AbstractBasic->authenticate() 
/usr/share/php/Sabre/DAV/Auth/Plugin.php:108#01228. 
Horde_Dav_Auth->validateUserPass() 
/usr/share/php/Sabre/DAV/Auth/Backend/AbstractBasic.php:77#01229. 
Horde_Core_Auth_Application->authenticate() 
/usr/share/php/Horde/Dav/Auth.php:54#01230. 
Horde_Core_Auth_Application->authenticate() 
/usr/share/php/Horde/Core/Auth/Application.php:126#01231. 
Horde_Auth_Base->authenticate() 
/usr/share/php/Horde/Core/Auth/Application.php:129#01232. 
Horde_Core_Auth_Application->_authenticate() 
/usr/share/php/Horde/Auth/Base.php:160#01233. 
Horde_Registry->callAppMethod() 
/usr/share/php/Horde/Core/Auth/Application.php:158#01234. 
call_user_func_array() /usr/share/php/Horde/Registry.php:1201#01235. 
IMP_Application->authAuthenticate()#01236. IMP_Auth::authenticate() 
/usr/share/horde/imp/lib/Application.php:371#01237. IMP_Imap->login() 
/usr/share/horde/imp/lib/Auth.php:86#01238. IMP_Imap->__call() 
/usr/share/horde/imp/lib/Auth.php:86#01239. call_user_func_array() 
/usr/share/horde/imp/lib/Imap.php:718#01240. 
Horde_Imap_Client_Base->login()#01241. 
Horde_Imap_Client_Socket->_login() 
/usr/share/php/Horde/Imap/Client/Base.php:794
Nov 20 21:00:43  HORDE: [imp] FAILED LOGIN for XXXX (192.168.8.254) to 
{imap://192.168.6.231/} [pid 2934 on line 157 of 
"/usr/share/horde/imp/lib/Auth.php"]

Can I do more debugging to see what user and password is given to 
Horde? Can I do anything else to help find the bug?

Kind regards
Torsten

About iCal4OL - for hn (at) axxedia-it (dot.) de:

Actually, it's the flag "newconn" (new connection) which helped with 
previous version of Horde. It's working now correctly without this 
flag for Horde 5.2.3
(This bug was fixed, at least from the perspective of iCal4OL.)

Regarding the Thunderbird/Lightning issue:

I think this bug https://bugzilla.mozilla.org/show_bug.cgi?id=799184#c15
describes it perfectly. It seems to be a known problem with the password
manager. Definitely not a bug in Horde.

I did some tests with Thunderbird 31.2.0 and Lightning 3.3.1.
I used four calendars in this test setup, one of them is read/write 
and the rest is read only. The read only calendars are shared by other 
users. I added the calendars one by one, to see if I can sync them 
against Horde 5.2.3.
In my first attempt I did not save the login credentials with the 
password manager from Thunderbird. All calendars worked fine, even 
after a restart of Thunderbird, I could still add new entries and they 
where synched just fine. Of course I had to enter the login 
credentials each time I did a restart of Thunderbird.

Then I tried to use the built in password manager to save the login 
credentials, and that's where the trouble started. I can no longer 
sync the calendars, even after a restart of TB they instantly fail. So 
it seems to be a problem between Lightning and Thunderbird.

If anyone can confirm this?

I get this error from imp when I use the password panager:

Nov 18 12:33:12 mail HORDE: [imp] [getNamespaces] No password 
provided. [pid 27445 on line 730 of "/var/www/webmail/imp/lib/Imap.php"]

I upgraded all packages on two of my customers installations to check 
whether iCAL4OL fails or succeeds against Horde 5.2.3.

I first created a clean configuration ini file for iCAL4OL to rule out 
any changes I might have done over time. iCAL4OL then auto detected 
the calendars from one user and wrote the settings to the ini file. No 
trouble so far, but I think iCAL4OL also detected that I want so sync 
against Horde and automatically added a "horde" tag to it's 
configuration to counter the session/login error.
I manually removed that tag to see if a sync would succeed and as far 
as I can tell it did that without complaining. All calendar entries 
are in sync. I tried it both ways and then with multiple calendars and 
it still works.

I would like to have Roland check it against the Horde demo server to 
see if my observations are true.

Regarding the Lightning/TB failure: I do have a customer who started 
to use CalDAV sync with Lightning last week. Synching only one 
calendar seems to work fine, but using more than one calendar seems to 
break things. It won't sync at all after a restart of TB, giving me a 
CALDAV_ERROR and a can't read data message. I don't think that this is 
related to the session/Login bug, but I can try to investigate.

Does this still happen with the latest version of all packages? There 
had been a related fix with sessions and RPC access recently.

I can confirm this bug with Thunderbird connecting to Turba and 
Lightning connecting to Kronolith Calendars using IMP authentication.

mail horde: [imp] [login] No password provided. [pid 47775 on line 730 
of "/usr/local/www/horde/imp/lib/Imap.php"]

How can I help debugging?

Attached a libcurl debug file, where you can see this issue..

I don'ts follow this topic.. and just did one click too early.

The TCP "Ground" Connection is established (libcurl), and of course 
every request has the correct Authentication Header (Basic Realm). 
Also the cookies between requests are treated automatically and 
correctly (same with WinHttp.dll and WinInet.dll).

It's a Kronolith <-> SabreDAV bug, where a second request always fails.
A next HTTP request is only possible, if the TCP connection is closed 
and a new one created (a new handshake for SSL needed).

This issue is also with the demo.horde.org

I don't know the internas of Horde about sessions.
I just can't understand, why Michael is writing about "transparent 
auth" and why "IMP" is mentioned?! Gibberish..

Horde is the only web solution with this special issue. There must be 
something wrong. Smartphones probably use always new connections, but 
e.g. the autodiscover of CalDAV server collections may fail.

So the observed behaviour is by design?
It wasn't before in 5.1.x, thats why I am surprised that iCAL4OL was 
not working with the update to version 5.2.1.

But I'm not the right Person to discuss this error with. Roland 
Scherrer, the author of iCAL4OL can give you more details.

I'm not sure what you mean with new connection vs. re-using the 
previous connection.
If you talk about Horde sessions identified with cookies, then this 
client is plain wrong. There are no sessions in WebDAV, clients *must* 
authenticate with each request, as long as authentication is required. 
And *if* they use sessions, then they need to at least implement them 
correctly by updating session cookies that are sent back from the 
server.

What I posted is exactly correct.  The log error that you provided is 
irrelevant and has been silenced in the latest code (IMP 6.2.2).

I'm not commenting on the "2 sessions issue" - just that the log error 
referring to "empty password" doesn't provide any useful information.

@slusarz - You perhaps misunderstood...

Reusing an existing https connection for CalDAV, doing a second https 
request with providing correct BASIC AUTH also this  time, does not 
work anymore in 5.2.1. This is a severe bug.

In the SabreDAV backend a wrong error message will generated (even 
with correct BASIC AUTH header):

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
   <s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
   <s:message>Username or password does not match</s:message>
   <s:sabredav-version>1.8.10</s:sabredav-version>
</d:error>

Roland

FWIW, this error can be disregarded, since it doesn't affect the login 
process.  It was silenced as of this commit:

commit 1c63a64d694c57e65f7b5e263c837a04bd12d9fe
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Fri Jul 11 14:25:44 2014 -0600

     Don't attempt transparent authentication if we don't have a 
backend password

I have a customer using Horde with iCAL4OL to sync calendars and 
contacts between users. After upgrading to 5.2.1 from 5.1.6 they 
cannot use iCAL4OL anymore, because there seems to be a problem with 
the authentication. iCAL4OL starts a CalDAV sync with the given 
credentials, then it gets disconnected and cannot authenticate again, 
because it tries to use the previous session which is not available 
any longer.

I did have a quick check with the developer of iCAL4OL who found out, 
that if iCAL4OL sends the login credentials each time the server asks 
for them (new connection / new ssl-handshake) it works fine. This 
behavior can also be seen on the demo server you provide, so it is not 
a configuration problem on my customers server.

In the syslog a failed connection attempt then looks like this:
HORDE: [imp] Login success for tb (zensiert) to {imap://localhost/} 
[pid 9310 on line 157 of "/var/www/webmail/imp/lib/Auth.p$
Aug 18 11:21:31 khs-server HORDE: [imp] [login] No password provided. 
[pid 9310 on line 732 of "/var/www/webmail/imp/lib/Imap.php"]
Aug 18 11:21:31 khs-server HORDE: [imp] [login] No password provided. 
[pid 9855 on line 732 of "/var/www/webmail/imp/lib/Imap.php"]

In 5.1.6 it was possible to reuse the existing connection thus it was 
not necessary to send the login credentials each time. We suspect a 
configuration error somewhere in the SabreDAV settings in Horde.

I also did a quick check with CalDAV Sync for android, and it looks 
like this app does handle the login problem by itself, because I can 
see it doing multiple logins / new connections during one 
synchronisation attempt.