Plugin does not always load up bigbluebutton (http 405)

[Imkerix]

We believe to have found a problem with the loading of the plugin in Mattermost, but first some stats of our setup:

Setup

Host 1:
  Mattermost:
    Version: 5.28.1
    Mattermost is running inside Docker behind an apache2 reverseproxy.
  BBB Plugin:
    Version: 2.2.0
    Installed via upload inside the Mattermost webapp.

Host 2:
  Version: Ubuntu 16.04.6 LTS
  BigBlueButton:
    Version: 2.2.0
    Greenlight version: 2.5.5
    BigBlueButton is reachable behind an apache2 reverseproxy.

Description

We started to take a more in depth look because we have somewhat of a slack joint failure here. It appears that if you connect to our big blue button setup first and open up Mattermost afterwards everything works perfectly well, but if you open Mattermost first and try to access BigBlueButton over the plugin all you get is a blank new tab page and an http 405 error in the Mattermost tab.

Since everything works fine if the browser was connected to BigBlueButton first, I do not believe this to be a connectivity issue between Mattermost and BigBlueButton. This must have to do with the client or rather with the xhr call of the plugin to load up BigBlueButton.

Next we tried to get behind the meaning of the http 405 error we had found in the browsers debug console, and found that all connections from the Mattermost installation to the BigBlueButton server appeared to suffer from this issue. All calls to "ismeetingrunning" fail with the same error, if BigBlueButton was not open prior to Mattermost.

Error example ismeetingrunning

Failed to load resource: the server responded with a status of 405 (Method Not Allowed) https://Mattermost.example.com/ourteam/channels/undefined/plugins/BigBlueButton/ismeetingrunning

Error example attempt to join

POST https://Mattermost.example.com/ourteam/channels/undefined/plugins/BigBlueButton/joinmeeting 405 (Method Not Allowed)

Sadly we didn't find anything useful in the logs of our Mattermost container or the apache/nginx logs on both sides that belongs to these problems. Only the 405 errors are visible on the nginx server as well but with no more details.

However while trying around I found one more thing that was interesting to me: If I open Mattermost first, disable the BBB Plugin and re enable it everything works for the session as if I would have opened BigBlueButton first. At this point I came to the conclusion that something in the loading of the plugin might be wrong, but since I neither know javascript nor go well I am out of knowledge to debug deeper at this point.

PS: I noticed that both http POST request try to reach a mattermost channel "undefined". This seems to be done when the real name of the channel cannot be determined and might be a totally different problem, but in case it has anything to do with the problem I wanted to mention it.

PPS: We tried this with different browsers and with disabled addons, to make sure no script blocking is intervening with this problem.

Thank you all for any tipps on this ;)

[harshilsharma63]

@Imkerix thanks for reporting the issue.

The URL you mentioned for ismeetingrunning doesn't look correct. It should be like this - https://mattermost.example.com/plugins/bigbluebutton/ismeetingrunning. Specifically, it is <Mattermost site URL>/plugins/bigbluebutton/ismeetingrunning.

Can you please verify if your Mattermost site URL is configured correctly?

[Imkerix]

Hello @harshilsharma63, thanks for looking into this!

Our siteurl is currently set to https://mattermost.example.com which is the same URL we use to access Mattermost behind it´s Apache2 Reverseproxy mentioned above. While debugging I got the feeling, that the ismeetingrunning URL tries to represent the channel which contains the Meeting Post /bbb... Is that a wrong assumption and there should be only one ismeetingrunning URL for the whole Mattermost Server?

I will look around a bit and try to figure out why we get the ismeetingrunning URL we get at the moment. Perhaps the error to the rest of this issue is down the same path.

[Imkerix]

Here is an update from me.

While I didn't find a solution, I have found more clues to share. You were quite right. The base problem appears to be, that some sessions just don't load the right siteURL in time and end up having undefined as SiteURL. Everything else that follows seems to happen because of this. I worked myself down to this statement:

var siteURL = store.getState().entities.general.config.SiteURL;

strangely enough siteURL ends up with undefined if I set my brakepoint after this line, but everything works fine if I set the brakepoint on the line and then step over it. This leads me to guess there is some sort of timeout issue underneath.

[harshilsharma63]

@Imkerix this issue is fixed in v3.0.0 release. Please upgrade to the latest release and let us know if you still face this.

[Imkerix]

@harshilsharma63 Today we have installed Version 3.0.0 and can confirm that our issue is fixed.

Thank you very much for your time and effort in working on this extension :+1:

[harshilsharma63]

@Imkerix hurray!