for me the following happens.
access with basic-auth works:
curl --verbose -u jiratest@usersnap.com:<$API_TOKEN> https://api.atlassian.com/ex/jira/ea712a28-1636-4f3c-b8d3-d7a15f487591/rest/api/2/issue/AP-1
< HTTP/2 200
< date: Wed, 28 Feb 2024 12:54:50 GMT
< content-type: application/json;charset=UTF-8
< server: AtlassianEdge
< timing-allow-origin: *
< x-arequestid: f1c1b87db691d4e3729916198dc7c599
< set-cookie: atlassian.xsrf.token=acfd7ec38182be16caf711c8a7f5f6b39c4624cc_lin; Path=/; SameSite=None; Secure
< x-aaccountid: 557058%3Ab5c2d168-22a2-4fbc-ad59-617cc01675f1
< cache-control: no-cache, no-store, no-transform
< vary: Accept-Encoding
< x-trace-id: a18b93b9e8ea419098b5417d8fde53d6
< x-frame-options: SameOrigin
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< atl-traceid: a18b93b9e8ea419098b5417d8fde53d6
< report-to: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
< nel: {"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
< strict-transport-security: max-age=63072000; preload
<
{"expand":"renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations,customfield_10740.requestTypePractice","id":"17900","self":"https://api.atlassian.com/ex/jira/ea712a28-1636-4f3c-b8d3-d7a15f487591/rest/api/2/issue/17900","key":"AP-1","fields":{"statuscategorychangedate":"2017-03-07T16:22:22.719+0100","issuetype":{"self":"https://api.atlassian.com/ex/jira/ea712a28-1636-4f3c-b8d3-d7a15f487591/rest/api/2/issuetype/1","id":"1","description":"A problem which impairs or prevents the ...
coming from oauth, it doesn’t work:
curl --verbose --request GET --url https://api.atlassian.com/ex/jira/ea712a28-1636-4f3c-b8d3-d7a15f487591/rest/api/2/issue/AP-1 --header 'Authorization: Bearer $BEARER_TOKEN' --header 'Accept: application/json'
< HTTP/2 404
< date: Wed, 28 Feb 2024 12:56:34 GMT
< content-type: application/json;charset=UTF-8
< server: AtlassianEdge
< timing-allow-origin: *
< x-arequestid: f1688518240df6eaa453e70f01f200fd
< set-cookie: atlassian.xsrf.token=1f491c81c0f58aefbaa86d14e43d45f4a0d1af0b_lin; Path=/; SameSite=None; Secure
< x-aaccountid: 557058%3Ab5c2d168-22a2-4fbc-ad59-617cc01675f1
< cache-control: no-cache, no-store, no-transform
< x-trace-id: 31a16da45c7d49be87bc1cb64ab2946c
< x-frame-options: SameOrigin
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< atl-traceid: 31a16da45c7d49be87bc1cb64ab2946c
< report-to: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
< nel: {"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
< strict-transport-security: max-age=63072000; preload
<
* Connection #0 to host api.atlassian.com left intact
{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{}}
note that it’s always the same url that i’m requesting: https://api.atlassian.com/ex/jira/ea712a28-1636-4f3c-b8d3-d7a15f487591/rest/api/2/issue/AP-1
also, the bearer token is not broken. it works – here’s a request (that i actually made after the i got the 404).
curl --verbose --request GET --url https://api.atlassian.com/oauth/token/accessible-resources --header 'Authorization: Bearer $BEARER_TOKEN' --header 'Accept: application/json'
< HTTP/2 200
< date: Wed, 28 Feb 2024 12:58:02 GMT
< content-type: application/json; charset=utf-8
< content-length: 798
< x-frame-options: SAMEORIGIN
< x-content-typeoptions: nosniff
< etag: W/"31e-Kn1d39XHgC/699WasDTy9CuE4oc"
< server: AtlassianEdge
< x-trace-id: b812524470dd4e70a2c3f18b86526df2
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< atl-traceid: b812524470dd4e70a2c3f18b86526df2
< report-to: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
< nel: {"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
< strict-transport-security: max-age=63072000; preload
<
* Connection #0 to host api.atlassian.com left intact
[{"id":"3296ed78-bb1c-4b3c-b112-2342707b2538","url":"https://usersnap-jiratest.atlassian.net","name":"usersnap-jiratest","scopes":["read:jira-user","read:jira-work","write:jira-work"],"avatarUrl":"https://site-admin-avatar-cdn.prod.public.atl-paas.net/avatars/240/rings.png"},{"id":"df5b93f5-ac92-4c0e-8f95-ab5aaeca0722","url":"https://usersnap.atlassian.net","name":"usersnap","scopes":["read:jira-user","read:jira-work","write:jira-work"],"avatarUrl":"https://site-admin-avatar-cdn.prod.public.atl-paas.net/avatars/240/koala.png"},{"id":"ea712a28-1636-4f3c-b8d3-d7a15f487591","url":"https://usersnaptest.atlassian.net","name":"usersnaptest","scopes":["read:jira-user","read:jira-work","write:jira-work"],"avatarUrl":"https://site-admin-avatar-cdn.prod.public.atl-paas.net/avatars/240/koala.png"}]%
note that the user is also the same: usersnap-jiratest.
that is not even our actual problem, our problem is that the createmeta endpoints also deliver a 404, thus breaking our Jira Integration (because we’re fetching the createmeta before creating issues).
what can we do about this?
EDIT: FWIW, we started really seeing this yesterday. some logs indicate that this might have started feb 22, but not entirely clear if it’s the same thing.