SuiteCRM incorrectly url-encodes "special" characters in (at least) the Gmail smtp password. Or, forgets to un-encode them, depending on how you look at it.
When setting up smtp integration via Administration -> Admin -> Email Settings, I entered the credentials for the Gmail account for SuiteCRM and noticed I received an auth failure.
I had to go into the PHP code and modify it to get the base64-encoded fields instead of just "--obfuscated--", and that's when I saw that a '>' character in the password I entered was being encoded as > before being sent to Gmail's smtp server.
When the password was changed to not have any "special" characters, everything started working, I could send a test message successfully.
Expected Behavior
When putting special characters into Gmail smtp passwords, it should send the password as-stated, and not a url-encoded/escaped version of it.
Actual Behavior
It sends the url-encoded/escaped version of the password, not the actual password.
Possible Fix
Either don't escape the password in the first place, or remember to unescape it before sending to the smtp server.
Steps to Reproduce
Create a gmail account with a '>' in the password.
Go to Administration -> Admin -> Email Settings
Set up Gmail smtp for SuiteCRM.
Edit the code in /bitnami/suitecrm/include/SugarPHPMailer.php in the app container like the following:
$this->Debugoutput = function($str, $level) {
// obfuscate part of response if previous line was a server 334 request, for authentication data:
//static $previousIs334 = true;
//if ($previousIs334) {
// $this->fullSmtpLog .= "$level: CLIENT -> SERVER: ---obfuscated---\n";
//} else {
$this->fullSmtpLog .= "$level: $str\n";
//}
//$previousIs334 = (strpos($str, 'SERVER -> CLIENT: 334') !== false);
};
Open your browser debugger to capture the HTTP response.
Click "send test email" and enter a proper email address.
Click send.
Observe the now-base64-encoded bits in the debug output (before editing the code, it would have been --obfuscated--.
Decode those values doing the following, or the equivalent for the password field:
Note that the '>' that was entered for the password actually becomes >.
Context
This bug effectively breaks smtp integration in a really obscure way that was fairly difficult to debug.
The workaround is easy (change the password to something without "special" characters), but it's difficult for the user/admin to realize that's the proper workaround.
Your Environment
SuiteCRM Version used:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
bitnami/suitecrm latest 3e77e7dc807a 5 weeks ago 451 MB
bitnami/mariadb latest af8c432caec4 5 weeks ago 298 MB
Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)):
Chrome Version 68.0.3440.106 (Official Build) (64-bit)
Environment name and version (e.g. MySQL, PHP 7):
# php --version
PHP 7.0.31 (cli) (built: Jul 27 2018 11:03:09) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.31, Copyright (c) 1999-2017, by Zend Technologies
$ mysql --version
mysql Ver 15.1 Distrib 10.1.35-MariaDB, for Linux (x86_64) using readline 5.1
Issue
SuiteCRM incorrectly url-encodes "special" characters in (at least) the Gmail smtp password. Or, forgets to un-encode them, depending on how you look at it.
When setting up smtp integration via Administration -> Admin -> Email Settings, I entered the credentials for the Gmail account for SuiteCRM and noticed I received an auth failure.
I had to go into the PHP code and modify it to get the base64-encoded fields instead of just "--obfuscated--", and that's when I saw that a '>' character in the password I entered was being encoded as
>
before being sent to Gmail's smtp server.When the password was changed to not have any "special" characters, everything started working, I could send a test message successfully.
Expected Behavior
When putting special characters into Gmail smtp passwords, it should send the password as-stated, and not a url-encoded/escaped version of it.
Actual Behavior
It sends the url-encoded/escaped version of the password, not the actual password.
Possible Fix
Either don't escape the password in the first place, or remember to unescape it before sending to the smtp server.
Steps to Reproduce
Create a gmail account with a '>' in the password. Go to Administration -> Admin -> Email Settings Set up Gmail smtp for SuiteCRM. Edit the code in /bitnami/suitecrm/include/SugarPHPMailer.php in the app container like the following:
Open your browser debugger to capture the HTTP response. Click "send test email" and enter a proper email address. Click send. Observe the now-base64-encoded bits in the debug output (before editing the code, it would have been
--obfuscated--
. Decode those values doing the following, or the equivalent for the password field:Note that the '>' that was entered for the password actually becomes
>
.Context
This bug effectively breaks smtp integration in a really obscure way that was fairly difficult to debug. The workaround is easy (change the password to something without "special" characters), but it's difficult for the user/admin to realize that's the proper workaround.
Your Environment