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

Implied capabilities not applied when parsing custom parameters

    XMLWordPrintable

    Details

    • Testing Instructions:
      Hide
      1. Configure an LTI tool registration for http://lti.tools/test/tp.php, offer it all capabilities and all services
      2. Register the new tool but select only the "basic-lti-launch-request" capability, the "ToolProxy.custom.url" substitution variable and all services
      3. Enable the Test tool provider tool configured by the tool proxy received
      4. Goto a course as a teacher and add an instance of this tool including a custom parameter of "demo=$ToolProxy.custom.url"
      5. Launch the tool and notice that the parameters include "custom_demo=$ToolProxy.custom.url" - the variable has not been substituted.
      6. Update Moodle with the new code and re-launch to see that the value is now substituted.
      Show
      Configure an LTI tool registration for http://lti.tools/test/tp.php , offer it all capabilities and all services Register the new tool but select only the "basic-lti-launch-request" capability, the "ToolProxy.custom.url" substitution variable and all services Enable the Test tool provider tool configured by the tool proxy received Goto a course as a teacher and add an instance of this tool including a custom parameter of "demo=$ToolProxy.custom.url" Launch the tool and notice that the parameters include "custom_demo=$ToolProxy.custom.url" - the variable has not been substituted. Update Moodle with the new code and re-launch to see that the value is now substituted.
    • Workaround:
      Hide

      None

      Show
      None
    • Affected Branches:
      MOODLE_28_STABLE, MOODLE_29_STABLE, MOODLE_30_STABLE
    • Fixed Branches:
      MOODLE_28_STABLE, MOODLE_29_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-49185-master

      Description

      An LTI 2 tool proxy declared enabled capabilities which generate their associated parameter when a launch occurs. However, variable parameters should also be used as implicit capabilities; just ones which are passed in custom parameters rather than an existing LTI 1 parameter. These implicit capabilities are not being included when parsing a custom parameter to check for supported substitution variables to be translated into their representative value.

      So, for example, a tool proxy which includes the following parameter for a message with a type of "basic-lti-launch-request":

      { "name" : "username", "variable" : "User.username" }

      which is launched from a link which adds a custom parameter of:
      loginname=$User.username
      will not have the value of the custom loginname parameter substituted because the capability was not included in the enabled_capability section of the tool proxy. The code should check both this section and the variable parameters for a complete list of enabled capabilities and hence, in this example, the loginname parameter should have had its value substituted because the capability is supported implicitly.

      This only affects 2.8+.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  14/Sep/15