Mattermost-desktop: links to access-restricted resources not well handled

When using mattermost-desktop (the Electron bundled we interface), there’s 2 issues when posting URLs which point to a resource which requires login:

  1. if preview is enabled, it shows a preview of the login form. Instead it shouldn’t show any preview (or just a small message telling it couldn’t access the resource for preview).
  2. when clicking such a link, the browser is in some cases handed a wrong URL. E.g. for a private gitlab instance which redirects all URLs to /users/sign_up when not logged in, all links pointing to that domain are rewritten by Mattermost to open the signup-page - which makes no sense when the browser handling the request is already logged into that site.

The second issue seems may have been recently introduced. I didn’t have it with Mattermost 3.7.1, but have it with 4.0.1 (both running on Linux).
Is there a known workaround to any of this?

@yuya-oc Is this something we should look at for 4.1?

@amy.blais I think no. This depends on how mattermost server gets preview data though, I guess it’s not performed by webapp. I can reproduce the issue on Chrome by posting my private GitLab repository URL.

@d10r Thank you for reporting this, I’ve created a ticket here for our engineers to take a look:

Hi @d10r, our engineers have discussed this and it seems that there is no way for Mattermost to identify whether a redirect is to a login page vs. an ordinary use of a redirect.

I’ll close the Jira ticket that I opened for now, and I’ll ask our engineers if there is any workaround.

Thx Amy.
I propose the following handling:

  1. ad preview: I wrongly assumed the server to signal needed auth via a dedicated http status code (typically 403). But the Mattermost engineers are right, in this redirect scenario that’s not the case. Thus in fact there’s no easy way (I’m aware of) to avoid the preview of the login page.
  2. ad URL handed to the browser: this is imo the bigger problem and should be easy to fix: just hand the browser (or whatever external application the OS decides to invoke) the original URL.

@d10r I’ve opened an improvement ticket for the second suggestion for our team to discuss: