Checksum error with spaces

[sualko]

I have a user which is reporting checksum errors if he is using spaces. It seams his installation does not like RFC3986 encoding introduced in https://github.com/littleredbutton/bigbluebutton-api-php/commit/8fbdc1dff2c9d6454932e2891792e6da0de9d260. If he changes it back to RFC1738, everything works fine. Can someone reproduce this, or explain it?

[sualko]

It seams BigBlueButton is reencoding the url while removing the checksum from the query string, see https://github.com/bigbluebutton/bigbluebutton/blob/8cf5b64a0feeb6da04c6a3eb0dc03cc93c4022dd/bbb-common-web/src/main/java/org/bigbluebutton/api/model/shared/GetChecksum.java#L36. Therefore they are using the RFC1738 encoding to calculate the checksum. The only mystery is why this is not failing on every server.

[sualko]

Sorry that you get so many mails from me :-)

It seams it's a bit of a false alarm. The change was introduced with the upcoming 2.4 line and therefore the user is probably a beta tester :see_no_evil:.

Just for the recording, BBB 2.3 is using a more stable verification step: https://github.com/bigbluebutton/bigbluebutton/blob/c8577dd76d21197374bef2490eceb027e9327e2e/bbb-common-web/src/main/java/org/bigbluebutton/api/ParamsProcessorUtil.java#L801

I leave this issue open, because it's something we have to look into if 2.4 gets released.

[sualko]

As you can see, BBB has fixed the issue, but the user is reporting that he is still using BBB 2.2. So what do you thing? Do we have to revert back to RFC1738? Can someone reproduce this?

[SamuelWei]

I haven't experienced any problems with the new encoding. Could the user provide us with the data he used to call the api. What api call (create, join, etc.)? What are the parameters? Could the user write a test that fails?

[sualko]

Here is the url which results in a checksum error. I only changed the domain names.

https://bbb.foobar.link/company/bigbluebutton/api/create?name=Test1&meetingID=zok78HrZb8bFkzcj&attendeePW=AP8DEZ3qonoPrp3zPHtgLbCZfMr5DedF&moderatorPW=9wCiYSojXzNisJfJxexgHMQc9dN3JRqC&logoutURL=https%3A%2F%2Fcloud.company.de&record=false&moderatorOnlyMessage=Um%20jemanden%20zu%20dem%20Termin%20einzuladen%2C%20schicken%20Sie%20ihm%20diesen%20Link%3A%20https%3A%2F%2Fcloud.company.de%2Findex.php%2Fapps%2Fbbb%2Fb%2Fzok78HrZb8bFkzcj&allowStartStopRecording=false&guestPolicy=ALWAYS_ACCEPT&meta_endCallbackUrl=https%3A%2F%2Fcloud.company.de%2Findex.php%2Fapps%2Fbbb%2Fhook%2Fended%2Fzok78HrZb8bFkzcj%2FpHLUIdkipSCRI0WehdvAkUzOGCI&meta_bbb-recording-ready-url=https%3A%2F%2Fcloud.company.de%2Findex.php%2Fapps%2Fbbb%2Fhook%2Frecording%2Fzok78HrZb8bFkzcj%2FpHLUIdkipSCRI0WehdvAkUzOGCI&checksum=d67760999471fd5378a22c4dcc399332bcf0e8e8

The user also created a test script:

use BigBlueButton\Parameters\CreateMeetingParameters;

$createMeetingParams = new CreateMeetingParameters("123", "Raum1");
$createMeetingParams->setAttendeePW("pw1");
$createMeetingParams->setModeratorPW("pw2");
$createMeetingParams->setModeratorOnlyMessage("Das ist eine Meldung");

$url = $bbb->getCreateMeetingUrl($createMeetingParams);

echo "URL: <a href='$url'>$url</a>";

The resulting url will produce a checksum error with the current version of this library. If he changes http_build_query to use RFC1738 everything works fine. The user is reporting that there are no related errors on the bbb server.

[FelixJacobi]

Hm, interesting. According to the change to fix https://github.com/bigbluebutton/bigbluebutton/issues/12919 the old method which was restored there to receive the query string without the checksum looked very straight and not depended on the method used to encode the parameters.

What I would do here:

• Use the given parameters to create a new functional test case.
• Check if this really still failing with BBB 2.3 (in the meanwhile, we upgraded all our BBB instances to 2.3, so I currently do not have access to an instance still running BBB 2.2), if yes, try to figure what exactly changed in BBB between these versions and define further steps.
• A last option would be to revert to RFC 1738, but this is not compatible with the Symfony HTTP client integration as in contrast RFC 3986 is hard-coded there :/ : https://github.com/symfony/symfony/blob/76a414c7d8ad03b5d6e520edfd8b947af21717b0/src/Symfony/Component/HttpClient/HttpClientTrait.php#L573 - if we must choose this way, I would probably offer an option in the library to set which encoding to use and would investigate if Symfony would accept adding an option for RFC 1738 in HTTP client.

[sualko]

I currently do not have access to an instance still running BBB 2.2

I have access to a 2.2 version and I can't reproduce it either. So I guess we leave this open until we get more information.

[SamuelWei]

@sualko As is issue is one year old, should we close it as stale?