Description
Get onError callback 7 when using certain tpc/sessionNames
Customizable Desktop SDK v.1.0.1
To Reproduce
Try authenticating into a session on Android Instant Zoom SDK through the normal process (audio on, video off), except use string “03/16/21_” as the tpc/sessionName.
Get (only) onError callback with code 7 despite Initialize & JoinSesssion reporting success
Additional Info
Simply changing tpc/sessionName to “_Default” works as expected (no errors, all proper callbacks.)
Adding the two special characters “/" to my userName field (ie "Username/” with tpc="_Default") give no issues, so it isn’t something with strings generally.
Replacing “/” with “_” fixes it, so it seems “/” is a special char for the tpc/sessionName field for Android Instant Zoom SDK?
Can someone confirm that it’s a bug with the SDK and not something I’m doing wrong? FYI I am using the exact same string for both JWT’s tpc field and JoinSession’s sessionName argument.
Hi @hung, thanks for bringing this to our attention.
I believe this has to do with how the JWT is encoding the / character. We will investigate this and let you know once we have more information. It’s either a bug, or we have a lapse in our documentation surrounding the requirements for a session’s tpc value. Either way, we apologize for the inconvenience and will be sure to give you an update ASAP.
Thanks for the reply. I forgot to mention, but the exact same setup works with the Windows Instant SDK (with `tpc=“03/16/21_”), so the issue could be platform-specific (I did not/cannot test on other platforms’ SDKs.)
Thanks for the additional information. This has been consistent with our internal findings, so this is really a matter of determining which platform is doing things correctly.
It turns out that this is actually not a bug with the SDK and you can properly use / characters in your tpc value. If you are using the JWTUtil class, when encoding the payload, the Base64.URL_SAFE flag is replacing / with _. Removing this flag from the encodeToString call will resolve the issue.
Hi, thanks for the feedback! That might be part of the problem-- but I am generating my JWT token from the same source for both Windows and Android, and not using (as far as I can tell) the JWTUtil class.
I also remember checking the tokens generated by both Android & Windows, and they were correct. I verified with a generic base64encoder to confirm:
You can use this (https://www.base64encode.org/) to see that the string 03/16/21_ encode/decodes correctly with no loss of data (even with “safe” checked), since the replace happens after encoding and before decoding (here’s the exact implementation of the encoder I’m using.)
Happy to be proven wrong, but my guess is that there’s still a bug in how tpc is parsed on Android.
Thank you for the additional information. After generating the JWT in jwt.io, I was able to reproduce this issue, confirming your suspicions. We will let you know as soon as we have any updates around this investigation.
After looking into this internally, we have determined that the behavior on Android is correct. We are working on updating the logic on our other platforms to match this and will update our documentation as well.
