Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-65536

LTI 1.3 post-landing issues

    XMLWordPrintable

    Details

    • Testing Instructions:
      Hide

      Testing the bug fix for the stale platformid:

      1. Log into Moodle as System Administrator
      2. Go to Site administration / Plugins / Activity modules / External tool / Manage tools
      3. Manually configure a tool:
        • Enter any name for the tool
        • set LTI version to 1.3
        • Set the tool url to any valid URL, it doesn't need to be a valid tool nor suite URL (https://moodle.org/ will work fine here).
      4. Save the tool
      5. Now from the tool card (Listed below under the heading "Tools"), click the list icon to view the configuration details for the tool.
      6. Verify the 'platformid' field contains localhost
      7. **Now, make your site publicly available, via something like ngrok (make sure to set $CFG->sslproxy if using https), updating the $CFG->wwwroot to the new public URL.
      8. Now, run steps 4 again, and Verify the platformid contains the ngrok (or relevant) URL and not localhost.

      Testing the misconfigured openssl fix (can be run on linux/mac, doesn't require windows):

      Fresh install:

      1. Checkout a new integration master, but don't install.
      2. Edit mod/lti/upgradelib.php and change OPENSSL_KEYTYPE_RSA to 42
      3. Run through install and observe the warning during upgrade (check both CLI and web install to make sure they both work)

      Upgrade:

      1. Checkout a 36 Moodle and install
      2. Now, checkout integration master, but don't upgrade yet.
      3. Edit mod/lti/upgradelib.php and change OPENSSL_KEYTYPE_RSA to 42
      4. Run upgrade and observe the warning during upgrade (check both CLI and web upgrade to make sure they both work)

      Now, on either of the prior installed or upgraded sites:

      1. As an instructor create a new External Tool
      2. Click the + icon next to the "Preconfigured Tool" field.
      3. Fill all the fields with any value - but make sure the "LTI Version" field is set to "LTI 1.3"
      4. Verify you see an error next to the LTI version field. "LTI 1.3 requires a valid openssl.cnf to be configured and available to your web server. Please contact the site administrator to configure and enable openssl for this site."

      Testing the JWT autoloading change:

      1. CIBot will cover this change. Nothing required of you.
      Show
      Testing the bug fix for the stale platformid: Log into Moodle as System Administrator Go to Site administration / Plugins / Activity modules / External tool / Manage tools Manually configure a tool: Enter any name for the tool set LTI version to 1.3 Set the tool url to any valid URL, it doesn't need to be a valid tool nor suite URL ( https://moodle.org/  will work fine here). Save the tool Now from the tool card (Listed below under the heading "Tools"), click the list icon to view the configuration details for the tool. Verify the 'platformid' field contains localhost **Now, make your site publicly available, via something like ngrok (make sure to set $CFG->sslproxy if using https), updating the $CFG->wwwroot to the new public URL. Now, run steps 4 again, and Verify the platformid contains the ngrok (or relevant) URL and not localhost. Testing the misconfigured openssl fix (can be run on linux/mac, doesn't require windows): Fresh install : Checkout a new integration master, but don't install. Edit mod/lti/upgradelib.php and change OPENSSL_KEYTYPE_RSA to 42 Run through install and observe the warning during upgrade (check both CLI and web install to make sure they both work) Upgrade : Checkout a 36 Moodle and install Now, checkout integration master, but don't upgrade yet. Edit mod/lti/upgradelib.php and change OPENSSL_KEYTYPE_RSA to 42 Run upgrade and observe the warning during upgrade (check both CLI and web upgrade to make sure they both work) Now, on either of the prior installed or upgraded sites: As an instructor create a new External Tool Click the + icon next to the "Preconfigured Tool" field. Fill all the fields with any value - but make sure the "LTI Version" field is set to "LTI 1.3" Verify you see an error next to the LTI version field. "LTI 1.3 requires a valid openssl.cnf to be configured and available to your web server. Please contact the site administrator to configure and enable openssl for this site." Testing the JWT autoloading change: CIBot will cover this change. Nothing required of you.
    • Affected Branches:
      MOODLE_37_STABLE
    • Fixed Branches:
      MOODLE_37_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-65536-master

      Description

      This is a followup of MDL-62599 where any detected and remaining issues should be fixed before Moodle 3.7 release (20th May 2019).

      With the code already available upstream we should be able to advance here at good pace.

      Specifically, let's pay attention to the results gathered from the testing session started in the original issue.

      Ciao

      Specifically, the items which need to be resolved ASAP:

      1. No connectivity whatsoever to the LTI 1.3 test suite on a fresh install - OIDC error invalid request when opening the tool. A site upgrading from 3.6 worked, so I suspect something was missed in the install code. EDIT: See the cause in my comment below.

      2. Windows install with improperly configured openssl. The code:

      $res = openssl_pkey_new($config);
      openssl_pkey_export($res, $privatekey);

      will result in $res  being false, and then a warning will be thrown for the second line as 'false' isn't valid for $res. Configuring fixes this, but given we don't detect this, we'll end up with a missing private key and broken 1.3 support. This code is run during upgrade and install. We discussed disabling the module if the configuration is known to be in error, but the specifics are yet to be determined on this. I welcome any input.

      3. Testing errors (from LTI 1.1 and LTI 2 external test suites), as reported on MDL-62599. Need to test 3.6 and see whether these same failures were present. If so, disregard. 

      4. Firebase\JWT\JWT should be class autoloadable and not be required.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  20/May/19

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 day, 51 minutes
                  1d 51m