Canvas authorize_redirect request never goes out about lti-php HOT 10 CLOSED

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.

from lti-php.

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?

from lti-php.

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.

from lti-php.

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

from lti-php.

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?

from lti-php.

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.

from lti-php.

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?

from lti-php.

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
        )

from lti-php.

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.

from lti-php.

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

from lti-php.