Horde_Core 2.2.1

I see no need to support session IDs longer than 32 bytes at this 
time.  MD5 vs. other hashing methods shouldn't matter since we don't 
care about the cryptographical properties of these hashing algorithms 
- all we are doing is generating random token strings.  So there is no 
practical benefit of a longer session ID because a token is either 
obtained in full or not.

Additionally, there are some assumptions built in to Horde code that 
count on 32 byte (or less) session IDs.  No need to do a full audit at 
this time just to allow an increase in size.

Changes have been made in Git (master):

commit 032f2b6137f08ed12cc1844081067afeedb5c8d5
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Sun Feb 17 13:50:17 2013 -0700

     [mms] Ensure that session IDs are always 32 bytes long (Bug #12041).

  framework/Core/lib/Horde/Session.php |    6 ++++++
  framework/Core/package.xml           |    2 ++
  2 files changed, 8 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/032f2b6137f08ed12cc1844081067afeedb5c8d5

You are right.
The Hash-function is SHA256 and not SHA-1 (must have happend during 
the last PHP upgrade).

Regards,
Martin

Did you change the value of PHP's ;session.hash_function' ini value?   
We currently only support session.hash_function = 1 and 
session.hash_bits_per_character = 5

I found the problem (don't know where exactly it comes from):

horde_sessionhandler (description):
+----------------------+-------------+------+-----+---------+-------+
| Field                | Type        | Null | Key | Default | Extra |
+----------------------+-------------+------+-----+---------+-------+
| session_id           | varchar(32) | NO   | PRI | NULL    |       |
| session_lastmodified | int(11)     | NO   | MUL | NULL    |       |
| session_data         | blob        | YES  |     | NULL    |       |

As you can see, the session_id has 32 characters. The id generated is 
longer :)

E.g.:
Session-ID:   jiah80ekjoqbu0ccmrujkoluqpsqkjhpv60vg8dv001v4l5v6341
in Database: jiah80ekjoqbu0ccmrujkoluqpsqkjhp

So I extended the session_id to 64 Chars. Now it looks like this:
+----------------------+-------------+------+-----+---------+-------+
| Field                | Type        | Null | Key | Default | Extra |
+----------------------+-------------+------+-----+---------+-------+
| session_id           | varchar(64) | NO   | PRI |         |       |
| session_lastmodified | int(11)     | NO   | MUL | NULL    |       |
| session_data         | blob        | YES  |     | NULL    |       |
+----------------------+-------------+------+-----+---------+-------+

And now it is working again.

We explicitly check whether the session ID exists before deciding 
whether to make an INSERT or UPDATE query. You have to track this down 
yourself in Horde/SessionHandler/Storage/Sql.php in the write() method.

Ok. I emptied the table again, and I am using the mysqli-driver now 
(before mysql/PDO) Here is the result (in the end nothing changes; log 
again in DEBUG).

Here sessionhandler before the login:
MariaDB [horde]> select * from horde_sessionhandler;
Empty set (0.00 sec)

and after:
MariaDB [horde]> select session_id from horde_sessionhandler;
+----------------------------------+
| session_id                       |
+----------------------------------+
| dbobdsjjhiidd6cq54al4g56i5cv6tfr |
+----------------------------------+
1 row in set (0.00 sec)

Perhaps there is some "INSERT" instead of an "UPDATE"-Statement somewhere?

regards,
Martin

With an empty table, this error couldn't happen, because with an empty 
table there's no duplicate key. Which session handler backend exactly 
do you use, and did you try a different driver if using SQL (mysqli 
vs. mysql/pdo if using mysql)?

Is there any additional table besides the "horde_sessionhandler"? 
Emptying this table had no effect on the error.

Yes, you were right. Changing the sessionhandler to native made 
everything work again.
Next I try to empty the sessionhandlertables and try again with the 
SQL-Sessionhandler.

Regards,
Martin

The log unfortunately didn't contain the SQL queries that cause these 
errors for some reason. But I'm pretty sure those are coming from the 
SQL session handler. Try with the native session handler, or empty the 
session handler tables.

Here is a weblogin with Log-Level set to DEBUG. Hope this helps:

(See Attachment)

Also, please raise your log level, the SQL error is incomplete and not 
much helpful.

This seems highly unlikely since:
1) I use IMP authentication and it works fine for me
2) Nothing changed from Horde 5.0.3-5.0.4 (verified by running 'git 
log horde-5.0.3..horde-5.0.4 horde' from the base of the git repo)

With upgrading from horde 5.0.3 to 5.0.4 IMP-based authentication does 
not work any longer:

Log-Snippet:
Feb 13 23:01:36 chewie HORDE: [horde] Login success for xxx 
[10.100.14.240] to horde. [pid 11550 on line 163 of 
"/srv/www/vhosts/webmail.die-tessuns.de/htdocs_ssl/login.php"]
Feb 13 23:01:36 chewie HORDE: User is not authorized for horde [pid 
11550 on line 259 of "/usr/share/php5/PEAR/Horde/Registry.php"]
Feb 13 23:01:36 chewie HORDE: SQL QUERY FAILED: SQLSTATE[23000]: 
Integrity constraint violation: 1062 Duplicate entry 
's35d7coaa5939aulr1up013umt2hat93' for key 'PRIMARY'
Feb 13 23:01:36 chewie HORDE: [horde] SQL QUERY FAILED: 
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
's35d7coaa5939aulr1up013umt2hat93' for key 'PRIMARY'

config.php from horde (auth-Section):
$conf['auth']['admins'] = array('root');
$conf['auth']['checkip'] = true;
$conf['auth']['checkbrowser'] = true;
$conf['auth']['resetpassword'] = true;
$conf['auth']['alternate_login'] = false;
$conf['auth']['redirect_on_logout'] = false;
$conf['auth']['list_users'] = 'input';
$conf['auth']['params']['app'] = 'imp';
$conf['auth']['driver'] = 'application';
$conf['auth']['params']['count_bad_logins'] = false;
$conf['auth']['params']['login_block'] = false;
$conf['auth']['params']['login_block_count'] = 5;
$conf['auth']['params']['login_block_time'] = 5;


backends.local.php:
$servers['cyrus'] = array(
     'disabled' => false,
     'name' => 'Cyrus IMAP Server',
     'server' => 'localhost',
     'secure' => 'none',
     'hordeauth' => false,
     'protocol' => 'imap',
     'port' => 143,
     'maildomain' => 'some-domain.de',
     'smtphost' => 'localhost',
     'smtpport' => 25,
     'realm' => '',
     'preferred' => '',
     'admin' => array(
         'params' => array(
             'login' => 'cyrus',
             'password' => 'somepass',
             // The 'userhierarchy' parameter defaults to 'user.'
             // If you are using a nonstandard hierarchy for personal
             // mailboxes, you will need to set it here.
             'userhierarchy' => 'user.',
             // Although these defaults are normally all that is required,
             // you can modify the following parameters from their default
             // values.
             'protocol' => 'imap',
             'hostspec' => 'localhost',
             'port' => 143
         )
     ),
     'quota' => array(
         'driver' => 'imap',
         'params' => array('hide_quota_when_unlimited' => true),
     ),
     'acl' => array(
         'driver' => 'rfc2086',
     )
);

It all worked until 5.0.4. I changed nothing in the config-Files.
When authenticating this way I get a "normal" Login-Page back.
If I type a wrong Password I get the usual "Access-Denied page"
The Logs look like this in case of wron password:

Feb 13 23:08:24 chewie HORDE: [imp] Der E-Mail-Server hat die 
Authentifizierung verweigert. [pid 11509 on line 387 of 
"/srv/www/vhosts/webmail.die-tessuns.de/htdocs_ssl/imp/lib/Imap.php"]
Feb 13 23:08:24 chewie HORDE: [horde] FAILED LOGIN for someone 
[10.100.14.240] to Horde [pid 11509 on line 192 of 
"/srv/www/vhosts/webmail.die-tessuns.de/htdocs_ssl/login.php"]
Feb 13 23:08:24 chewie HORDE: [horde] SQL QUERY FAILED: 
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
's35d7coaa5939aulr1up013umt2hat93' for key 'PRIMARY'