Password lost during hordeauth authentication via API

This is very vaguely because I wasn't able to track this dow

Mon, 28 Mar 2011 14:02:01 +0000

This is very vaguely because I wasn't able to track this down yet. It's not a showstopper either, because everything still works fine. My horde log is full of: 2011-03-28T15:57:42+02:00 ERR: HEADHORDE [imp] IMAP error: Login failed: authentication failure [pid 2042 on line 212 of "/home/jan/horde-git/framework/Imap_Client/lib/Horde/Imap/Client/Base.php"] 2011-03-28T15:57:42+02:00 ERR: HEADHORDE [imp] IMAP server denied authentication. [pid 2042 on line 212 of "/home/jan/horde-git/framework/Imap_Client/lib/Horde/Imap/Client/Base.php"] 2011-03-28T15:57:42+02:00 INFO: HEADHORDE [imp] FAILED LOGIN for jan (Horde user jan) [109.250.42.72] to {localhost:143} [pid 2042 on line 200 of "/home/jan/horde-git/imp/lib/Auth.php"] Coming from ActiveSync requests. I'm using LDAP authentication in Horde and hordeauth in IMP. Transparent authentication to IMP using the web interface works flawlessly. I tracked it down as far as the password not being passed to the auth driver.

Duplicate of Bug #9718?

Mon, 28 Mar 2011 20:09:03 +0000

Duplicate of Bug #9718?

> Duplicate of Bug #9718? I'll answer my own question: No

Mon, 28 Mar 2011 20:55:45 +0000

> Duplicate of Bug #9718? I'll answer my own question: No. #9718 dealt with trying to do IMAP actions on a server that had not yet been authenticated to. This ticket is about the password not being passed around.

Bumping, because this might cause users to get locked out du

Tue, 12 Apr 2011 14:27:37 +0000

Bumping, because this might cause users to get locked out due to too many failed logins.

Are you 100% sure these are coming from AS requests? I ask b

Thu, 14 Apr 2011 04:54:32 +0000

Are you 100% sure these are coming from AS requests? I ask because you said that you are using LDAP auth. Since you are not using application/imp auth, IMP should only be polling the IMAP server when IMP is being accessed directly, right? There *should* be nothing in an ActiveSync request that attempts to access IMP, so IMP should not be attempting to authenticate to the IMAP server. The only thing I'm able to come up with is that since we set authentication => none when we initialize Horde in rpc.php, something in the Horde application initialization process (maybe checking permissions on each installed app when listing apps?) is hitting IMP.

I'm 95% sure, because this always coincides with an AS reque

Thu, 14 Apr 2011 08:00:14 +0000

I'm 95% sure, because this always coincides with an AS request. BUT it doesn't happen with *all* requests (anymore). The question is not why IMP is being called though, I'm pretty sure that this is coming from the new mail notification decorator. The question is, what happens to the password, and why is it not passed to IMP?

We always geht the same error messages when trieing to coone

Thu, 14 Apr 2011 10:28:42 +0000

We always geht the same error messages when trieing to coonect with active sync. horde with imp auth

Maybe related to the fact that there is no session created f

Thu, 14 Apr 2011 13:32:13 +0000

Maybe related to the fact that there is no session created for AS requests? A separate issue thuough is why the new mail notifications are even chcecked when calling code that would never be able to do anything with them. Seems like a waste of resources to me.

> Maybe related to the fact that there is no session created

Thu, 14 Apr 2011 17:14:27 +0000

> Maybe related to the fact that there is no session created for AS requests? This is a somewhat big issue for those of us that use imp authentication (not really the point of this bug, but going to mention anyway). Every AS request causes IMP to initialize and create its session information. An alternative would be to use imap authentication in horde and hordeauth in IMP. But this is not optimal at the moment because two separate IMAP connections will be made - one in IMAP auth and one in IMP.

> A separate issue thuough is why the new mail notifications

Thu, 14 Apr 2011 17:18:23 +0000

> A separate issue thuough is why the new mail notifications are even > chcecked when calling code that would never be able to do anything > with them. Seems like a waste of resources to me. The logic on whether to display is fully contained within the new mail notification decorator, however. Not sure how else this could work. Disabling notifications altogether for the AS request might be an option. But on the flip side, ignoring all notifications might not be a good idea either since when you push a notification on the stack in the code, you have an expectation that it will eventually be processed somehow.

>> Maybe related to the fact that there is no session create

Thu, 14 Apr 2011 17:25:02 +0000

>> Maybe related to the fact that there is no session created for AS requests? > > This is a somewhat big issue for those of us that use imp > authentication (not really the point of this bug, but going to > mention anyway). Every AS request causes IMP to initialize and > create its session information. Enabling sessions shouldn't break AS, but introduces all that overhead for something that is not required for anything related to the AS request. > > An alternative would be to use imap authentication in horde and > hordeauth in IMP. But this is not optimal at the moment because two > separate IMAP connections will be made - one in IMAP auth and one in > IMP. I guess I'm still unclear as to why IMP needs to be involved here at all if not using IMP auth. >

> I guess I'm still unclear as to why IMP needs to be invol

Thu, 14 Apr 2011 17:31:14 +0000

> I guess I'm still unclear as to why IMP needs to be involved here at > all if not using IMP auth. Because setupNotification() exists in IMP. And this needs to be called during Horde initialization. ...Although I'm not sure why we are calling setupNotification() in ALL applications vs. only applications that are currently authenticated. Jan's the one who implemented this, so he would probably be the one to best answer this question.

>> A separate issue thuough is why the new mail notification

Thu, 14 Apr 2011 17:31:38 +0000

>> A separate issue thuough is why the new mail notifications are even >> chcecked when calling code that would never be able to do anything >> with them. Seems like a waste of resources to me. > > The logic on whether to display is fully contained within the new > mail notification decorator, however. Not sure how else this could > work. But there is no display context when we are talking about non-horde client requests for rpc.php > Disabling notifications altogether for the AS request might be an > option. But on the flip side, ignoring all notifications might not > be a good idea either since when you push a notification on the stack > in the code, you have an expectation that it will eventually be > processed somehow. There is no mechanism in place to display any notifications for AS requests, or for some other rpc requests for that matter, so disabling notifications in these cases makes sense to me

> Because setupNotification() exists in IMP. And this nee

Thu, 14 Apr 2011 17:33:37 +0000

> Because setupNotification() exists in IMP. And this needs to be > called during Horde initialization. > > ...Although I'm not sure why we are calling setupNotification() in > ALL applications vs. only applications that are currently > authenticated. Exactly. That's the basic question I'm getting at here. Jan's the one who implemented this, so he would > probably be the one to best answer this question.

> There is no mechanism in place to display any notification

Thu, 14 Apr 2011 17:34:29 +0000

> There is no mechanism in place to display any notifications for AS > requests, or for some other rpc requests for that matter, so > disabling notifications in these cases makes sense to me But you are making the assumption that notifications need to be displayed. There is no such requirement. Notifications can be anything. Theoretically, we could convert Horde::logMessage() to a log notification handler. Which we WOULD want to be processed during an AS request. Anyway, I answered my own question - we can't disable notifications entirely.

That's a good point. I'll look at adding a config to use

Thu, 14 Apr 2011 17:43:48 +0000

That's a good point. I'll look at adding a config to use sessions or not with AS requests, but wouldn't this affect ANY script that uses session => none then?

> I'll look at adding a config to use sessions or not with A

Fri, 15 Apr 2011 05:45:53 +0000

> I'll look at adding a config to use sessions or not with AS requests, > but wouldn't this affect ANY script that uses session => none then? Yes... at least until the setupNotification() problem is fixed. But most scripts with session = 'none' are things like command-line scripts that will only be run once. The difference with AS is that these requests will be happening on a regular & repeating basis (e.g. my android device used to send requests every 10 seconds).

Changes have been made in Git for this ticket: Bug #9733:

Fri, 15 Apr 2011 05:49:34 +0000

Changes have been made in Git for this ticket: Bug #9733: Don't setup notification handlers in applications that are not yet authenticated 2 files changed, 8 insertions(+), 5 deletions(-) http://git.horde.org/horde-git/-/commit/dcdd9f52eabc7cd8df5b2ea661097effe039833e

> 2 files changed, 8 insertions(+), 5 deletions(-) > http:

Fri, 15 Apr 2011 14:27:28 +0000

> 2 files changed, 8 insertions(+), 5 deletions(-) > http://git.horde.org/horde-git/-/commit/dcdd9f52eabc7cd8df5b2ea661097effe039833e with this commit, I get lots of NOTICE: HORDE PHP ERROR: Undefined property: Horde_Core_Factory_Notification::$_app [pid 17422 on line 21 of "/var/www/html/hordetest/libs/Horde/Core/Factory/Notification.php"]

Changes have been made in Git for this ticket: Bug #9733: F

Fri, 15 Apr 2011 15:38:03 +0000

Changes have been made in Git for this ticket: Bug #9733: Fix copy/paste error 1 files changed, 1 insertions(+), 1 deletions(-) http://git.horde.org/horde-git/-/commit/21c42f5538f5185b6e010e6c95e294802f21c67c

> The difference with AS is that > these requests will be

Tue, 19 Apr 2011 16:00:38 +0000

> The difference with AS is that > these requests will be happening on a regular & repeating basis (e.g. > my android device used to send requests every 10 seconds) . FWIW this can be somewhat controlled via horde's AS settings. It is a tradeoff between keeping a single request open longer vs making more frequent requests.

Target this for 4.1. This is caused by the authenticatio

Wed, 20 Apr 2011 18:35:12 +0000

Target this for 4.1. This is caused by the authentication credentials being stored in the horde session, and since horde's session storage is backed by $_SESSION, this information is lost, even during the same request. In AS, this is caused by Kronolith checking for APIs such as Tasks and listTimeObjects - which causes a need for those apps to be authenticated. After discussion with other devs, this is going to be fixed by implementing a new session storage backend to be used when sessioncontrol == none, that will simply store the session values in private members so that session data set during the request will still be available during the request.

> Changes have been made in Git for this ticket: > > Bug #

Tue, 26 Apr 2011 19:50:08 +0000

> Changes have been made in Git for this ticket: > > Bug #9733: Don't setup notification handlers in applications that > are not yet authenticated > > 2 files changed, 8 insertions(+), 5 deletions(-) > http://git.horde.org/horde-git/-/commit/dcdd9f52eabc7cd8df5b2ea661097effe039833e From Ticket #9979 - reports that this breaks AJAX timeout request. So refactoring/fixing this can not wait until 4.1.

Agreed. This needs to be dealt with asap, kronolith API acce

Mon, 02 May 2011 02:31:00 +0000

Agreed. This needs to be dealt with asap, kronolith API access is also broken as a result of this. See Bug: 9837

For 4.0.x, this will have to be fixed by enabling sessions a

Mon, 02 May 2011 02:33:00 +0000

For 4.0.x, this will have to be fixed by enabling sessions again for AS (or any other RPC request that has it currently set to 'none'. For 4.1, should be fixed as described below.

Changes have been made in Git for this ticket: Bug: 9733 -

Tue, 03 May 2011 22:01:32 +0000

Changes have been made in Git for this ticket: Bug: 9733 - Don't disable sessions for ActiveSync requests. This is not the ideal fix for this, since creating a new session for each activesync request is a complete waste of resources. However, this is the only viable solution for this until Horde 4.1. 1 files changed, 2 insertions(+), 4 deletions(-) http://git.horde.org/horde-git/-/commit/a65072badbcb509690ca009bb0770ca1c641e393

Now that hotfix is in place for 4.0.x series, downgrade prio

Tue, 03 May 2011 22:03:19 +0000

Now that hotfix is in place for 4.0.x series, downgrade priority and target the proper fix for 4.1

Changes have been made in Git (develop): commit b009bbc6c3f

Sun, 26 Feb 2012 01:36:30 +0000

Changes have been made in Git (develop): commit b009bbc6c3f8ade37c64179157a385b660f25c47 Author: Michael J Rubinsky Date: Thu Feb 23 15:41:08 2012 -0500 Use local storage when no session is available. Bug: 9733 framework/Core/lib/Horde/Registry.php | 5 +- framework/Core/lib/Horde/Session/Null.php | 320 +++++++++++++++++++++++++++++ framework/Core/package.xml | 7 +- horde/rpc.php | 1 + 4 files changed, 330 insertions(+), 3 deletions(-) http://git.horde.org/horde-git/-/commit/b009bbc6c3f8ade37c64179157a385b660f25c47

Changes have been made in Git (master): commit b009bbc6c3f8

Wed, 29 Aug 2012 12:31:20 +0000

Changes have been made in Git (master): commit b009bbc6c3f8ade37c64179157a385b660f25c47 Author: Michael J Rubinsky Date: Thu Feb 23 15:41:08 2012 -0500 Use local storage when no session is available. Bug: 9733 framework/Core/lib/Horde/Registry.php | 5 +- framework/Core/lib/Horde/Session/Null.php | 320 +++++++++++++++++++++++++++++ framework/Core/package.xml | 7 +- horde/rpc.php | 1 + 4 files changed, 330 insertions(+), 3 deletions(-) http://git.horde.org/horde-git/-/commit/b009bbc6c3f8ade37c64179157a385b660f25c47

Any chance that this will be made available in FRAMEWORK_4 a

Thu, 27 Sep 2012 09:25:46 +0000

Any chance that this will be made available in FRAMEWORK_4 as well? A handful of ActiveSync clients (Android 2.3.6) currently leave hundreds of abandoned sessions behind every hour, which probably would be fixed by not creating sessions in the first place.

It doesn't look like there would be any obvious problems wit

Fri, 28 Sep 2012 13:37:50 +0000

It doesn't look like there would be any obvious problems with back porting it, I'll look into it.

Changes have been made in Git (FRAMEWORK_4): commit 3d82ef5

Fri, 28 Sep 2012 14:24:01 +0000

Changes have been made in Git (FRAMEWORK_4): commit 3d82ef5ca93558b1afeb6b07879565bb645c8e10 Author: Michael J Rubinsky Date: Thu Feb 23 15:41:08 2012 -0500 Use local storage when no session is available. Bug: 9733 Conflicts: framework/Core/package.xml framework/Core/lib/Horde/Registry.php | 5 +- framework/Core/lib/Horde/Session/Null.php | 320 +++++++++++++++++++++++++++++ framework/Core/package.xml | 6 + horde/rpc.php | 1 + 4 files changed, 330 insertions(+), 2 deletions(-) http://git.horde.org/horde-git/-/commit/3d82ef5ca93558b1afeb6b07879565bb645c8e10

This should be good now. Includes the following commits:

Fri, 28 Sep 2012 14:30:24 +0000

This should be good now. Includes the following commits: http://lists.horde.org/archives/commits/2012-September/016282.html If you could test these on your setup before they are released, that would be a big help.

> This should be good now. Includes the following commits:

Fri, 28 Sep 2012 15:07:51 +0000

> This should be good now. Includes the following commits: > > http://lists.horde.org/archives/commits/2012-September/016282.html > > > If you could test these on your setup before they are released, that > would be a big help. Looks good, except that 'horde-active-sessions' now doesn't work anymore: PHP Fatal error: Call to a member function getSessionsInfo() on a non-object in /usr/bin/horde-active-sessions on line 35 It looks like it doesn't really like the Horde_Session_Null storage handler. Attached patch works around this, by only using Horde_Session_Null when the SESSION_NONE flag is explicitly set. In all other cases, the behavior is as was previously the case.

I can also confirm that the changes to framework/Core/lib

Fri, 28 Sep 2012 15:24:50 +0000

I can also confirm that the changes to framework/Core/lib/Horde/Core/ActiveSync/Connector.php framework/Core/lib/Horde/Core/ActiveSync/Driver.php will clean up the sessions that are created due to ActiveSync traffic from my Android phones. Commenting out line 42 ($session_control = 'none';), at least the sessions that are created are cleaned up after the sync.

> Looks good, except that 'horde-active-sessions' now doesn'

Fri, 28 Sep 2012 15:30:59 +0000

> Looks good, except that 'horde-active-sessions' now doesn't work anymore: Great, thanks for testing. > PHP Fatal error: Call to a member function getSessionsInfo() on a > non-object in /usr/bin/horde-active-sessions on line 35 > > It looks like it doesn't really like the Horde_Session_Null storage > handler. Attached patch works around this, by only using > Horde_Session_Null when the SESSION_NONE flag is explicitly set. In > all other cases, the behavior is as was previously the case. This is actually fixed by another commit to the horde-active-sessions script that needed to be cherry-picked: http://lists.horde.org/archives/commits/2012-September/016286.html

> I can also confirm that the changes to > > framework/Cor

Fri, 28 Sep 2012 15:31:24 +0000

> I can also confirm that the changes to > > framework/Core/lib/Horde/Core/ActiveSync/Connector.php > framework/Core/lib/Horde/Core/ActiveSync/Driver.php > > will clean up the sessions that are created due to ActiveSync traffic > from my Android phones. Commenting out line 42 ($session_control = > 'none';), at least the sessions that are created are cleaned up after > the sync. Great, thanks again for the testing. >

> This should be good now. Includes the following commits:

Sat, 29 Sep 2012 09:58:15 +0000

> This should be good now. Includes the following commits: > > http://lists.horde.org/archives/commits/2012-September/016282.html > > > If you could test these on your setup before they are released, that > would be a big help. With all these patches applied, there is one thing left. I use memcache as a session handler (config/conf.php): $conf['sessionhandler']['params']['track_lifetime'] = 43200; $conf['sessionhandler']['params']['track'] = true; $conf['sessionhandler']['type'] = 'Memcache'; $conf['sessionhandler']['memcache'] = false; ActiveSync now no longer creates (or leaves behind abandoned) sessions, however I see zero length sessions popping up under the 'session.path' as defined in 'php.ini': session.save_handler = files session.save_path = "/var/lib/php5" These empty sessions are created when ActiveSync is run. I never noticed these empty sessions before, so I tried if adding $session->setup(false, $args['session_cache_limiter']); that was commented out for a while (and now removed) in Registry.php made a difference. It did, no more zero length sessions are created. Could it be that above line is actually doing something useful?

> These empty sessions are created when ActiveSync is run. I

Sat, 29 Sep 2012 10:32:21 +0000

> These empty sessions are created when ActiveSync is run. I never > noticed these empty sessions before, so I tried if adding > > $session->setup(false, $args['session_cache_limiter']); > > that was commented out for a while (and now removed) in Registry.php > made a difference. It did, no more zero length sessions are created. > Could it be that above line is actually doing something useful? Forget about the above remark, the zero length sessions are created regardless of the presence of the above line. So somehow when using the Horde_Session_Null handler, the Horde configuring settings for the session handler are ignored and the session handler as configured in 'php.ini' is used.

>> Looks good, except that 'horde-active-sessions' now doesn

Sat, 29 Sep 2012 18:02:59 +0000

>> Looks good, except that 'horde-active-sessions' now doesn't work anymore: > > Great, thanks for testing. > >> PHP Fatal error: Call to a member function getSessionsInfo() on a >> non-object in /usr/bin/horde-active-sessions on line 35 >> >> It looks like it doesn't really like the Horde_Session_Null storage >> handler. Attached patch works around this, by only using >> Horde_Session_Null when the SESSION_NONE flag is explicitly set. In >> all other cases, the behavior is as was previously the case. > > This is actually fixed by another commit to the horde-active-sessions > script that needed to be cherry-picked: > > http://lists.horde.org/archives/commits/2012-September/016286.html No more errors are shown, but now I consistently get '0' as number of active sessions, despite the fact that 'admin/sessions.php' returns that there are active sessions.

> Forget about the above remark, the zero length sessions ar

Sun, 30 Sep 2012 19:17:08 +0000

> Forget about the above remark, the zero length sessions ar

Sun, 30 Sep 2012 19:24:59 +0000

> Forget about the above remark, the zero length sessions are created > regardless of the presence of the above line. So somehow when using > the Horde_Session_Null handler, the Horde configuring settings for > the session handler are ignored and the session handler as configured > in 'php.ini' is used. Some more information for the above. In the 'php.ini' file, I have session.save_handler = files while Horde is configured to use memcache as session handler (see comment #38). It looks like for each ActiveSync request, a zero-length session file is created. Most of them are removed almost immediately (when the connection is closed), but for some reason sometimes the connection stalls in the ESTABLISHED or CLOSE_WAIT state. In that case, the zero-length session file is finally removed when the lingering connection times out. No session file is created if I comment out line 42 in rpc.php $session_control = 'none'; in which case ActiveSync request will create a memcache session, but which seems to be removed before the connection stalls. What causes the Horde_Session_Null handler to create an empty session in the first place and why isn't it using memcache for storing the session, but instead falls back to the session handler defined in php.ini?

> What causes the Horde_Session_Null handler to create an em

Sun, 30 Sep 2012 19:30:27 +0000

> What causes the Horde_Session_Null handler to create an empty session > in the first place and why isn't it using memcache for storing the > session, but instead falls back to the session handler defined in > php.ini? Never mind, our messages crossed. It's clear to me now what's happening.

> No more errors are shown, but now I consistently get '0' a

Sun, 30 Sep 2012 19:38:56 +0000

> No more errors are shown, but now I consistently get '0' as number of > active sessions, despite the fact that 'admin/sessions.php' returns > that there are active sessions. I'm seeing this too, both in FW_4 and master. The problem, at least for me, is caused by a different value of sys_get_temp_dir() being returned for cli requests vs fastcgi requests. Still investigating why this is happening.

>> No more errors are shown, but now I consistently get '0'

Sun, 30 Sep 2012 19:40:13 +0000

>> No more errors are shown, but now I consistently get '0' as number of >> active sessions, despite the fact that 'admin/sessions.php' returns >> that there are active sessions. > > I'm seeing this too, both in FW_4 and master. The problem, at least > for me, is caused by a different value of sys_get_temp_dir() being > returned for cli requests vs fastcgi requests. Still investigating > why this is happening. ...I should also mention that I see this even if I remove the check for disabling sessions. I.e., this happens even if creating a "normal" session for CLI.

>>> No more errors are shown, but now I consistently get '0'

Sun, 30 Sep 2012 19:47:30 +0000

>>> No more errors are shown, but now I consistently get '0' as number of >>> active sessions, despite the fact that 'admin/sessions.php' returns >>> that there are active sessions. >> >> I'm seeing this too, both in FW_4 and master. The problem, at least >> for me, is caused by a different value of sys_get_temp_dir() being >> returned for cli requests vs fastcgi requests. Still investigating >> why this is happening. > > ...I should also mention that I see this even if I remove the check > for disabling sessions. I.e., this happens even if creating a > "normal" session for CLI. If I replace $GLOBALS['session'] = $session = new Horde_Session_Null(); by $GLOBALS['session'] = $session = new Horde_Session(); $session->setup(false, $args['session_cache_limiter']); which was used before (somewhere around line 423 in Horde/Registry.php), 'horde-active-sessions -ll' reports the same sessions as 'admin/sessions.php'.

Ok. I see what's happening now. The session data is being de

Sun, 30 Sep 2012 20:41:52 +0000

Ok. I see what's happening now. The session data is being decoded into $_SESSION to parse the sessions for horde-active-sessions, but the Null handler doesn't use $_SESSION for storage. The issue with my session save path was getting in the way of me seeing this. Not sure what that is about, but using the "File" session driver instead allows me to see this. I've committed your earlier patch, which now fixes it locally for me too. Thanks!