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:
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.
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?
@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