Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
3.1.12, 3.1.13, 3.1.14, 3.2.9, 3.3.6, 3.3.7, 3.3.8, 3.4.3, 3.4.4, 3.4.5, 3.5, 3.5.1, 3.5.2
-
2.2
-
MOODLE_31_STABLE, MOODLE_32_STABLE, MOODLE_33_STABLE, MOODLE_34_STABLE, MOODLE_35_STABLE
Description
This may happen when there are two (or more) instances of moodle running in the same hostname but in different directories. Even though courseid and groupid is used for disambiguation, ther may be cases where courseid also clashes.
The encoded meetingid used as a seed for each meeting created in BBB is based on this:
sha1($CFG->wwwroot . $seed . \mod_bigbluebuttonbn\locallib\config::get('shared_secret'));
So, lets say the moodle instance1 is in http://mymoodle.com/moodle1 and the instance2 is in http://mymoodle.com/moodle2. And both have a course with courseid = 1 lets say, English 101 in the first and Development 101 in the second, and you added as the first activity a BigBlueButtonBN instance to both of them so bigbluebuttonbn = 1 for both.
The seed for meetingid in both instances would end up being sha1("mymoodle.com1THESECRET").
When creating the meeting the BBB external meetingid looks like this 5f1002e4becd1a4adc07af515325ed44-1-1 or like this if groups were enabled like this 5f1002e4becd1a4adc07af515325ed44-1-1[1,2...n] for both instances, so even though the courseid is used to reduce the chances of a clash, it may happen.
This is a legacy code due the way the meetingid was recreated before (long long time ago), but it is not the case anymore, the solution would be to make the meetingid seed unique with random numbers.