Refactor LTI11 source

[jgwerner]

• Refactors LTI 1.1 codebase based largely on Organize into multiple files #2
• Updates tests

Related to #38 #39

[jgwerner]

@yuvipanda this is the second PR related to #39. Once we merge this one I'll update #40 based on an agreed structure.

By the way, adding ltiauthenticator.lti11... and ltiauthenticator.lti13... to the package namespace is a breaking change for existing imports. Is that ok with you or would you rather have all classes in the ltiauthenticator root?

[yuvipanda]

This looks good too! What do you think about keeping ltiauthenticator.LTIAuthenticator as an alias so we don't break existing installs?

[jgwerner]

Good idea on the alias. I'll push and update with that change.

[jgwerner]

@yuvipanda the requested changes have been pushed.

[yuvipanda]

Minor changes, + merge conflict resolution - otherwise LGTM!

[yuvipanda]

LTI11LaunchValidator?

[jgwerner]

@yuvipanda this is a class I created as an abstraction to validate the LTI 1.1 requests since some are required and some optional and wanted to offer end users the option of fine tuning their own validations. I would be glad to remove this though if it's noisy.

[yuvipanda]

Does 1.3 use the same validation logic? If so, then we can leave it as is! Otherwise just wanted a rename.

Thank you for going through this with me!

[jgwerner]

It does, but we can rename it to something else if you'd like.

[yuvipanda]

Ah, I did not know that! If it's using the same validation logic, we can leave it as is. Thank you for the explanation :)

[jgwerner]

Actually, the Launch part in the class name is due to how the LTI 1.1 specification refers to logins as "Launch Requests". With LTI 1.3 the term changed to "Login Initiation Requests" so that it's more in line with OIDC/OAuth2 but we kept using "...Launch..." with LTI 1.3. We were planning to refactor the class name from LTI13LaunchValidator to LTI13LoginInitiationValidator for clarity but haven't gotten around to it.

[jgwerner]

@yuvipanda I pushed the requested changes and added more tests (mostly for the validator). If possible, we would like to submit one more PR before tackling #39 so we update the logic for the LTI 1.1 validator so that it's more consistent with the LTI 1.3 validator logic.

[yuvipanda]

AWESOME! Thanks, @jgwerner :)