Fixed in HEAD and for Horde 3.0.5.

Alright, so, this was the wrong fix:

http://bugs.horde.org/ticket/?id=1302



That's probably why you were seeing immediate timeouts. I'll get this 
sorted out for Horde 3.0.5.

I read the URL that accompanied the timeout option, and what it 
appears to say is that it should be the time in seconds that the 
cookie should live, not the current time plus the number of seconds 
the cookie should live.  The entry quoted below seems to state this 
rather plainly (if this comment is incorrect, then the documentation 
should reflect this, or a note should be made for the timout option):



The first argument to session_set_cookie_params is the number of 
seconds in the future (based on the server's current time) that the 
session will expire.  So if you want your sessions to last 100 days:



$expireTime = 60*60*24*100; // 100 days

session_set_cookie_params($expireTime);



I was using time()+$expireTime, which is WRONG (a lot of the 
session_set_cookie_params() examples I found get this wrong, but 
probably don't care because they are just doing "infinite" sessions).

time() + 3300 is exactly the correct solution as explained at the link 
provided with the configuration item.

There seems to be an issue with the session timeout defined in 
horde/config/conf.php.  We wanted the horde session to time out before 
our load balancer so the user would get any meaningful messages before 
the load balancer cut the connection.  In order to make this

happen, we set the following timeout:



$conf['session']['timeout'] = 3300;



This resulted in sessions expiring immediately, so there was a looping 
problem when we tried to use hordeauth for imp since the credentials 
were always different.



Setting the timout back to the default of 0 fixed the problem.   
Setting it to time() + 3300 also appeared to work, but is very 
inellegant.