[Question] Incorrectly Invalid Signature

[battis]

I'm running into a strange error. I'm running my Tool Provider on Heroku (although I think that may be irrelevant — I mention it only because of the way they handle SSL connections on free apps), and when I make an LTI launch request from my Tool Consumer (Blackbaud's learning management system, in this case), I find that the OAuth Signature is failing its checks and being flagged as invalid.

I went through a bunch of gyrations making sure that I wasn't having some sort of timezone/timestamp disconnect, and have both the tool consumer and tool provider in the same timezone, with timestamps ~1 second apart (depending on when checked, I suppose). Double-checked that everyone was using the same key/secret combination.

Having dug around for a while in PHP-LTI code, I slapped together the below. Which makes me think that I'm experiencing Schrödinger's OAuth signature: it is both valid (using my hacked together check) and invalid (when processed by $tool->handleRequest()).

Any perspective on what might be going wrong? Any insights/redirects would be much appreciated! Thanks!

use ceLTIc\LTI\OAuth\OAuthRequest;
use ceLTIc\LTI\OAuthDataStore;
use DI\Container;
use GrotonSchool\AssignmentsViewer\AssignmentsViewerTool;
use ceLTIc\LTI\OAuth\OAuthConsumer;
use ceLTIc\LTI\OAuth\OAuthServer;
use ceLTIc\LTI\OAuth\OAuthSignatureMethod_HMAC_SHA1;

require_once __DIR__ . '/../bootstrap.php';
/** @var Container $container */

$_SESSION = [];
session_destroy();

/** @var LTITestTool */
$tool = $container->get(LTITestTool::class);
$tool->debugMode = true;

$hmac = new OAuthSignatureMethod_HMAC_SHA1();
$consumer = new OAuthConsumer('<key provided to consumer>', '<secret provided to consumer>');
$store = new OAuthDataStore($tool);
$server = new OAuthServer($store);
$request = OAuthRequest::from_request();
$token_field = $request instanceof OAuthRequest ? $request->get_parameter('oauth_token') : null;
error_log('token_field: ' . $token_field);
$token = $store->lookup_token($consumer, "access", $token_field);
error_log('token: ' . print_r($token, true));
error_log('Built signature: ' . $hmac->build_signature($request, $consumer, $token));
error_log('Check: ' . $hmac->check_signature($request, $consumer, $token, $request->get_parameter('oauth_signature')));

$tool->handleRequest();

And I'm seeing results like this:

2021-11-29T19:33:03.258151+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] token_field: 
2021-11-29T19:33:03.258387+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] token: ceLTIc\LTI\OAuth\OAuthToken Object
2021-11-29T19:33:03.258411+00:00 app[web.1]: (
2021-11-29T19:33:03.258533+00:00 app[web.1]:     [key] => ceLTIc\LTI\OAuth\OAuthConsumer Object
2021-11-29T19:33:03.258577+00:00 app[web.1]:         (
2021-11-29T19:33:03.258711+00:00 app[web.1]:             [key] => <key provided to consumer>
2021-11-29T19:33:03.258859+00:00 app[web.1]:             [secret] => <secret provided to consumer>
2021-11-29T19:33:03.258941+00:00 app[web.1]:             [callback_url] => 
2021-11-29T19:33:03.258984+00:00 app[web.1]:         )
2021-11-29T19:33:03.258996+00:00 app[web.1]: 
2021-11-29T19:33:03.259171+00:00 app[web.1]:     [secret] => 
2021-11-29T19:33:03.259192+00:00 app[web.1]: )
2021-11-29T19:33:03.259204+00:00 app[web.1]: 
2021-11-29T19:33:03.259411+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] Built signature: 3SUKntyPu0Md+fXXf42fV1IpXq8=
2021-11-29T19:33:03.259536+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] Check: 1
2021-11-29T19:33:03.259775+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] [INFO] POST request received for '/launch' with body parameters of:
2021-11-29T19:33:03.259807+00:00 app[web.1]: array (
2021-11-29T19:33:03.259903+00:00 app[web.1]:   'oauth_callback' => 'about:blank',
2021-11-29T19:33:03.260048+00:00 app[web.1]:   'oauth_nonce' => '6698fe12a2844078848815af6142c8aa',
2021-11-29T19:33:03.260159+00:00 app[web.1]:   'oauth_signature_method' => 'HMAC-SHA1',
2021-11-29T19:33:03.260271+00:00 app[web.1]:   'oauth_timestamp' => '1638214383',
2021-11-29T19:33:03.260321+00:00 app[web.1]:   'oauth_version' => '1.0',
2021-11-29T19:33:03.260421+00:00 app[web.1]:   'launch_presentation_locale' => 'en-US',
2021-11-29T19:33:03.260536+00:00 app[web.1]:   'lti_message_type' => 'basic-lti-launch-request',
2021-11-29T19:33:03.260596+00:00 app[web.1]:   'lti_version' => 'LTI-1p0',
2021-11-29T19:33:03.260713+00:00 app[web.1]:   'resource_link_id' => '542|27|2352627|84489|1202415',
2021-11-29T19:33:03.260814+00:00 app[web.1]:   'resource_link_title' => 'LTI Test',
2021-11-29T19:33:03.260923+00:00 app[web.1]:   'resource_link_description' => 'Testing LTI tool provider',
2021-11-29T19:33:03.261056+00:00 app[web.1]:   'tool_consumer_info_product_family_code' => 'BlackbaudK12',
2021-11-29T19:33:03.261139+00:00 app[web.1]:   'tool_consumer_info_version' => '1.52',
2021-11-29T19:33:03.261193+00:00 app[web.1]:   'user_id' => '6511555',
2021-11-29T19:33:03.261252+00:00 app[web.1]:   'roles' => 'Instructor',
2021-11-29T19:33:03.261328+00:00 app[web.1]:   'lis_person_name_given' => 'Seth',
2021-11-29T19:33:03.261414+00:00 app[web.1]:   'lis_person_name_family' => 'Battis',
2021-11-29T19:33:03.261501+00:00 app[web.1]:   'lis_person_name_full' => 'Seth Battis',
2021-11-29T19:33:03.261628+00:00 app[web.1]:   'lis_person_contact_email_primary' => 'sbattis@groton.org',
2021-11-29T19:33:03.261705+00:00 app[web.1]:   'context_id' => '542|2|94137853',
2021-11-29T19:33:03.261797+00:00 app[web.1]:   'context_label' => 'Advanced History (Y)',
2021-11-29T19:33:03.261890+00:00 app[web.1]:   'context_title' => 'Advanced History (Y)',
2021-11-29T19:33:03.262002+00:00 app[web.1]:   'tool_consumer_instance_guid' => '<tool consumer GUID>',
2021-11-29T19:33:03.262109+00:00 app[web.1]:   'tool_consumer_instance_name' => 'Groton School',
2021-11-29T19:33:03.262217+00:00 app[web.1]:   'launch_presentation_document_target' => 'window',
2021-11-29T19:33:03.262461+00:00 app[web.1]:   'launch_presentation_return_url' => 'https://groton.myschoolapp.com/app/Lti/Land?lid=eyFC5CGyAwwYN7YMH4ihNg%253d%253d',
2021-11-29T19:33:03.262586+00:00 app[web.1]:   'oauth_consumer_key' => '<key provided to consumer>',
2021-11-29T19:33:03.262699+00:00 app[web.1]:   'oauth_signature' => '3SUKntyPu0Md+fXXf42fV1IpXq8=',
2021-11-29T19:33:03.262709+00:00 app[web.1]: )
2021-11-29T19:33:03.262900+00:00 app[web.1]: [29-Nov-2021 14:33:03 America/New_York] [ERROR] Request failed with reason: 'Invalid signature'
2021-11-29T19:33:03.262917+00:00 app[web.1]: See: 
2021-11-29T19:33:03.263014+00:00 app[web.1]:   /app/vendor/celtic/lti/src/Util.php line 222
2021-11-29T19:33:03.263110+00:00 app[web.1]:   /app/vendor/celtic/lti/src/Tool.php line 473
2021-11-29T19:33:03.263192+00:00 app[web.1]:   /app/public/launch.php line 34

[spvickers]

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.

[spvickers]

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".

[battis]

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.

[spvickers]

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?

[battis]

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

[battis]

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.

[spvickers]

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

[spvickers]

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.

[battis]

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.)

[spvickers]

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.

[BurninLeo]

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.

Thanks for this answer! It had taken me hours tracking down the "invalid signature" issue in lti-php. The problem was that an URL like .../interface.php?module=lti would not work for the launch, because one side did only use ``.../interface.php` to calculate the hash.

[spvickers]

Glad to hear you have now got to the bottom of this.