SOLVED: Connection Timeout When Testing Inbound Settings

[dhammond2]

I'm new to SugarCRM, and I was pulling out my hair over an issue I kept experiencing in the inbound e-mail configuration. I was setting up a Gmail (Google Apps) account as my inbound source. At some point, I saved the configuration and then went back in to edit something (specifically, I corrected the username and kept everything else the same).

I then clicked on "Test Settings", and I got this:

Connection failed to gmail-imap.l.google.com,993: Connection timed out

Please check your settings and try again.

My first suspicion was that the timeout indicated a problem with the firewall settings. I took a look at the firewall, and everything looked fine. I then hit Google, and I found references to an old php-imap/php5-imap library in Debian/Ubuntu that may cause problems. But when I tried an IMAP connection with a minimal PHP test script, it seemed to connect okay.

Then, I whipped out Firebug to inspect the "Test Settings" AJAX request, in order to see what PHP script was being called, and I noticed that the AJAX request was passing a blank password parameter. Curious, I went into the SugarCRM source code and added a debug line to output the effective password just before the imap_open call, and it turned out the password was still blank.

You would think that trying to authenticate with an empty password would give you a login error, not a timeout. Well, as best as I can tell, SugarCRM seems to need the password before it can determine the set of service flags needed to make a proper connection, and it ends up trying to connect without the "/ssl" flag, thus resulting in the timeout.

From a user's point of view, the workaround is to click on "Change password", re-enter the account password, and THEN click "Test Settings". This seems to be the only way to pass the password on to the test connection code (that code doesn't seem to remember the settings you have in the database).

From a developer's point of view, there are a couple of changes that could be made to better deal with this scenario:

1. The code shouldn't require the password in order to generate a workable set of service flags, like the "/ssl" flag. I haven't looked into how these flags are finally generated (perhaps it comes during some sort of server handshake?), but it should be possible to come up with a reasonable initial set of flags based on the account settings alone. For example, if I simply add "$ie->service = '::::'.($useSsl ? 'ssl' : '').'::'.$ie->protocol.'::::::';" to the Popup.php code before the connectMailserver call, that results in a more appropriate error message in the event that the password isn't transmitted.

2. The "Test Settings" code could be made aware of the account ID you're editing, if it's an already-saved account, so that it can pull the password from the database in the event that the user hasn't clicked the "Change password" link.

I hope this proves helpful to someone.

[kbrill]

I found this exact same thing on a customers instance this week. I have submitted a bug report for this to get it fixed.

[hurst75]

Hello chaps,

I'm having the exact same issue. But no matter what I do, the password will not save. Is there anyway to hard code the password into the application?