Mattermost, Inc.

Unable to open links on same host as mattermost in client

Summary

Unable to open links to sites on same host as the mattermost server.

Steps to reproduce

Mattermost desktop version: 4.4.0 Windows 10.

This text will be hiddenA link is pasted in the chat that is on the same host (foo . bar . com) (added spaces around parts since I cannot have more than two links as a new user, making it really difficult to write a troubleshoot message) as mattermost, but in a different folder (Mattermost is in /mm on my setup, and the links I cannot access are for instance in /cr). When I press the link nothing happens and the console message shown in observed behavior is displayed in “Developer tools for Application Wrapper”.

Expected behavior

The link is opened in my default browser.

Observed behavior

My setup is somewhat similar to this: Mattermost is on: https :// foo . bar . com / mm and I have a code review site on foo . bar . com / cr when I receive links to the code review site, I am unable to open it, and get the following message in the console:

[09:05:57.130] https://foo.bar.com/cr/#/c/c2/something/+/12063/ is a known team, preventing to open a new window

Links to external sites like youtube works just fine. It has worked in a previous version (before 4.3.2 I think), it works for my colleague running 4.2.1. In my previous version it opened the links, but in an internal mattermost window and not my default browser. My colleagues version works as expected. So I guess the problem is introduced between version 4.2.1 and 4.3.2 and worsened in 4.4.0.

What Mattermost server version are you on?

Mattermost Version: 5.10.0
Database Schema Version: 5.10.0
Database: postgres

Would you be able to check if you can reproduce this on a more recent version? Our most recent version is v5.22.

Hi Amy

I am not the administrator of the server, and do not have access to upgrading it. But it seems strange that this should be a server related issue, since colleagues on the same server, but with an older version of the desktop client, do not have the problem. Are you sure it can be a server related problem?

Do you have public servers that I can join and test it on?

@deanwhillier Would you have more knowledge on this issue?

@amy.blais & @TommyA, I don’t know if this behaviour has changed in v5.22, but the issue here is one of subpath support. The default behaviour of the server is to assume full control of the domain, unless the SiteURL is configured with a non-empty path component. It’s possible that the desktop app isn’t taking the configured subpath into account when deciding which links are “internal” or “external”. If we can reproduce, this is a bug in the desktop app to address.

Agreed @jesse, I believe the issue here is related to the subpath. @TommyA, for security reasons, the decision was made between 4.2 and 4.3, with refinements in subsequent versions, to be stricter when handling links in the Desktop app. Part of this includes determining whether a link is internal to MM or external. Internal links are just loaded in the main window to allow regular navigation in MM to occur, while the decision was made to pretty much open all other links in the OS’s default application for a given link (usually a browser). I suspect your scenario is falling between the cracks.

Appreciate the feedback! We will create a ticket to investigate this scenario on our end, stay tuned!

if you prefix your url with /plugins/ it works than…actually I have plugin which is making redirection further…But I don’t want to have /plugins/ in my url in order to make it work

Just checked source code…

const nonTeamUrlPaths = [‘plugins’, ‘signup’, ‘login’, ‘admin’, ‘channel’, ‘post’, ‘api’, ‘oauth’];

Maybe consider adding /ext or /external or /url in this list