Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-42366

Make sure Sakai LTI Advantage uses Base64 urlDecoder when parsing JWTs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Verified
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 19.3, 20.0 [Tentative]
    • Component/s: BasicLTI
    • Labels:
      None
    • 19 status:
      Resolved
    • Test Plan:
      Hide

      This is a tough one - probable not worth QA testing.  This is how I reproduced the problem myself - just as notes.

      Install a copy of www.py4e.com on my local computer.  Set up LTI Advantage between my local Sakai and local py4e.   Make a site with Announcements.  Click on shopping cart.  In Tsugi go to "Learning Objects" - check 4-5 learning objects and attempt to send them back to Sakai.  Sakai will blow up with a "500" error in the iframe - in the log it will trace back to Base64.decode and complain about "2d" as an illegal character.

      My first test was to not fix the code in LTI13JwtUtil.java and add the try/catch in LTIAdminTool - then run through the test scenario and see a nicer error (SAK-42366-py4e-lots-of-content-items attachment).

      My second test was to actually fix  LTI13JwtUtil.java and run the scenario and have it work.

      Show
      This is a tough one - probable not worth QA testing.  This is how I reproduced the problem myself - just as notes. Install a copy of www.py4e.com  on my local computer.  Set up LTI Advantage between my local Sakai and local py4e.   Make a site with Announcements.  Click on shopping cart.  In Tsugi go to "Learning Objects" - check 4-5 learning objects and attempt to send them back to Sakai.  Sakai will blow up with a "500" error in the iframe - in the log it will trace back to Base64.decode and complain about "2d" as an illegal character. My first test was to not fix the code in LTI13JwtUtil.java and add the try/catch in LTIAdminTool - then run through the test scenario and see a nicer error ( SAK-42366 -py4e-lots-of-content-items attachment). My second test was to actually fix  LTI13JwtUtil.java and run the scenario and have it work.

      Description

      The JWT specification specified that the middle part of the JWT is to be encoded using Base64Url encoding and decoding.

      https://jwt.io/introduction/

      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!

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                csev Charles Severance
                Reporter:
                csev Charles Severance
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Git Source Code