[horde] "Error: User is not authorized for imp" with PHP 5.6 ... another update

[Andy Dorman]

On 06/10/2014 10:00 AM, Andy Dorman wrote:
> On 06/06/2014 09:20 AM, Andy Dorman wrote:
>> On 05/29/2014 03:08 PM, Michael M Slusarz wrote:
>>> Quoting Ernie Dunbar <maillist at lightspeed.ca>:
>>>
>>>> After yesterday's difficulty in getting Horde set up (I moved the
>>>> directory back to its original installation value and changed back what
>>>> configuration I had changed), I'm now up against something totally new.
>>>>
>>>> I'm able to log in to Horde with a regular user as well as the
>>>> administrator, authenticate against our IMAP server (I can see the
>>>> successful authentication in the IMAP server's logs), but nobody can
>>>> use
>>>> IMP. I just see that panel filled with the message:
>>>>
>>>> "ERROR
>>>>
>>>> User is not authorized for imp"
>>>>
>>>> If I try to click on the "Mail" menu at the top, I apparently get
>>>> logged
>>>> out, which seems strange.
>>>
>>> No... you are being kicked out to the IMP authentication screen.  I've
>>> been meaning to make this more clear on the login screen, so I should
>>> probably do it before we release 5.2.
>>>
>>> michael
>>>
>>> ___________________________________
>>> Michael Slusarz [slusarz at horde.org]
>>>
>>
>> I just ran into the same problem, imp login failure, but I believe it is
>> because php 5.6 has apparently changed something that is causing imp
>> authentication to fail.  So far I have not found a good indication of
>> what that might be.
>>
>> We run a development server where we test the latest debian release of
>> Horde Groupware Webmail (currently Horde 5.1.6/IMP 6.1.7-1).
>>
>> It has been working well with only a couple of minor issues (apparent
>> cookie timeouts and such).  Last night it was working fine and I read my
>> email with no problems.
>>
>> This morning I updated the development server to PHP 5.6.0-beta3 and was
>> very surprised when I tried to log in and got the Horde fatal error page
>> at the end of this email.
>>
>> I mainly want to alert the community that there may be a coming issue
>> with PHP 5.6 that needs to be addressed.  And if anyone knows of a
>> suggested patch to test, I will be happy to try it.
>>
>> We are using Apache2 with php-fpm and there is nothing in the php-fpm
>> log that indicates a problem.
>
> A quick update on the PHP 5.6 login problem with IMP.
>
> - We have been unable to revert our dev server(s) back from PHP 5.6
> because of complications unrelated to Horde.  So we are stuck for the
> moment.  The good news is this only affects our dev server and has made
> us pretty dedicated to fixing it.
>
> - The issue is not limited to Horde/IMP.  PHP 5.6 is also affecting
> logins with roundcube AND even Drupal 6/7.  No one appears to know why
> yet.  I was able to directly confirm the Drupal 6/7 issue when I
> mistakenly let our Drupal dev server upgrade PHP this weekend.
> Fortunately I realized my mistake before upgrading the production
> servers.  There I held PHP at 5.5 while upgrading everything else and
> the production sites are fine.
>
> - I reviewed the PHP 5.6 incompatible change docs at
> http://www.php.net/manual/en/migration56.incompatible.php
> and tried adding openssl.verify_peer=false and
> openssl.verify_peer_name=false to our php5/fpm/php.ini and that did not
> help.  So we are stuck at the moment.
>
> If anyone has any ideas or suggestions, we would love to hear them.
>
> Thanks,
>

More info.  After some experimenting with /horde/test.php we have found:

1. None of the /etc/php5/fpm/php.ini settings below helps:

- openssl.cafile = 
/etc/ssl/certs/ourdomain_cert/mail.ourdomain.com.ca-bundle (same as used 
by the local IMAP server to which we are trying to connect)

- openssl.capath = /etc/ssl/certs/ourdomain_cert/

- openssl.verify_peer = false

- openssl.verify_peer_name = false,


2. We can connect fine without TLS by setting $servers 
['advanced']['secure'] = false; in our imp/backends.local.php

So, while connecting without TLS is OK as long as we are connecting to 
our local IMAP server or one on our local private network, this is NOT 
an acceptable solution as it prevents connecting to any remote IMAP 
servers...this may have a bad impact on the new remote mail account 
feature for IMP.

If anyone sees anything dumb or wrong with what we have tried above, 
please speak up and I will be happy to try something else and report back.

-- 
Andy Dorman