Desktop: Clicking on a file:// does not work for local folders

[maximd]

I confirm (by marking "x" in the [ ] below: [x]):

• [x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
• [x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• [x] I have read contributing guidelines.

---

Summary
Clicking on a file:// does not work for local folders with mattermost desktop 4.1.2 on windows (but it works for UNC paths).

Environment

• Operating System: Windows
• Mattermost Desktop App version: 4.1.2
• Mattermost Server version: X.X.X

Steps to reproduce

Post a message with:

file://C:\

The trailing \ is important (= do not type file://C:) otherwise the : is not interpreted and the autogenerated link becomes file://C/ (which cannot work) instead of file:///C:/ (which is correct).

As another example, type another message with:

file://C:\users

Expected behavior

The windows explorer opens the C:\ or C:\users folder.

FYI it used to work in mattermost desktop 3.4.1 but stopped working in 3.5.0 (like the whole file protocol as described in #579).

Observed behavior

Nothing happens in both examples.

But note that if the path was an UNC path like file://\\servername, everything works correctly (an explorer windows would open at the desired location).

Possible fixes

Something in #712?

[maximd]

Ergh, I just saw in PR #712 that the behavior was here by design :(

https://github.com/mattermost/desktop/blob/7718cf046a8bc15afbdf4ccf2676fad851cc3242/src/browser/components/MattermostView.jsx#L187

@lip-d, as the original pull requester (thanks again for your work, by the way), is there a particular reason why you choosed to prevent loading local paths?

The "problem" is that when you use a network drive (which means a network share mounted with a letter like N: for example), then the file:// protocol fails even if you were in fact trying to access a network resource. And when you are in a team with people used to navigating the network drive with a letter, it is difficult to ask them to use UNC paths only for mattermost links.

Can we consider adding support for local paths?

[yuya-oc]

Thanks @maximd for concrete usecase! I didn't imagine about network drives. In the PR, I had thought:

• Accepting local resources would allow to execute programs via malicious link
• There is no situation where an user would want to share their local files without attached files.

The "problem" is derived from Electron's shell.openExternal() in order to handle file:// URL. However if the purpose is to share local paths, possibly shell.showItemInFolder() would be enough. It's safe if a link refers to an executable file.

[maximd]

Sorry for the late reply! I also think that shell.showItemInFolder() would be the best compromise between usability and security :)

[hmhealey]

We've been discussing this recently, and we've decided that we're going to match browser with these links this instead of inconsistently supporting them for different types of content.