Introduction

Rocket.Chat Desktop recently released version 3.0.2. In this release Rocket.Chat team introduced Server validation and hard-coded the minimum required Rocket.Chat server version of 2.0.0.

With this breaking change, Rocket.Chat Desktop will no longer work on Rocket.Chat Server running on version < 2.0.0. If you try connecting to Rocket.Chat server running an older version, you’ll be prompted with the following message.

Firstly, the message is vague and unclear, and at first, the user will try to double-check if they have entered the correct URL. Secondly, this message has nothing to do with the server version. A more appropriate message would have been:

“You are connecting to the server that is running an older version and is no longer supported. Please upgrade your Rocket.Chat server.”

Many users and companies who are running Rocket.Chat server version < 2.0.0 in production is suddenly left with one option, UPGRADE!

However, an overnight server upgrade is not possible for any production software unless it’s Heartbleed of course.

One of the possible workarounds is to request end-users to re-install the older version of Rocket.Chat Desktop < 3.0.0, which doesn’t perform the Server Validation. But in reality, this is not feasible when you have 100s of users!

Let’s buy us some time!

Alright, we know the upgrade is mandatory but not possible overnight. So now what!

I began drilling into the Rocket.Chat Desktop source code to figure out how Server validation is actually performed under the hood.

In line no. 18, the server version information is fetched by requesting api/info endpoint. If you curl this endpoint, it’ll return the server version information as JSON response:

Hmm…that’s interesting. The version information is then parsed from JSON response and is compared against the hard-coded REQUIRED_SERVER_VERSION_RANGE.

Well, what if we modify the JSON response on the fly and return a version ≥ 2.0.0 without upgrading the server. If you have deployed Rocket.Chat server behind AWS load-balancer then we can add a custom rule and craft a custom JSON response using Fixed Response feature of AWS ALB.

And voila! we’ve upgraded the server in the eyes of Rocket.Chat Desktop.

With this simple change, if you now try connecting to the server using the latest Rocket.Chat Desktop version. Not surprisingly, it will connect even though the server is still running an older version.

Your users should now be able to connect to the server and use the latest Rocket.Chat Desktop normally.

WARNING! Do not use this “hack” as a permanent fix. This “hack” allows your team some breathing space while you start planning on upgrading the Rocket.Chat server version.

Conclusion

Rocket.Chat Team should have kept the backward compatibility with the older server version and gave a deadline to act. Instead, they went the other route and forced everyone to upgrade immediately. Anyway, if you are still running an older server version then it’s about time you plan your upgrade soon!

P.S. Rocket.Chat is a really good open-source communication and collaboration tool. If you haven't check it out. https://rocket.chat/