by Michael Robellard.
Figured it out!
Had nothing to do with Running publicly or Access-Control-Allow-Origin
It was Apache.
Apache was stripping the Authorization Header coming into the server.
In moodle toolproxy.php the response code was being set properly to 401 on line 74
public function execute($response) {
$ok = $this->check_tool_proxy(null, $response->get_request_data());
if ($ok) {
$toolproxy = $this->get_service()->get_tool_proxy();
} else {
$toolproxy = null;
$response->set_code(401);
}
but then being changed to 400 later on
if (!empty($toolproxy)) {I think if someone puts a return after the set_code(401) It should start returning a 401 instead of a 400.
if ($ok) {
// If all went OK accept the tool proxy.
$toolproxy->state = LTI_TOOL_PROXY_STATE_ACCEPTED;
$toolproxy->toolproxy = $response->get_request_data();
$toolproxy->secret = $toolproxyjson->security_contract->shared_secret;
$toolproxy->vendorcode = $toolproxyjson->tool_profile->product_instance->product_info->product_family->vendor->code;
$url = $this->get_endpoint();
$body = <<< EOD
{
"@context" : "http://purl.imsglobal.org/ctx/lti/v2/ToolProxyId",
"@type" : "ToolProxy",
"@id" : "{$url}",
"tool_proxy_guid" : "{$toolproxy->guid}"
}
EOD;
$response->set_code(201);
$response->set_content_type('application/vnd.ims.lti.v2.toolproxy.id+json');
$response->set_body($body);
} else {
// Otherwise reject the tool proxy.
$toolproxy->state = LTI_TOOL_PROXY_STATE_REJECTED;
$response->set_code(400);
}
lti_update_tool_proxy($toolproxy);
} else {
$response->set_code(400);
}
The fix in apache was simple
Just add:
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
to the Apache Configuration and problem solved