6.0.0-git
2019-07-23

[#9733] Password lost during hordeauth authentication via API
Summary Password lost during hordeauth authentication via API
Queue Horde Base
Queue Version Git master
Type Bug
State Resolved
Priority 2. Medium
Owners mrubinsk (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 2011-03-28 (3039 days ago)
Due
Updated 2012-09-30 (2487 days ago)
Assigned
Resolved 2012-02-26 (2704 days ago)
Milestone 4.1
Patch No

History
2012-09-30 20:41:52 Michael Rubinsky Comment #47 Reply to this comment
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!

2012-09-30 19:47:30 arjen+horde (at) de-korte (dot) org Comment #46 Reply to this comment

[Show Quoted Text - 12 lines]
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'.
2012-09-30 19:40:13 Michael Rubinsky Comment #45 Reply to this comment
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.
2012-09-30 19:38:56 Michael Rubinsky Comment #44 Reply to this comment
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.
2012-09-30 19:30:27 arjen+horde (at) de-korte (dot) org Comment #43 Reply to this comment
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.
2012-09-30 19:24:59 arjen+horde (at) de-korte (dot) org Comment #42 Reply to this comment
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?
2012-09-30 19:17:08 Michael Rubinsky Comment #41 Reply to this comment
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.
This is a side effect of the Null handler calling session_start(). 
Even though we don't store any data in the session, we still must tell 
PHP to create one, otherwise certain data that is required to be 
available will not be. E.g., session_id() is used by Horde_Secret as 
an encryption key. The absence of this value breaks authentication in 
certain places.
2012-09-29 18:02:59 arjen+horde (at) de-korte (dot) org Comment #40 Reply to this comment

[Show Quoted Text - 16 lines]
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.
2012-09-29 10:32:21 arjen+horde (at) de-korte (dot) org Comment #39 Reply to this comment
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.
2012-09-29 09:58:15 arjen+horde (at) de-korte (dot) org Comment #38 Reply to this comment
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?
2012-09-28 15:31:24 Michael Rubinsky Comment #37 Reply to this comment

[Show Quoted Text - 9 lines]
Great, thanks again for the testing.
2012-09-28 15:30:59 Michael Rubinsky Comment #36 Reply to this comment
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
2012-09-28 15:24:50 arjen+horde (at) de-korte (dot) org Comment #35 Reply to this comment
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.

2012-09-28 15:07:51 arjen+horde (at) de-korte (dot) org Comment #34
New Attachment: Registry.php.diff Download
Reply to this comment
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.
2012-09-28 14:30:24 Michael Rubinsky Comment #33 Reply to this comment
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.
2012-09-28 14:24:01 Git Commit Comment #32 Reply to this comment
Changes have been made in Git (FRAMEWORK_4):

commit 3d82ef5ca93558b1afeb6b07879565bb645c8e10
Author: Michael J Rubinsky <mrubinsk@horde.org>
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
2012-09-28 13:37:50 Michael Rubinsky Comment #31 Reply to this comment
It doesn't look like there would be any obvious problems with back 
porting it, I'll look into it.
2012-09-27 09:25:46 arjen+horde (at) de-korte (dot) org Comment #30 Reply to this comment
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.
2012-08-29 12:31:20 Git Commit Comment #29 Reply to this comment
Changes have been made in Git (master):

commit b009bbc6c3f8ade37c64179157a385b660f25c47
Author: Michael J Rubinsky <mrubinsk@horde.org>
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
2012-02-26 01:37:51 Michael Rubinsky Taken from Horde DevelopersHorde Developers
State ⇒ Resolved
 
2012-02-26 01:36:30 Git Commit Comment #28 Reply to this comment
Changes have been made in Git (develop):

commit b009bbc6c3f8ade37c64179157a385b660f25c47
Author: Michael J Rubinsky <mrubinsk@horde.org>
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
2011-05-03 22:03:19 Michael Rubinsky Comment #27
Assigned to Michael Rubinsky
Priority ⇒ 2. Medium
Milestone ⇒ 4.1
Reply to this comment
Now that hotfix is in place for 4.0.x series, downgrade priority and 
target the proper fix for 4.1
2011-05-03 22:01:32 Git Commit Comment #26 Reply to this comment
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
2011-05-02 02:33:00 Michael Rubinsky Comment #25 Reply to this comment
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.
2011-05-02 02:31:00 Michael Rubinsky Comment #24 Reply to this comment
Agreed. This needs to be dealt with asap, kronolith API access is also 
broken as a result of this. See Bug: 9837
2011-04-26 19:50:08 Michael Slusarz Comment #23
Milestone ⇒
Reply to this comment
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.
2011-04-20 18:35:12 Michael Rubinsky Comment #22
Milestone ⇒ 4.1
Reply to this comment
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.
2011-04-19 16:00:38 Michael Rubinsky Comment #21 Reply to this comment
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.
2011-04-15 15:38:03 Git Commit Comment #20 Reply to this comment
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
2011-04-15 14:27:28 rsalmon (at) mbpgroup (dot) com Comment #19 Reply to this comment
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"]


2011-04-15 05:49:34 Git Commit Comment #18 Reply to this comment
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
2011-04-15 05:45:53 Michael Slusarz Comment #17 Reply to this comment
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).
2011-04-14 17:43:48 Michael Rubinsky Comment #16 Reply to this comment
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?
2011-04-14 17:34:29 Michael Slusarz Comment #15 Reply to this comment
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.
2011-04-14 17:33:37 Michael Rubinsky Comment #14 Reply to this comment
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.
2011-04-14 17:31:38 Michael Rubinsky Comment #13 Reply to this comment
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
2011-04-14 17:31:14 Michael Slusarz Comment #12 Reply to this comment
  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.
2011-04-14 17:25:02 Michael Rubinsky Comment #11 Reply to this comment
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.
2011-04-14 17:18:23 Michael Slusarz Comment #10 Reply to this comment
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.
2011-04-14 17:14:27 Michael Slusarz Comment #9 Reply to this comment
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.

2011-04-14 13:32:13 Michael Rubinsky Comment #8 Reply to this comment
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.
2011-04-14 10:28:42 bjoern (dot) koester (at) mediata (dot) net Comment #7 Reply to this comment
We always geht the same error messages when trieing to coonect with 
active sync.

horde with imp auth

2011-04-14 08:00:14 Jan Schneider Comment #6 Reply to this comment
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?
2011-04-14 04:54:32 Michael Rubinsky Comment #5 Reply to this comment
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.

2011-04-12 14:27:37 Jan Schneider Comment #4
Priority ⇒ 3. High
Milestone ⇒ 4.0.1
Reply to this comment
Bumping, because this might cause users to get locked out due to too 
many failed logins.
2011-03-28 20:55:45 Michael Slusarz Comment #3
Assigned to Horde DevelopersHorde Developers
Reply to this comment
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.
2011-03-28 20:09:03 Michael Slusarz Comment #2
Taken from Horde DevelopersHorde Developers
Reply to this comment
Duplicate of Bug #9718?
2011-03-28 14:02:01 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ Password lost during hordeauth authentication via API
Queue ⇒ Horde Base
Assigned to Horde DevelopersHorde Developers
Milestone ⇒
Patch ⇒ No
Reply to this comment
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.

Saved Queries