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

[Andy Dorman]

On 06/11/2014 12:53 PM, Michael M Slusarz wrote:
> Quoting Andy Dorman <adorman at ironicdesign.com>:
>
>> 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,
>
> This is most likely your issue.  If using a self-signed certificate, you
> won't be able to connect.
>

Michael, thank you for your response.

I definitely agree it is likely our issue.  Something changed in PHP 5.6 
that is no longer compatible with our development configuration and I am 
just trying to document the issue and hopefully the fix in case others 
run into it later.

For the record, I used dummy cert file names above...we actually have a 
Comodo RSA Domain Validation Secure Server certificate re-issued April 
14 of this year for mail.fanmail.com (right after the heartbleed 
vulnerability became public knowledge).  I used the proper cert path & 
file names when I tried it in our dev server.

This cert is legitimate and works great for https and IMAP tls on about 
20 servers for every client we have found except PHP 5.6

> Note that these are NOT php.ini settings so the verify_* configuration
> options above don't do anything.
>

I hope it is obvious that PHP is NOT my primary programming language and 
I was wondering where to try those settings.  ;-)  It would be helpful 
if you or any of the other really smart PHP developers in the list know 
where I should try setting them.

I tried it in php.ini based on the PHP 5.6 migration web page at

http://www.php.net/manual/en/migration56.openssl.php

where it also discussed openssl.cafile or openssl.capath configuration 
settings.

So since cafile & capath were at the end of the PHP 5.6 php.ini file 
(see below) I hoped it would be worth a shot to see if I could try 
setting verify_peer and verify_peer_name back to their old default 
(false) there in the php.ini too.  I am not surprised I was wrong, but I 
am not sure where else to apply them.

...
[openssl]
; The location of a Certificate Authority (CA) file on the local filesystem
; to use when verifying the identity of SSL/TLS peers. Most users should
; not specify a value for this directive as PHP will attempt to use the
; OS-managed cert stores in its absence. If specified, this value may still
; be overridden on a per-stream basis via the "cafile" SSL stream context
; option.
;openssl.cafile=

; If openssl.cafile is not specified or if the CA file is not found, the
; directory pointed to by openssl.capath is searched for a suitable
; certificate. This value must be a correctly hashed certificate directory.
; Most users should not specify a value for this directive as PHP will
; attempt to use the OS-managed cert stores in its absence. If specified,
; this value may still be overridden on a per-stream basis via the "capath"
; SSL stream context option.
;openssl.capath=



Thank you Michael and everyone for your continued patience and help as 
we work through this with PHP 5.6

Have a great week!

-- 
Andy Dorman