Rocket.chat: Timeout while changing avatar without internet connection

[magicbelette]

Description:

When editing the profile, users have to wait for the "Loading suggestions..." timeout to change their avatar, even if the option "Accounts_SetDefaultAvatar" is disabled.

Server Setup Information:

• Version of Rocket.Chat Server: 0.62.1
• Operating System: Debian
• Deployment Method(snap/docker/tar/etc): Tar
• Number of Running Instances: 3
• DB Replicaset Oplog: Enabled
• Node Version: 8.9.3
• mongoDB Version: 3.2.12

Steps to Reproduce:

1. Disable the Internet connection or block gravatar.com on the rocketChat server
   $ sudo iptables -A OUTPUT -d 192.0.73.2 -j DROP
2. Edit user profil in RocketChat

Expected behavior:

Do not try to contact gravatar.com when "Accounts_SetDefaultAvatar" is disabled or anything else that allow changing avatar without to wait for the timeout.

Actual behavior:

Users have to wait the timeout to gravatar.com to change their avatar

Relevant logs:

Mar 13 10:04:27 srv-01 nodejs-rocketchat0[26280]: rocketchat_logger rocketchat_logger.js:278 #033[34mMeteor ➔ method#033[39m getAvatarSuggestion -> userId: c8P5ygFNHtd2a4qDz , arguments: {}

[pettitto]

Is this similar to https://github.com/RocketChat/Rocket.Chat/issues/8992 ?

[ipikiiskinen]

We have a Rocket.Chat 3.5.0 installation in internal network where there is no access to internet.
We noticed that Account settings takes ages to get changed & saved.
Investigations revealed that when accessing to Account settings Rocket.Chat tries to take connections to DST=192.0.73.2 which turned out to be Gravatar service (secure.gravatar.com:443).

Accounts_SetDefaultAvatar setting is disabled in our system.

It seems that when this connection is NOT available some timeout sequence is blocking changes to the user account settings. It can take quite a long time, until some timeout happens and the changes take place.
User can't change even own preferences (well after a long time yes, but not as user expects), so this not just a profile picture issue.

We have tested that if the same instance is started with HTTP proxy settings and outbound connections to secure.gravatar.com:443 are allowed, the account setting changes takes place instantly.

I think this issue may be related?

[ipikiiskinen]

Just if anyone else drops into this issue, here's a workaround:
Create output reject rule(s) for your (local) firewall to secure.gravatar.com (port 443).