REST API, Receiving a 401 Authentication failed message, but worked before and still works with sepa

[Jose Vallecillo]

JIRA Server Version 8.1.0

We have a custom plugin that makes REST API calls to our JIRA standalone server. It used to work just fine using a basic authentication method. We havent made any changes, and now it doesnt work anymore.

We can still make a basic REST call directly from the shell (As seen further below), but it doesnt work anymore via any other methods.

We are looking for some help to figure out what else we can try to get this going again from the plugin.

Also curious to know how the REST API can work as a cUrl call from the shell, but not from any other source.

Apparently something with Atlassian changed (it appears this issue impacts server as well) and we can not proceed using this method as we get an a failed authentication 401 response.

(Reference Links removed due to being a new user)

Results from the plugin:

HTTP/1.1 401
Cache-Control: private
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-AREQUESTID: 692x9264x1
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors ‘self’
X-ASEN: SEN-L14257054
X-Seraph-LoginReason: AUTHENTICATED_FAILED
WWW-Authenticate: OAuth realm="[localhost]"
Content-Type: text/html;charset=UTF-8

Unauthorized (401)

Attempts to use an API token using both an email address or user name also nets a 401 authenticated failed response:

curl -k -D- -u [email address]:[API token] -X GET “[localhost]/rest/api/latest/issue/ACC-17316?fields=customfield_10010”

HTTP/1.1 401
Cache-Control: private
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-AREQUESTID: 1053x39554x1
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors ‘self’
X-ASEN: SEN-L14257054
X-Seraph-LoginReason: AUTHENTICATED_FAILED
WWW-Authenticate: OAuth realm=“localhost”
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 06 Dec 2019 22:34:11 GMT

Attempts to use OATH1 are also failing
OAUTH tutorial for JIRA Server: (Fails at step 3)
My Results from Step 3:

java -Xdiag -jar OAuthTutorialClient-1.0.jar requestToken “[localhost]/jira/rest/auth/1/session”
Creating default properties file: ./config.properties
com.google.api.client.http.HttpResponseException: 400
oauth_parameters_absent=oauth_consumer_key&oauth_problem=parameter_absent
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1097)
at com.google.api.client.auth.oauth.AbstractOAuthGetToken.execute(AbstractOAuthGetToken.java:73)
at com.atlassian.oauth.client.example.JiraOAuthClient.getAndAuthorizeTemporaryToken(JiraOAuthClient.java:37)
at com.atlassian.oauth.client.example.OAuthClient.handleGetRequestTokenAction(OAuthClient.java:69)
at com.atlassian.oauth.client.example.OAuthClient.execute(OAuthClient.java:51)
at com.atlassian.oauth.client.example.ClientMain.main(ClientMain.java:18)

config.properties file:

JIRA_HOME=[localhost]
PRIVATE_KEY=MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBANuXE…[redacted]
oauth_consumer_key=JiraGitLoader

Also attempted this config file:

JIRA_HOME=[localhost]
PRIVATE_KEY=MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBANuXE…[redacted]
consumer_key=JiraGitLoader

and this config file

JIRA_HOME=[localhost]
PRIVATE_KEY=MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBANuXE…[redacted]
oauth_consumer_key=JiraGitLoader
OAUTH_PROBLEM=problem

Is there another method available to authenticate using OUATH1 on JIRA server?

Somehow it still works using basic authentication when invoking directly from the shell so we assume the actual permissions should be good:

curl -k -D- -u [username]:[password] -X GET “[localhost]/rest/api/latest/issue/ACC-17316?fields=customfield_10010”

HTTP/1.1 200
Cache-Control: private
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-AREQUESTID: 1040x39328x1
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors ‘self’
X-ASEN: SEN-L14257054
Set-Cookie: JSESSIONID=25B361F59B2D4B08A26AAD5546D48722; Path=/; Secure; HttpOnly
X-Seraph-LoginReason: OK
Set-Cookie: atlassian.xsrf.token=BWFS-I5KY-9U38-QRZG_73fb8a5ad08f4a6d6cab4f43cd5301aeb1954ce9_lin; Path=/; Secure
X-ASESSIONID: 13nwgkc
X-AUSERNAME: [username]
Cache-Control: no-cache, no-store, no-transform
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 06 Dec 2019 22:20:09 GMT

{“expand”:“renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations”,“id”:“113512”,“self”:“https://[localhost]/rest/api/latest/issue/113512”,“key”:“ACC-17316”,“fields”:{“customfield_10010”:[{“self”:"[localhost]/rest/api/2/customFieldOption/10003",“value”:“Enterprise”,“id”:“10003”},{“self”:"[localhost]/rest/api/2/customFieldOption/10004",“value”:“Fidelity”,“id”:“10004”}]}}

Other methods attempted:

Cookie based authentication (Doesn’t seem to even exist on the server anymore):

curl -d ‘{ “username”: “[user]”, “password”: “[password]” }’ -H “Content-Type: application/json” -X POST [localhost]/jira/rest/auth/1/session

Oops, you've found a dead link. - JIRA

[Jose Vallecillo · Accepted solution]

The code provided with the OAUth tutorial doesnt appear to work as provided. I did also attempt to edit that Properties Client file to no avail. Perhaps its something that someone on the Atlassian team can examine as I believe that I was not the only one facing that issue.

Giving up on getting this implementation of OAuth to work, we went back to examining why we could send a REST API request to our bitbucket installations, but not to JIRA’s.

We are using Apache httpcomponents for our java code. In both Bitbucket and JIRA, were using an interceptor with the DefaultCredentialsProvider to perform preemptive authentication. Worked just fine in both Bitbucket and JIRA until it wouldnt work in JIRA anymore.

Examining our own debug server logs, we noticed that without prompting, JIRA was dropping the header information and replacing it with an anonymous authentication instead while Bitbucket would retain the header information intact and authenticate properly.

The header information was also retained by JIRA for CURL calls from the shell. We couldnt determine why JIRA was doing this all of a sudden.

Our solution was to forcibly recreate the headers on the REST API call upon sending and for some reason, JIRA decided to retain them this time.