Page Comparison

...

The Tomcat RequestDumperValve is another option for getting at the original request in a less processed format, although it can have side-effects which may disrupt the LTI message authentication process.

Moodle Isn't Sending the Launch Parameters I Need

OOTB, Moodle's LTI Tool Consumer does not send a value SSP can use as either a username or a schoolId. Workarounds:

Use Email Address Instead - Moodle does send a lis_person_contact_email_primary launch parameter which can be used to look up Platform accounts, assuming values in that field uniquely identify users in your SSP deployment. To this end, starting with SSP 2.5.3 and 2.6.0, SSP's Tool Consumer configuration UI allows you to set primaryEmailAddress in the 'SSP User Attribute' field. Use that value whenever setting 'Lti User Id Field' to lis_person_contact_email_primary. Also, if you've configured SSP Platform to source user attributes from either a custom database table or AD/LDAP, you'll likely need to add an entry to the <queryAttributeMapping> element in <platform-src>uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml: <entry key="primaryEmailAddress" value="{physical-mail-attribute-name}"/>. The local default uPortal DAO now includes that configuration for locally provisioned Platform accounts. Specifically:

No Format
<entry key="primaryEmailAddress" value="mail"/>

The correct value for physical-mail-attribute-name will depend on the details of the external attribute source with which you are integrating and may be different for each DAO. If you are currently mapping a logical attribute named primaryEmailAddress on the "value-side" of a DAO's <resultAttributeMapping> property, you should use the "key-side" of that mapping as {physical-mail-attribute-name} (this is exactly how the local default uPortal DAO is currently configured). I.e.

No Format

<property name="queryAttributeMapping">
  <map>
    <!-- snip -->
    <entry key="primaryEmailAddress" value="mail"/>
    <!-- snip -->
  </map>
</property>
<property name="resultAttributeMapping">
  <map>  
  <!-- snip -->
  <entry key="mail">
    <set>
      <value>primaryEmailAddress</value>
    </set>
  </entry>
  <!-- snip -->
  </map>
</property>

Modify Moodle Source - To include a username in LTI launch params, edit moodle/mod/lti/locallib.php or moodle/mod/basiclti/locallib.php to add a line like $requestparams['lis_person_username'] = $USER->username; E.g. the end result should resemble:

No Format

$requestparams['lis_person_name_given'] =  $USER->firstname;
$requestparams['lis_person_name_family'] =  $USER->lastname;
$requestparams['lis_person_name_full'] =  $USER->firstname." ".$USER->lastname;
// Next line added to export the current user's username as a LTI launch param
$requestparams['lis_person_username'] =  $USER->username;

Similar code changes may be feasible to include a schoolId parameter, but the details depend on where/how exactly your Moodle instance stores that value.

OOTB, Moodle also does not necessarily send a LTI launch parameter that maps to SSP section_code in an obvious way. In some deployments the context_label launch parameter serves this purpose, but whether or not that field has the necessary semantics is very deployment-specific. Some trial and error may be necessary. If no OOTB-supported launch parameters can be correctly mapped to section_code, a Moodle code patch similar to that proposed above for username may be necessary.

Versions Compared

Old Version 17

New Version 18

Key