Mattermost Delete Channel "fixed"

Users of Mattermost have probably noticed the less-than-optimal interface design where de Delete option is right above the Leave option in the Channel menu. On a busy server, you can imagine having quite a few incidents where people accidentally completely delete a channel.

In the Open Source version of Mattermost, everybody van do anything, because there is no sensible security model with roles. Mattermost Inc. seems to think that the Open Source community is not entitled to roles, which I (and others with me) strongly disagree with.

Forking Mattermost, learning Golang and enabeling security, improving a few other issues for the open source community along the way is a plan. But there is a simpler workaround for people running Mattermost inside Nginx.

[sourcecode language="text" highlight="15-18, 20-50" padlinenumbers="false" gutter="false"] location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_pass http://127.0.0.1:8065;

if ($request_method = DELETE) {
   return 403;
   break;
}

} location ~ /api/v[0-9]+/channels/[\d\w]*$ { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_pass http://127.0.0.1:8065;

# See https://stackoverflow.com/questions/4833238/nginx-conf-redirect-multiple-conditions#4939522
if ($request_method = DELETE) {
    set $block_delete 1;
}
# Allow deletes originatig from this ip address.
if ($remote_addr = 44.137.37.17) {
    set $block_delete 0;
}
if ($block_delete = 1) {
    return 403;
    break;
}

} location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_pass http://127.0.0.1:8065; } [/sourcecode]

Restart nginx with the command "service nginx restart". After this modification, nobody can delete a channel. Crude but effective. If you have tips on how to parse the headers with nginx to allow certain users to access the DELETE methods, please let me know.

Background: We run a chat server for (mostly Dutch) licensed HAM radio operators on our own 44.x.x.x network segment of the internet also known in the Netherlands as "hamnet". We wanted a modern chat service with mobile applications to spice up the HAM radio world, ping eachother on field days, share thoughts and links to information, and enable colaboration for the growing number HAM radio programmers working on open source software.

The server is paid for and run by people who care about sharing. Although Mattermost is not our focus area, we do try to contribute to Mattermost with bug reports, fixes and running the beta chat clients. Our usergroup is almost 500 people, and growing. Depending on events or contests roughly 20% of our users are actively reading and contributing to one or more channels:

From where we are standing, with the open source tools we use, Mattermost looks like an odd duck. Most of the open source tools we use and contribute to have common-sense safety and security built in, Linux, nginx, haproxy and letsencrypt  being a few strong examples. In contrast, the Mattermost team cripples the Open Source version with weak passwords and no implementation of even the most basic security roles. For a tool which pretends to be mature and safe enough to be exposed to the Internet, the workaround as described in this blogpost should not be needed.

Please help us convince the Mattermost Team of the importance of security in all versions of their products. Making money with support and features is okay, but basic common sense security should be the default for any open source project. We even think that improving security and speed makes Mattermost a more viable competitor against Slack and Telegram, to name two.

Open Source is about sharing, not about farting in the general direction of the very people contributing to it.