Details
Description
The JWT specification specified that the middle part of the JWT is to be encoded using Base64Url encoding and decoding.
This does not matter until the JWTs get to a certain length and Base64Url begins to break its output into chunks using "-" and newline. This of course freaks out the normal Base 64 decoder. In Sakai, this manifests itself with a awesome traceback complaining about an invalid character "2d" which just so happens to be minus sign.
The simple fix is to use getUrlDecoder() instead of getDecoder() in the code.
Also - add a try / catch in LTIAdminTool to make the error message more user friendly.
I uploaded a video of my successful dev test. I would say this is not worth trying to separately QA.
Ironically this "large JWT" scenario was identified while testing Tsugi with Desire2Learn. Tsugi could send large JWTs to D2L but not to Sakai. After I worked out all the issues with D2L I came back to Sakai - it took a while to figure out the exact problem - but in the end it was pretty simple and obvious. Whew!