[Question] Incorrectly Invalid Signature about lti-php HOT 10 CLOSED

I plan to change the constructor method for the DataConnector object to be protected (rather than public) in the next release to avoid this issue in future.

from lti-php.

The most likely cause is that the URL of your endpoint as seen by your app is not the same as the URL used by the sender because of some mapping happening on the server. For example, rather than https://your.server.com/launch (as used by the Tool Consumer) your code is detecting the URL as being something else like https://your.server.com/lti/launchapp.php. If you set the logging level to debug I think you may get the OAuth basestring logged so you can check this.

from lti-php.

As well as altering your code, you can also set the logging level to debug by including a custom parameter in the launch named "debug" (passed as "custom_debug") with a value of "true".

from lti-php.

Interesting. I'll spend some time looking at that base string more deeply. When I looked at the base string, the URL endpoint looked identical (save for url encoding):

POST&https%3A%2F%2Ftool-provider-subdomain.herokuapp.com%2Flaunch&context_id%3D542%257C2%257C94137853%26context_label%3DAdvanced%2520History%2520%2528Y%2529%26context_title%3DAdvanced%2520History%2520%2528Y%2529%26launch_presentation_document_target%3Dwindow%26launch_presentation_locale%3Den-US%26launch_presentation_return_url%3Dhttps%253A%252F%252Fgroton.myschoolapp.com%252Fapp%252FLti%252FLand%253Flid%253DPu0NvH2%2525252bVuZQKy3KieyXkw%2525253d%2525253d%26lis_person_contact_email_primary%3Dsbattis%2540groton.org%26lis_person_name_family%3DBattis%26lis_person_name_full%3DSeth%2520Battis%26lis_person_name_given%3DSeth%26lti_message_type%3Dbasic-lti-launch-request%26lti_version%3DLTI-1p0%26oauth_callback%3Dabout%253Ablank%26oauth_consumer_key%3D<key provided to consumer>%26oauth_nonce%3Dd9ee9f17bc32455cb2c1191106030a1b%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1638280984%26oauth_version%3D1.0%26resource_link_description%3DView%2520assignments%26resource_link_id%3D542%257C27%257C2352627%257C84489%257C1202415%26resource_link_title%3DAssignments%2520Viewer%26roles%3DInstructor%26tool_consumer_info_product_family_code%3DBlackbaudK12%26tool_consumer_info_version%3D1.52%26tool_consumer_instance_guid%3D<tool consumer GUID>%26tool_consumer_instance_name%3DGroton%2520School%26user_id%3D6511555

So... https%3A%2F%2F<tool provider subdomain>.herokuapp.com%2Flaunch vs. https://<tool provider subdomain>.herokuapp.com/launch in the tool consumer settings.

I have to admit, the thing that confuses me the most at the moment is that the signature I built on the tool provider end with my hack (3SUKntyPu0Md+fXXf42fV1IpXq8=) is an exact match for the sent signature (3SUKntyPu0Md+fXXf42fV1IpXq8=) and that when I called $hmac->check_signature() in my hack, I saw this:

2021-11-29T19:33:03.259536+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] Check: 1

I think I need to remove the Heroku question mark from my testing, so I'll set up a test on a non-Heroku domain to see if I can get it to work.

from lti-php.

OK, so it looks like my hunch was not the reason. When you turned on debug-level logging did you get any more detailed error message to give further hints at the cause. You can use a tool like the one at https://lti.tools/oauth/ to check the calculation of the signature; let me know if it looks like the signature generated from the base string reported from the LTI library being used by your tool provider does not agree with the one generated elsewhere and I shall investigate further. If you are able to provide a full base string and shared secret so I can check it myself that would be very helpful. You can send it to me at stephen at spvsoftwareproducts.com if you prefer not to post it here. Is the tool consumer you are using IMS certified?

from lti-php.

Yup, they're certified. I'll email you the base string and secret in a moment. Thank you so much!

from lti-php.

Closing this out by noting (with many thanks to Stephen for helping figure this out), that one can only have the DataConnector auto-detect your database if you use the factory method, not the constructor.

Super important to create the DataConnector thus:

$pdo = new PDO( /* ... as one does ... */ );
$works = DataConnector::getDataConnector($pdo); // <-- the RIGHT way
$fails = new DataConnector($pdo); // <-- the WRONG way

Calling the DataConnector constructor creates a generic DataConnector that fills in default values for things like, say... secrets.

from lti-php.

Thanks @battis, I shall reflect on this and see if I can remember why this behaviour exists and perhaps update the code accordingly.

from lti-php.

I suspect, in your case, you could also have done something like this:

$pdo = new PDO( /* ... as one does ... */ );
$should_work = new DataConnector_pdo($pdo);

The static method (getDataConnector) will work out which class to create for you, but you can also do this directly.

from lti-php.

Yes, that would have worked too. (Really, what I should have done in that case was new DataConnector_pdo_pgsql($pdo), but I think the regular PDO connector would have worked in this. moment.)

from lti-php.