There appear to be a few variations on how this works, depending on the origin of the request to the api. The docs might make sense to some people, but not to me.
I ran a node.js script locally and could connect to jira cloud using axios with an 'auth' config. Some have noted that email address is important here, rather than username, if that is even an option anymore.
axios.get( {
...,
auth: { username: me@domain.com, password: <apikey> },
...
})When I tried to use this same method after browserify, i.e., connect to the REST API from a javascript in a web browser, I was indirecty informed (because it didn't work) that I was required to use Oauth23LO. Fine, np. I doctored up my script to do the dance:
- get the "authorization code" using the "client id" from my external app config,
- then get the "access token" using the "client id", "secret", and newly minted "authorization code"
- then get "cloud id" to stuff it in the rest url using the "access token"
- then use the 'api.atlassian.net' host instead of my jira cloud hostname,
but it still didn't work, because evidently one still must include the "access token" in the request header.
The only examples in REST API docs that i could find are for scripts and/or serverside proxies which apparently use similar syntax to the above (and one must question whether 3LO is actually necessary with a proxy--it's not, is it?) Nevertheless, the community has a spate of posts from folks with similar issues. (Some using Connect, and others, not.) Somewhere between the 15th and 20th of these posts I was encouraged to try putting my auth token in an auth bearer header.
axios.get( {
...,
headers: { ..., 'Authorization':'Bearer <access_token>' },
...
})This works in the browser, and apparently, it's secure. However, it's so cumbersome to set up I assume anyone slightly lazier than me will just pass around apikeys, or hard code them in proxy scripts and commit them to bitbucket.
