[horde] "Error: User is not authorized for imp" with PHP 5.6 ... Solution Found
Andy Dorman
adorman at ironicdesign.com
Fri Jun 13 14:40:15 UTC 2014
On 06/12/2014 01:15 PM, Michael M Slusarz wrote:
> Quoting Andy Dorman <adorman at ironicdesign.com>:
>
>> On 06/12/2014 01:54 AM, Michael M Slusarz wrote:
>>> Quoting Andy Dorman <adorman at ironicdesign.com>:
>>>
>>>> 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.
>>>
>>> A temporary fix might be to change the following in
>>> Horde/Socket/Client.php (in PEAR installation directory).
>>>
>>> Line 177-ish. From:
>>>
>>> $this->_stream = @stream_socket_client(
>>> $conn . $host . ':' . $port,
>>> $error_number,
>>> $error_string,
>>> $timeout
>>> );
>>>
>>> to:
>>>
>>> $this->_stream = @stream_socket_client(
>>> $conn . $host . ':' . $port,
>>> $error_number,
>>> $error_string,
>>> $timeout,
>>> STREAM_CLIENT_CONNECT,
>>> stream_context_create(array(
>>> 'ssl' => array(
>>> 'verify_peer' => false,
>>> 'verify_peer_name' => false,
>>> )
>>> ))
>>> );
>>>
>>> Not tested, so YMMV.
>>>
>>> michael
>>>
>>
>> Thanks Michael! I suspected the openssl context might need to be set
>> in the code, I had no idea where though.
>>
>> I will try this and report back. Even though it is NOT a preferred
>> solution because it turns off peer verification, it could at least
>> better indicate where and what I need to change to get this working
>> with tls.
>
> The flip side is that this is also completely opposite of the behavior
> pre-5.6 though. So if this fix does work, this will likely be the
> default configuration for Horde packages, at least for the current major
> point releases.
>
Michael, you are brilliant. Thank you.
Your fix worked. I modified /usr/share/php/Horde/Socket/Client.php
(where debian installs it) as you suggested. After modification the
code looks like this starting on line 177.
$this->_stream = @stream_socket_client(
$conn . $host . ':' . $port,
$error_number,
$error_string,
$timeout,
STREAM_CLIENT_CONNECT,
stream_context_create (array (
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
)
))
);
I then modified our imp/backends.local.php to turn tls back on
$servers ['imap']['disabled'] = true;
$servers ['advanced']['disabled'] = false;
$servers ['advanced']['hordeauth'] = 'full';
$servers ['advanced']['hostspec'] = $hostname;
$servers ['advanced']['preferred'] = '';
$servers ['advanced']['secure'] = 'tls';
...
and restarted apache & php-fpm and tried it and it worked great.
I also used test.php to confirm I could connect to our IMAP server with
and without a secure connection and those tests worked fine too.
Thanks again and have a great weekend.
--
Andy Dorman
More information about the horde
mailing list