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!

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'.

...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.

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.

Never mind, our messages crossed. It's clear to me now what's happening.

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?

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.

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 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.

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?

Great, thanks again for the testing.

Great, thanks for testing.
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/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'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.

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.

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

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

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.

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

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

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 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

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.

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

From Ticket #9979 - reports that this breaks AJAX timeout request.   
So refactoring/fixing this can not wait until 4.1.

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.

.
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.

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

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:  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

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).

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?

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.

Exactly. That's the basic question I'm getting at here.


   Jan's the one who implemented this, so he would

But there is no display context when we are talking about non-horde 
client requests for rpc.php
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 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.

Enabling sessions shouldn't break AS, but introduces all that overhead 
for something that is not required for anything related to the AS 
request.
  I guess I'm still unclear as to why IMP needs to be involved here at 
all if not using IMP auth.

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.

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.

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.

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

horde with imp auth

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?

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.

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

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.

Duplicate of Bug #9718?

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.