We recently moved from RocketChat (great chat software) over to Teamwork Chat (okay service) as we are already paying for Teamwork’s full suite. Teamwork chat integrates a bit better into the suite but has the disadvantage of not working at all when offline.
Brazil-based open source project RocketChat originally gained our business as a non-US company hosted on its own servers. This meant we enjoyed reasonable privacy when in chat. RocketChat lost this competitive advantage as they use Google authorization, Google Analytics and host on Amazon Web Services. So there is no privacy on RocketChat either. It’s an open book to the NSA and the Patriot Act (or whatever its current update is).
Teamwork Chat is not really any better (it’s hosted on AWS as well) but at this point it’s no worse (an early iteration of Teamwork Chat was one of the worst SAAS I’d ever used – having the application open in the background meant an entire processor was run at 100% all the time – great fun for overheating and crippling laptops). Our deeper views on Teamwork suite should be the subject of a separate article. Here’s some older articles which discuss Teamwork Projects in some depth. It’s time for a new one though.
One nice bit of business which worked in RocketChat was piping in our server alerts from UptimeRobot (a great, reliable and inexpensive service – 100 monitors every 1 minute are only $90/year). Here are the Uptime Robot webook settings to make it work with RocketChat:
- URL – use your callback URL like
https://fvchat.rocket.chat/hooks/s7f9...../Cnd90....?– notice the?at the end, it has to be put in! - POST value (JSON format) set to:
{ "url": "*monitorURL*", "status": "*alertType*" } - Enable “Send as JSON (application/json)”
After moving over to Teamwork Chat, we had a lot of difficulty marrying Teamwork Chat and UptimeRobot.
In theory it’s possible, here’s what the code looks like:
curl -d '{"conversationId":"$CHANNELID", "message": { "body":
"$MESSAGE_CONTENT"}}' \
-H "Authorization : Basic $API_TOKEN;" \
-H "Content-Type: application/json" \
-X POST https://fvaccount.teamworkpm.net/chat/rooms/$CHANNELID/messages
The parameters are:
- $CHANNELID – The channel where you want to publish the message –
- you can see it in Chat’s url
- $MESSAGE_CONTENT – message content, you can use @all, @online to
- make use of notifications
- $API_TOKEN – user api token – it’s best to setup a new user for the API use only
TW Chat API requires HTTP auth to work, but Uptime Robot doesn’t let you set that in the alert properties (UptimeRobot’s alerts are based on Webhooks). At first we thought we’d have to use a separate service domain with the necessary authorization header to make the two talk to one another.
I didn’t like this as the service domain is one more thing to break and one more thing to maintain. We have these SAAS to lower our maintenance burden, not increase it. Worse the Teamwork Chat team suggested we just email our alerts in. Email is clunky and doesn’t give immediate status updates like the direct API, so we didn’t want to do that.
Neither Teamwork Chat support nor UptimeRobot support could give us the solution to marrying the two services so we dug deep ourselves to figure out how to make UptimeRobot talk to Teamwork Chat.
There’s a simple enough solution: you can just include the HTTP auth details in the URL, since the full URL structure goes like this:
protocol://username:password@domain:port/path?query
So in this case it’s:
https://{the user TW desk API key}@{TW domain}/chat/rooms/{room ID}/messages
This helps anybody who needs to use HTTP auth anywhere, like for example here is a direct link to open dev.yoursite.com with HTTP auth right there: https://foliovision:4GDqGfhaRKCrUBZQZn9jxh@dev.yoursite.com
There’s just one caveat. Chrome doesn’t support this advanced URL structure, but it does work with cURL. So including authorisation within the URL is a legacy feature. I’m not sure I’d include credentials this openly in anything which is really high security.
Hacking into our site uptime alerts wouldn’t really give a hacker much joy. It could keep us up one night dealing with the fake alerts but that’s about it. Or if someone did manage to get into one of our dev sites it wouldn’t be the end of the world. The main goal of HTTP auth there is to keep both Google from indexing the dev site and huge crowds out of the dev site. We’re not coding for the NSA or high security corporate intranets these days.
I hope this short essay helps anyone trying to monitor site uptime or pipe any kind of alerts into Teamwork Chat.
So here are the Uptime Robot webook settings we use to be able to get alerts in Teamwork Chat:
- URL – use your callback URL like
https://twp_b...aY_eu@fvaccount.teamworkpm.net/chat/rooms/12345/messages?- notice the?at the end, it has to be put in! - POST value (JSON format) set to:
{"conversationId":"12345", "message": { "body": "*monitorURL* is *alertTypeFriendlyName*" }} - Enable “Send as JSON (application/json)”
Additional notes on RocketChat hosting
If you are considering RocketChat, I’d encourage you to use RocketChat but preferably on your own servers.
When you host with RocketChat themselves, RocketChat does not give an account admin any kind of export/migration or I didn’t like that at all. When we left, we lost all our legacy data. We’re careful though not to let chat become a main work system: too much chat is like an unkept garden with an uncut lawn. The software itself is great and fast and lightweight.
I did find competent hosted RocketChat on an independent host but the hosting provider is also US based.
Any service where you require privacy or confidentiality should not be hosted in the US but by preference in Europe where our privacy laws are considerably stricter. You’ll want to look into the management at the host to see if they are people who treat confidentiality and business agreements seriously. Privacy laws won’t help you if you host your confidential information with bandits or crooks.
The web hosting business has been tough and competitive enough for the last ten years that most of the easy money crowd have long left for greener pastures.
Alec Kinnear
Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.
Leave a Reply