XHR request to /me returns 204 no content using LTI 1.1

[porcospino]

Bug

Using Moodle 3.5.10+, which only supports LTI 1.0/1.1

As a Moodle administrator, follow the CONFIGURATION_GUIDE.md.

As a Moodle "Teacher" in a course, follow instructions in the USER_GUIDE.md

I get to step 7 and expect to see something similar to the screenshot. Instead I see a message saying "Loading assignment"

Developer Tools reveals the XHR request to https://users-xxxxxxxxx.azurewebsites.net/api/assignments/XXXXXX==_XXXXXX=/me returns 204 No Content

The Moodle "Teacher" account has an email address matching both the "mail" and "User Principal Name" values in Azure Active Directory

Desktop:

• OS: Ubuntu 20.04.1 LTS
• Browsers: Chromium Version 85.0.4183.83 and Firefox 80.0.1

[adbindal]

Thanks @porcospino for taking time to debug the issue with us today. I am summarizing the issue below: -

• It seems like the Learn-LTI Tool is making a ContextMembership API call to LMS (i.e. Moodle here) using the OAuth1 for passed in Key+Secret pair.
• In this case, LMS is returning unauthorized for the request and which in turn ends up causing an http204 for /api/assignments/{assignment_id}/me call.
  • We'll be eagerly waiting to hear back on your investigations around the LMS to understand probably why it is functioning this way and would love to take this issue to closure afterwards.

Thanks again for working with us on this issue.

[porcospino]

Hi @adbindal

My tests so far indicate it is failing at line 292 of /mod/lti/classes/local/ltiservice/service_base.php in Moodle (3.5)

    280     /**
    281      * Check that the request has been properly signed.
    282      *
    283      * @param int $typeid The tool id
    284      * @param int $courseid The course we are at
    285      * @param string $body Request body (null if none)
    286      *
    287      * @return bool
    288      */
    289     public function check_type($typeid, $courseid, $body = null) {
    290         $ok = false;
    291         $tool = null;
    292         $consumerkey = lti\get_oauth_key_from_headers();
    293         if (empty($typeid)) {
    294             return $ok;
    295         } else if ($this->is_allowed_in_context($typeid, $courseid)) {
    296             $tool = lti_get_type_type_config($typeid);
    297             if ($tool !== false) {
    298                 if (!$this->is_unsigned() && ($tool->lti_resourcekey == $consumerkey)) {
    299                     $ok = $this->check_signature($tool->lti_resourcekey, $tool->lti_password, $body);
    300                 } else {
    301                     $ok = $this->is_unsigned();
    302                 }
    303             }
    304         }
    305         return $ok;
    306     }

The function lti\get_oauth_key_from_headers() is defined in mod/lti/OAuthBody.php, and it is returning false

[porcospino]

And following my own trail, I discovered that the "Authorization" header was not being forwarded to the backend by AWS CloudFront. I think this is a documentation issue now.

See Configure CloudFront to Forward Authorization Headers

There is probably a similar configuration setting for Azure CDN.

[adbindal]

Thanks @porcospino for the update. I'm closing the issue based on the above update.