I’m building an app using Elixir so I’ve written the code to build a query_string_hash and jwt. Along the way I’ve been comparing against atlassian-jwt - npm and am now consistently generating matching results for both jwt.createQueryStringHash and jwt.encodeSymmetric.
When I make a request like the following I’m getting a 401 (actual generated jwt).
curl -X GET "https://opsb-dev.atlassian.net/rest/api/3/issue/TES-1" \
-H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2ODI1NDIzODcsImlhdCI6MTY4MjUzODc4NywiaXNzIjoiMmEyYTdjMDQtNDE1YS0zNDA4LTg3M2EtMDE2MjhkMDQ3ZDVhIiwibmJmIjoxNjgyNTM4Nzg2LCJxc2giOiI0YTdkMDVmNDdlZjc0ZjdjM2Q1YjI4MDAxY2IxMGM0N2Y2YzczODk5NDI2ZjE0ZTVkMzZkMDVhZDQ3M2Y5NDJjIn0.FgASMG0LJfYyUMbdQxAlxgCRZSUASmAHNJGT-I5mKUk"
The clientKey (iss) and sharedSecret (signing key) and baseUrl were taken from the app installed lifecycle callback.
I’ve added the read scope to atlassian-connect.json and done a fresh install of the app to ensure that the scopes are up to date.
I’d appreciate some help here, I’m not sure what I’m missing.
clientKeys actually come in all shapes and forms, it depends on when the app was first installed. There have been at least 3 generations of them if not more over the years.
Hey @ibuchanan thanks for the suggestion. I did save the whole payload from the post install hook and it doesn’t include a jira prefix in the clientKey. I tried it anyway just in case but I’m still getting the 401.