SSO hash fails because encoded password has trailing spaces

[L3CC]

When using RainLoop\Api::GetUserSsoHash I was able to log into some accounts (imap.gmail.com) but not into others (imap.zoho.com or imap-mail.outlook.com). When the SSO login fails the login screen is shown and a normal login can be done. After checking the logs I found that the same password, when sent to IMAP servers, looked different between an SSO call and a normal login. For instance: sso: 5pZGVpYS5uZXQAcHV0QHF1ZXBAcml1QHpvaG8AAAAAAAAAAAAAAAAAAAA= login: 5pZGVpYS5uZXQAcHV0QHF1ZXBAcml1QHpvaG8=

Editing Api.php function GetUserSsoHash, the following change solved my problem: // 'Password' => $sPassword, 'Password' => trim( $sPassword ),

Note: GMail ignores trailing spaces in passwords.

[RainLoop]

Thanks

[RainLoop]

Try to trim the password before function GetUserSsoHash. It is not a good idea to trim or some way to change email password.

[L3CC]

I did try that before, when I was testing the problem, but no luck. Without the trim, the password sent to the IMAP will have those trailing 'AAAA...'. That's what made me suspect of trailing spaces on first place. However, in a deeper look, the issue is really frustrating and I can't find a clear reason for it. If we check the content of $sPassword inside GetUserSsoHash it has no trailing spaces at all. I can't figure why or how the trim in that place is making a different outcome...

[RainLoop]

$email = 'user@yourdomain.com';
$pass = '   123456   ';

$ssoHash = \RainLoop\Api::GetUserSsoHash($email, trim($pass));

[L3CC]

Forget the issue, you were right. Sorry. The culprit was a decrypt routine. I have the password encrypted at database level and I was decrypting it just before calling GetUserSsoHash. In the tests I was trimming it before decryption and the outcome looked ok. When printed the password didn't show any trailing spaces. However testing the strlen gave me a lenght of 32 in a string with 17 visible characters. Some "invisible trash" is being added by the decrypt routine, perhaps some null bytes and those appeared as 'AAAA...' in the IMAP call. It just happened the gmail password I was using had 32 characters so the problem didn't occur. Full of traps, a programmer's life is...