I started seeing an issue with a single oauth client. For context, we have 4 environments that are running identical versions of code, the only difference in each environment is the client we use. In each environment we have 2 clients for 2 different use cases. Out of these 8 total oauth clients, all of them form urls and authorization the exact same way. For some reason, 1 client in 1 environment started returning a 401 with html as the body for every request made to the REST API.
We are forming our urls like so
https://<site-url>/rest/api/<version>/<resource>
As this was the recommendation of the jira cloud REST API documentation at the time (now that I’m checking, it seems that this recommendation has changed, more on that later).
For this one problem oauth client, if I instead form the urls like so
https://api.atlassian.com/ex/jira/<cloudId>/rest/api/<version>/<resource>
With the same Authorization header set, the request completes successfully. It seems at some point the documentation changed to suggest this url formation, although I am not sure when, as our code that uses the rest api has been functioning in production since January.
I have a few questions after this finding:
-
Why is only 1 of our 8 oauth clients affected by this issue, and why did it suddenly stop working after months of success?
-
Was there a breaking API change introduced underneath the cloud REST API in which target URL we are supposed to interact with? Was this change communicated to consumers of the REST API?
-
Are our other 7 oauth clients going to break at any point in time if we do not update the url formation to match the second pattern I described?