Allow context qsh for Jira subscriptions json
What does this MR do and why?
The /-/jira_connect/subscriptions
JSON endpoint will be requested by the frontend using a JWT that Atlassian provides via JavaScript. This JWT will likely use a context-qsh
because
Atlassian don't know for which endpoint it will be used. Read more about context JWT here: https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/
This MR is to fix the backend part for !83500 (comment 886699903)
How to set up and validate locally
- Start a Gitpod on the
325278-use-subscriptions-api-jira-connect
branch - Switch to the
gitlab
app foldercd
/workspace/gitlab-development-kit/gitlab` - Set up the Jira app using this instructions
- Complete the steps to set up the OAuth flow
- Remove the
, if: -> { request.format.html? }
part from app/controllers/jira_connect/subscriptions_controller.rb:24 - On Atlassian, visit the Get started page
- Open the developer tools on the Network tab
- Click Sign in to GitLab
- Complete the OAuth flow in the new window
- Observer in the Network tab that there is a request to
<Gitpod instance>/-/jira_connect/subscriptions?jwt=<token>
that response with403
- Cope the JWT token and paste it into a JWT debugger
- Observe that the payload contains a
qsh
with the valuecontext-qsh
- On Gitpod, rebase on this branch
git rebase andysoiron/allow-context-jwt-for-jira-subscriptions-json-endpoint
- Reload the Get started
- Complete the OAuth flow again
- Observe that the request to
<Gitpod instance>/-/jira_connect/subscriptions?jwt=<token>
now responses with200
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Andy Schoenen