Are there any known issues with using LTI 1.3 with self-hosted Canvas?

[jd1]

I am working on an LTI 1.3 tool. To test Canvas integration, I have set up a Canvas LMS in our Amazon Web Services account using the Bitnami "Canvas LMS Certified by Bitnami" machine image, which says it was last updated on 2/5/20, so I am assuming it is close to up-to-date. I have defined a tool per the documentation, and added it to a course module. However, when I try to access the resource that the tool refers to, I get an error:

{"errors":[{"message":"An error occurred.","error_code":"internal_server_error"}],"error_report_id":128}

My oAuth endpoints point to my server, e.g.:

https://my-domain.com/api/lti/security/jwks
https://my-domain.com/login/oauth2/token
https://my-domain.com/api/lti/authorize_redirect

which I think is correct. It's entirely possible that I am confused about the keys, as it seems that different sets of documentation refer to the keys differently. For what it's worth, I have the tool working okay with the IMS reference platform, and with Moodle.

But my main question: Are there any known issues with using LTI 1.3 with an open source / self-hosted Canvas installation?

[chad_spears_lod]

Hi Jim, 

I'm having this same problem on the Bitnami Canvas (Azure) build dated 2020.01.15.08-0. Our tool is working in Moodle and when testing with the IMS suite but I haven't had luck with Canvas.

I don't believe Consul nor dynamic_settings.yml are configured in my Canvas instance. After reading through github, I'm led to believe that Consul is required for LTI 1.3 integration, but dynamic_settings.yml may suffice. This Github Revision was reverted for some reason, but I'm going to try the suggestions from the link either today or tomorrow.

[jd1]

Thanks for this information.

I found this in the /opt/bitnami/apps/canvaslms/htdocs/log/production.log file when trying to process my LTI 1.3 request:

exception_message: Unknown Key Type

and

JSON::JWK::UnknownAlgorithm

Not sure if this is referring to my public key that appears in the Developers Keys entry, but it has

    "alg": "RS256"

and

    "kty": "RSA"

in the json entry.

I will be interested to hear what you find out -- if that's the issue, it could / should be something for Bitnami to update in their machine image.

[jd1]

I see where the Github setup instructions ( Production Start · instructure/canvas-lms Wiki · GitHub  ) has this in the section on cache settings: "Canvas supports two different methods of caching: Memcache and redis. However, there are some features of Canvas that require redis to use, such as OAuth2". 

Though I haven't gotten around to confirming if I have redis set up correctly, so cannot confirm if this does indeed fix the issue.

[krishnalallk]

Hi @jd1  @chad_spears_lod 

I am also facing the same issue with the bitnami self hosted canvas lms using oracle VM.

Any help to solve this issue?

In my case, I have added LTI 1.3 inside bitnami canvas lms but whenever I try to access the application it's returning an error message saying 

 My endpoints are as follows

"http://192.168.43.156/api/lti/authorize_redirect"
"http://192.168.43.156/api/lti/security/jwks"

[doc2]

Can I ask this question differently? Has anyone ever successfully performed an LTI for anything from Self Hosted? Something as simple as Office 365 opening in IFrame? I am just trying to simplify the problem as proposed, as I have too been unsuccessful with either Bitnami or direct install self host LTI. IF we can start at the simplest point, maybe together we can resolve this.

[athyg1]

My Question relates specifically to H5P LTI, as I'm unable to get this working for my AWS self-hosted Canvas instance. I'm using the older v1.1 as a workaround.

Is Self-hosted Canvas LMS compatible with H5P LTI v1.3?