-
Notifications
You must be signed in to change notification settings - Fork 337
user_external with imap: too many connections to the server #2213
Comments
+1 |
Have you specified the (optional) allowed domain for each mail server as described in the user_external README.md? |
"allowed domain"?
The problem is not about blocked connections. After the login process is done, when browsing the pages, you don't have any more imap connections. Edit: |
Hooo.. Sorry.
Well, the problem is that there are hundreds of domains and new ones are created regularly, so that's unfortunately not an option for me. |
I'm using a customized version of OC/apps/user_external/lib/imap.php that requires users to login using a full email address, then returns 'false' if the mail server address doesn't apply. However, I only have 4 domains to worry about; this code won't scale very well to hundreds of domains. Here is my customized code, in case there is something here that might help you. 'DISABLE_AUTHENTICATOR' (added to the imap_open command) may help if some of your 13 connections are failing due to an auth mechanism mis-match. My mail server reports that 'CRAM-MD5' is available, but it really isn't -- which was inserting significant delays in user logins. This code:
|
Once again, a big thanks for your help. Your code gave me some ideas and I finally managed to have a solution that seems to work smoothly, well much more smoothly than before. The idea is before trying to do the imap_open command, I do a db search to find all existing backends for a mail address. I can then compare the backend in the Db and the backend used in this call, and only execute an imap_open if they are similar. I'm sure this can be done in a much better way, but that's all I was able to do. Feel free to add comments or criticism to my method. In user_external/lib/base.php, I added the function getUserMailbox :
In user_external/lib/imap.php, I modified the checkPassword function :
|
Excellent. I think that user authentication has been refactored in Owncloud 10; you may need to revisit this when you upgrade. For what it's worth, on my server I keep copies of my modified file (imap.php) and a copy of the unmodified, original version (imap.php.org) in a separate folder that is not affected by owncloud upgrades. After each upgrade, I compare the "new" imap.php with my saved "imap.php.org". So far (for the last 2 years anyway) this has shown that there have been no changes to imap.php, so I feel safe copying my modified imap.php over the version that was installed by the upgrade. |
Affected apps
user_external
Expected behaviour
When using user_external app, have only 1 connection to each imap server configured and keep the info (success or failure) for after.
Actual behaviour
11 consecutive imap_open calls are made when login in the app + 2 others a bit later.
That's a lot.
When configuring several Imap server (I guess it's the same if it's an Imap and a ftp backend), and the person who tries to connect is from the second imap server, we loose something like 13 x 2 sec (each attempt on the first imap server) + 13 x 0,something sec (not a lot, but x 13 makes it bigger) for the login process.. That's quite huge.
But, after that, when navigating in the interface, no more imap_open are called (the expected behaviour).
This should be applied as soon as the first imap_open return true.
Steps to reproduce
Server configuration
Debian Jessie 8.8
Web server:
nginx/1.10.3
Database:
mariadb-server 10.0.30-0+deb8u2
PHP version:
PHP 7.0.18-1~dotdeb+8.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.18-1~dotdeb+8.1, Copyright (c) 1999-2017, by Zend Technologies
ownCloud version:
9.1.2
The text was updated successfully, but these errors were encountered: