Ever since the update, team members using the Mattermost-Desktop app or Chrome browser do not see new messages as they are sent, and need to manually refresh to display new content.
Steps to reproduce
This is an internal Mattermost server, on the local network, configured with Connection Security set to None. Server was migrated from 3.5 to 3.6 without changing the configuration.
Observed behavior
Interestingly, some clients using Edge, Firefox, or the mobile Android app do not have this issue. It seems related to these lines in the server log file:
[2017/01/19 08:33:31 EST] [DEBG] websocket.authTicker: did not authenticate ip=xxx.xxx.xxx.xxx:50090
[2017/01/19 08:33:31 EST] [DEBG] websocket.read: closing websocket for userId= error=read tcp xxx.xxx.xxx.xxx:8065->xxx.xxx.xxx.xxx:50090: use of closed network connection
and these lines in the client console log:
[] websocket connecting to ws://xxx:8065/api/v3/users/websocket
[] method=getFileInfosForPost status=undefined statusCode=undefined err=Error: Request has been terminated
Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.
Can you have the affected users clear their caches and do a hard refresh? It’s possible their browsers are still using the 3.5 version of the webapp and trying to connect to the 3.6 server.
@hmhealey Yes, we tried this (clearing cache and doing a hard refresh) and that didn’t solve the issue. Another test was logging into Mattermost from Chrome a Windows PC that was never logged into Mattermost previously, and we still got the issue there. In the Chrome console we can clearly see the websocket connection stuck in a close-reconnect loop.
Alright, so it’s not an issue with the browser caching. I double checked and it doesn’t look like that code changed much in 3.6 anyway.
Are you seeing any other errors in the server side logs like Invalid session err=ERROR or Invalid session token=TOKEN, err=ERROR? Perhaps you could send me your latest server logs to take a look at? If you sign up to our public instance of Mattermost where I’m @harrison, you can send them directly to me in a DM.
I believe this is also affecting my installation - appears to be related to the fact that I’m running a reverse proxy to mattermost (443 externally to localhost:8065 - something I need to have, as I require multiple SSL sites on this IP, so I’m depending on SNI). I’ve currently only spent about 10 minutes looking at this, but it seems like e4de5837d3e91b5b988fa749373683b7f849acf3 is the culprit.
Honestly though, I don’t know enough about websocket security to submit a patch for this one.
Edit: It’s just occured to me that the host header probably isn’t being preserved on my setup, which maybe is what’s causing the problem. I’ll check tomorrow when I get back to work and update accordingly.
Edit 2: Went back to work. Yeah it’s just the fact I wasn’t sending back the original host header. Since I’ve done that it’s resolved the problem.
It turns out that clearing the ‘Site URL’ field in the server configuration fixed the issue (but of course this disabled batch notifications), even though this URL was properly formed.