Skip to content

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

  1. Start a Gitpod on the 325278-use-subscriptions-api-jira-connect branch
  2. Switch to the gitlab app folder cd /workspace/gitlab-development-kit/gitlab`
  3. Set up the Jira app using this instructions
  4. Complete the steps to set up the OAuth flow
  5. Remove the , if: -> { request.format.html? } part from app/controllers/jira_connect/subscriptions_controller.rb:24
  6. On Atlassian, visit the Get started page
  7. Open the developer tools on the Network tab
  8. Click Sign in to GitLab
  9. Complete the OAuth flow in the new window
  10. Observer in the Network tab that there is a request to <Gitpod instance>/-/jira_connect/subscriptions?jwt=<token> that response with 403
  11. Cope the JWT token and paste it into a JWT debugger
  12. Observe that the payload contains a qsh with the value context-qsh
  13. On Gitpod, rebase on this branch git rebase andysoiron/allow-context-jwt-for-jira-subscriptions-json-endpoint
  14. Reload the Get started
  15. Complete the OAuth flow again
  16. Observe that the request to <Gitpod instance>/-/jira_connect/subscriptions?jwt=<token> now responses with 200

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Andy Schoenen

Merge request reports

Loading