Jira app fails to work from AWS Lambda

HI All,
I am trying to run a small jira app, that sends a jql query and shows a simple html table with the result (Some aggregation for work analysis).
The app is installed successfully in Jira cloud.

When I try run the app from my local computer it works great, but when I try to run the same app from AWS Lambda service, I get an error.

find stored client data for jira:5000bed1-d001-453a-9805-0b30754af1fc
Authentication verification error (401): Authentication failed: query hash does not match.

2019-11-18T08:29:56.386Z 2a1f6de6-789e-4c64-a8d2-e86614ac62bf ERROR Auth failure: Query hash mismatch: Received: "a966579f6f1f5c79cc69e89ace85a76fab50915d755385f77465ee6e72b50dd4" but calculated "b374bdaaf94d47ca7f53e3c88aa9f463cd55fb8e6107f7510dfc522996da1a8c". Canonical query was: "GET&/get-monthly-time-spent-gh-issues&cp=&cv=1.556.0&lic=none&xdm_c=channel-reports-plugin__jira-app&xdm_deprecated_addon_key_do_not_use=reports-plugin&xdm_e=https%3A%2F%2Fprosperaag.atlassian.net

Can someone help me figure this one out?

Hi Maayan,

It means that the canonical version of the request that arrived at the plugin is different from the one that is sent by cloud instance.

Since the JWT auth token requires that the relative path and query params matches exactly to decode correctly, it is most likely some part of the request is being altered between when it is sent and when it is received.

Do you have anything in your setup that might be adding parameters to the request or otherwise changing it from it’s original form?

2 Likes

Hi Richard,
Sorry for the delay, somehow I missed your reply.
Yes, I use NodeJS serverless, which added /dev to the url when deploying the Lambda.

No worries,

If you are using Atlassian Connect Express, just double checking:

  • did you add the /dev to the localBaseUrl in production section of config.json file? (correct)
  • or did you add /dev to each relative url in your atlassian-connect.json (will cause this error)

If that’s still not solving it, I would look for a way to log the request path and query parameters to make sure they match the canonical query.

Hey,
I tried several combinations, so probably tried both options.
Can you elaborate on logging the request path?
I have my cloudwatch logs.

So when it is checking the qsh is valid it checks:

  • does the request path and query parameters match what was claimed in the JWT token sent with the request?

Either:

  • there are request parameters / paths being altered by your setup / infrastructure (e.g Lambda)
  • the shared secret is incorrect (this seems unlikely)

So my suggestion is to check logs for what exactly is the inbound request path and parameters to determine if any parameters are being added / removed before they are turned into the canonical request format that you see in your error message.

Hi Richard,
Thanks a lot for your quick responses.
Unfortunately, I don’t have time to drill down into it right now.
I really appreciate your response, and I will need to get back to this in the future.
In the meantime, I suggest to close this ticket.

Maayan