Looking for an example of how to ingest an LTI request and then pass it onto another location. This will be a very common use-case for those using Drupal / LTI from a traditional LMS. Instead of launching against each tool individually, you'll want to launch against 1 site, and then have that site pass the user seamlessly onto their final location based on initial request.

Example: Form a link to say something like servicesite.address/lti/studiotools which passes the LTI request from servicesite.address/lti over to studiotools.servicesite.address. This would allow for lti/{thingyouwant} to be all the link difference is in the originating LMS tool.

While you could launch against each service individually, I think a mix of use-cases will be common place in the coming year(s). As such... if anyone has an example of doing this please let me know. Otherwise I'll probably have one by the end of the day :)

Comments

jzornig’s picture

jzornig commented

Typically each tool is registered with the LMS separately. This allows the Instructor/Course Designer to embed links to tools into a course by selecting from a list of available tools.

In the case of a multi-tool, which has a single registration but implements two or more discrete but possibly related tools, you may want some way of deep-linking from the LMS into the multi-tool so that the users don't have to do unnecessary navigation. We do this with the custom destination parameter.

If you want to build a multi-tool gateway which is just an LTI/OAuth endpoint that hands off or redirects to a collection of independent tools that don't support LTI (i.e. different drupal sites). You could use a custom parameter as a way of indicating the requested tool. However you still have the problem of authentication/authorization for the independent tools. You can't redirect the OAuth which underlies LTI because it must be within a https connection. So you must have another mechanism for connecting the independent tools to the gateway. This means implementing some form of Single-Sign-On (SSO) between the gateway and tools. There is also the problem with getting data such as grades or memberships between the LMS and these tools that don't have LTI. You would have to build secure protocols between the tools and the gateway for this as well.

You may as well just make each tool do LTI and do away with the gateway.

Having the list of tools available in a menu or select list in the LMS is the best experience for both the course builder and user.
- each LTI link in the LMS leads to the required tool directly.

A multi-tool which requires either:
- the user to navigate from the multi-tool landing page to the required tool (the user must have some contextual info that tells them which tool to pick), or
- the course designer to add a custom destination parameter to each multi-tool link

btopro’s picture

btopro commented

gateway is required for the way that this functions. Sites are setup automatically by the gateway and I'd like to remove setup entirely. A Gateway will eventually allow our LMS to send data to automatically create mirrored spaces in Drupal which automatically setup all services for the course, external to the LMS. LTI passes them to the right place based on the context of the initial request but the gateway will always have to look up and reroute the bounce.

I got this working by modifying your code to pass back the request for the grade service:

/**
 * Resign an LTI request and silently launch it against a service.
 *
 * @param string $params
 *   An array containing the POST data, eg, lti_message_type etc.
 * @param string $key
 *   The consumer key.
 * @param string $url
 *   URL of the LTI service.
 *
 * @return string
 *   HTTP response.
 */
function cis_lti_service_post($params, $key, $url) {
  $ext_response = NULL;
  if (!empty($url)) {
    $params['oauth_consumer_key'] = $key;
    $oauth_consumer_key = $key;
    $store = new LTIToolProviderOAuthDataStore();
    $consumer = $store->lookup_consumer($oauth_consumer_key);
    $token = '';
    $hmac_method = new OAuthSignatureMethod_HMAC_SHA1();
    $request = OAuthRequest::from_consumer_and_token($consumer, $token, 'POST', $url, $params);
    $request->sign_request($hmac_method, $consumer, $token);
    $params = $request->get_parameters();
    // Connect to tool consumer.
    // http_build_query($params).
    $options = array(
      'data' => http_build_query($params),
      'method' => 'POST',
      'max_redirects' => 5,
      'headers' => array('Content-Type' => 'application/x-www-form-urlencoded'),
    );
    $ext_response = drupal_http_request($url, $options);
  }
  return $ext_response;
}
jzornig’s picture

jzornig commented
Category: support » feature

Brian, you have an interesting use case. I just watched the video you posted. It might eventually be worthwhile creating an LTI Tool Provider Proxy module that proxies both the outgoing launch and the returning outcomes/memberships service requests. I suggest reading up on the link provisioning features of LTI 2. This might tie in with that when we add LTI 2 support. I'll leave this open as a feature request, so that people can discuss the idea of LTI proxy/routing.

btopro’s picture

btopro commented

That makes sense. Currently I'm just using the available after launch alter hook to invoke the function above. Agreed this should stay open to encourage discussion.

As for the link you mentioned: https://drupal.psu.edu/content/learning-tools-interoperability-drupal

Might be worth adding it to the presentations section on the project page as I think without seeing this module in action most people's initial impression of an IMS technology is SCORM and this is significantly easier to understand and implement.

jzornig’s picture

jzornig commented

Thanks btpro. I've added the link to the presentations section.

btopro’s picture

btopro commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.