Canvas authorize_redirect request never goes out

[mac1253]

Howdy! I have read IMS and your documentation over and over though I feel like I'm shooting in the dark still :( Anyways, using saltire, I able to get a request to work, though only with a redirect uri that is http and not https, which is I'm sure giving the me the related error attached in the image and my tool loads after clicking send anyways. However through Canvas, the hand shake request just seems to never get sent out. Checking the logs on my tool and using your debugger, the last thing that is logged is this:

[19-May-2022 15:26:57 UTC] [DEBUG] Form submitted using POST to 'https://canvas.instructure.com/api/lti/authorize_redirect' with parameters of:
array (
  'client_id' => 'xxxxxxx',
  'login_hint' => 'xxxxxx',
  'nonce' => 'xxxxxx,
  'prompt' => 'none',
  'redirect_uri' => 'http://mytool.com/ui/lti-new',
  'response_mode' => 'form_post',
  'response_type' => 'id_token',
  'scope' => 'openid',
  'state' => 'xxxxxx',
  'lti_message_hint' => jtw_token_xxxxxxxxxxxxx.xxxxxx,
)

What might be causing this to get hung up? Is there perhaps more code examples of using your library I could reference by chance? I am having a hard time understanding how to implement this standard.

[spvickers]

I suspect that most commercial platforms will prevent any LTI connections to tools which use http as this protocol is not allowed by the IMS spec and should be avoided, except for testing. There is nothing in saLTIre or this library which implements such a restriction; it is left to developers to do so.

[mac1253]

I stupidly forgot to include what happens when I include the https protocol (canvas and saltire):

{"status":"bad_request","message":"Invalid redirect_uri"}

and I noticed that despite using the https protocol the redirect uri in the post request for the hand shake back to canvas always has the redirect_uri using http. Why would the redirect_uri be http when I set it to https on the platform?

[spvickers]

If you are using both Canvas and saLTIre as alternative LTI platforms and they are both giving you the same error, my suspicion is that the redirect_uri you are passing to them is not the same as the one you have registered.

[mac1253]

They are different but only the protocol is different. Though I cant see why the protocol is being set to http rather than https.

'redirect_uri' => 'http://mytool.com/ui/lti-new',

In both platforms I have set the redirect uri to https://mytool.com/ui/lti-new

[spvickers]

Perhaps your tool is behind some form of load balancer which is offloading the https traffic so that your web server is seeing this as an http request and hence reconstructing the URL incorrectly?

[mac1253]

It seems that is actually one of the reasons I'm getting issues! we strip the the security layer before it reaches our tool. Thank you for the suggestion! So I should override a certain function from one of the classes? I can't override sendAuthenticationRequest since its private.

[spvickers]

At present the ceLTIc\LTI\OAuth\OauthRequest class looks for the presence of HTTP_X_FORWARDED_PROTO, HTTP_X_FORWARDED_SSL, HTTP_X_URL_SCHEME and HTTPS. I assume your infrastructure is not intialising any of these. What variables is your web server receiving which indicate that the origin of the request was using https?

[mac1253]

I only have HTTP_X_FORWARDED_PROTO, though its set to http when I log it. I also HTTP_CLOUDFRONT_FORWARDED_PROTO header and that is set to https

 [HTTP_X_FORWARDED_PROTO] => Array
        (
            [0] => http
        )

[HTTP_CLOUDFRONT_FORWARDED_PROTO] => Array
        (
            [0] => https
        )

[spvickers]

It looks to me that the HTTP_X_FORWARDED_PROTO variable is not being correctly set; if the incoming request is using https then I would expect this to be its value (as the HTTP_CLOUDFRONT_FORWARDED_PROTO variable is). I would suggest you check the reason for this with your service provider. In the meantime you could add in a check for the HTTP_CLOUDFRONT_FORWARDED_PROTO variable to get your code working temporarily. Please keep me updated on the reason for the value of the HTTP_X_FORWARDED_PROTO variable; if it is being set to "http" for a good reason then I'll look to update the library to accommodate this. Thanks.

[mac1253]

That does seem to be the issue! While were having issues getting the header _HTTP_X_FORWARDEDPROTO to include the https value. We just added it into the tool class for the moment.