Have you ever received an error with the LTI Provider that mentions something with the ./lms/djangoapps/lti_provider/signature_validator.py giving you issues with the client id/secret?
I have setup two different LTI Consumers. For some reason the one that works is the one that has consumer key/shared secret with max 20 characters, while another one with consumer key/shared secret with 30 characters seems not to work and generates the above errors.
@sambapete
It may not be a character limit here for consumer key / shared secret. After debugging the POST call to https://edx-platform-lms/lti_provider with request payload value of oauth_consumer_key: fake. That’s probably why the Valid client exception was thrown.
In this case:
self.lti_consumer.consumer_key - Value set from the LtiConsumer model at consumer_key field. Example: 20 or 32 characters random_uuid
client_key - From the POST request payload value of 'oauth_consumer_key'. Example in this failing POST call is 'fake'.
So (20 or 32 characters random_uuid) == 'fake' would produce False.
In this article it talks about external app configurations created at the course-level and/or account-wide third party app configuration. I’ve always set this external app permission for EducateWorkforce at the course-level. Can you double check that you’re not setting up an external app for courses.educateworkforce.com with fake Consumer Key value?
@sambapete
Confirmed this working with a Canvas customer. The had setup an External Tool at the account-level and they also had a configuration at the course-level. The course-level configuration was one that I provided for them through a IMSCC (Common Cartridge) file import, and it was never configured properly so the oauth_consumer_key: fake was getting passed from the course-level External Tool configuration instead.
When they removed the course-level External Tool configuration everything worked fine! So, I think it’s not a consumer key / shared secret length issue but rather multiple configurations of the External Tool (1 at the account-level configured properly, 1 at the course-level not setup).
After I tested this, I was unable to load a page. I think that it’s due to the request payload variables not named the same as what the edX /lti_provider endpoint expects.
The following request payload needs to be there and saLTIre sends key in the payload which don’t match up with oauth_consumer_key naming. Also, the other required parameters are missing. It doesn’t appear that saLTIre can allow you to input these additional values.
# LTI launch parameters that must be present for a successful launch
REQUIRED_PARAMETERS = [
'roles', 'context_id', 'oauth_version', 'oauth_consumer_key',
'oauth_signature', 'oauth_signature_method', 'oauth_timestamp',
'oauth_nonce', 'user_id'
]
@Zachary_Trabookis I do not have any issues using saLTIre with the shorter keys. That’s why I was asking if you did something special. I cannot even get the LMS to give me a web page when using the longer keys under Nutmeg and Tutor.
