Personal Access Token in Confluence - Not working even when following the Developer Documentation

[Joachim Schneider]

Dear All,
I created a Personal Access Token for my regular user, not Admin. Copied the Token and tried connecting via curl as described on the page "Using Personal Access Token" in the documenation: 

curl -H "Authorization: Bearer <yourToken>" https://{baseUrlOfYourInstance}/rest/api/space?limit=10

This results in a 200 OK but without any data as follows:

{"results":[],"start":0,"limit":10,"size":0,"_links":{"self":"https://{baseUrlOfYourInstance}/rest/api/space","base":"https://{baseUrlOfYourInstance}","context":""}}

Tried it in Python: same result.

If I however log into Confluence in my browser and issue the rest api request, I get the results as expected - in this case a JSON listing of the first 10 spaces accessible for my user. I would like to avoid logging in with credentials from the commandline.

What am I doing wrong? Running Confluence 7.16.5 Self Hosted

[Oday Rafeh]

Hi @Joachim Schneider ,

It looks like your API request is working correctly, as you're receiving a 200 OK status code. However, you're not getting any data in the response. This might be due to permission settings for your Personal Access Token (PAT).

[Joachim Schneider]

Thanks for the insight. I am wondering where I would set permission for the PAT. As far as I understand from the documentation, the PAT should have the same permission as my user. When creating a PAT I cannot select any permissions, just create one. Also it seems that Confluence is unaware of the fact that I did use my PAT. I just discovered that in my settings dialog it says: "Last authenticated: Never" in regard to this PAT. So apparently curl -H "Authorization: Bearer <yourToken>" did not go through, which would explain the API answering 200 OK but with no data, as it did not authorize.

[Oday Rafeh]

Hi @Joachim Schneider 

it seems that Confluence is not recognizing the use of the PAT, as indicated by the "Last authenticated: Never" message in your settings.

One potential issue could be with the format of your PAT in the API request. Make sure that you're replacing "<yourToken>" with the actual token you generated, without any brackets or other characters. Also, check that you're using the correct endpoint URL for your Confluence instance.

And one thing more as I can see in your request

curl -H "Authorization: Bearer <yourToken>" https: //{baseUrlOfYourInstance}/rest/api/space? limit=10

You may try to use Basic in place of Bearer like this way :

Curl -X -H "Authorization: Basic [base64_encoded_credentials]" \ -H "Content-Type: application/json" \ "https: //{baseUrlOfYourInstance}/rest/api/space? limit=10

[base64_encoded_credentials] Here You need to encode your token + your email address

[Joachim Schneider]

Thanks a lot. I tried the approach with 'Authorization: Basic' even though the documentation clearly states "For the PAT authentication, you should only replace '<yourToken>' with the actual PAT. The "Bearer" part should not be changed, nor should you need to inform which user is making the request". I got the expected 404 result. For the "Authorization: Basic".

I did enter the Token correctly without any brackets ( no <> either) as displayed in my personal settings.

I also checked the endpoint in the Browser. When I log in via the Browser and type the URL as in the cURL command, I do get the first 10 Spaces visible for my user as a JSON object as expected.

[Joachim Schneider]

I created a PAT within Confluence and try to connect and authorize my script with it.

I get a 404 and "authorized":false on the CLI, but the URL works perfectly in the browser, giving me the expected result. I am wondering if a correct answer would include {"authorized":true instead of false. What am I doing wrong? I do follow the developer documentation. Confluence Version is 7.16.5

My code:

import requests
token = "YayToken"
myHeaders = {
"Accept" : "application/json",
"Authorization" : "Bearer " + token
}
confURL = "https://organizationalURL"
response = requests.get(confURL + "/rest/api/content/123456789", headers=myHeaders, verify=False)
print(f"Status Code: {response.status_code}")
print(response.content)
response.close()

I get a

b'{"statusCode":404,"data":{"authorized":false,"valid":true,"allowedInReadOnlyMode":true,"errors":[],"successful":false},"message":"No content found with id: ContentId{id=123456789}","reason":"Not Found"}'

In the browser however I get the correct content. Anyone?

[Paul Woods]

Did you get anywhere with this Joachim? I'm facing the same issue - I have a customer about to switch off basic auth for apps in confluence data center, and there doesn't seem to be any way to fetch data using personal access tokens.

[Joachim Schneider]

Dear Paul, unfortunately not. I had no time to follow up on the issue but all testing went in a direction that it just does not do, what it's advertised to do. When entering an API query in my browser, while logged in, everything works fine, so logging in with password, keeping the cookies and providing the cookies for subsequent API calls via curl will work, but that's exactly what I cannot roll out in LIVE as it will require the users passwords be stored in other places, which is unacceptable. That's where PAT would really come in handy, if they'd do, what they are supposed to do. But until now authorization: false is the answer.

I will try to setup a testsystem and probably have a look at the code in the next few weeks and post the results here.

Sorry I have no solution yet.

[Ken McClean]

FYI I just tried it with Joachim's code, and it worked fine for me:

import requests

token = "<token>"

myHeaders = {

"Accept" : "application/json",

"Authorization" : "Bearer " + token

}

confURL = "<url>"

response = requests.get(confURL + "/rest/api/content/12320783", headers=myHeaders, verify=False)

print(f"Status Code: {response.status_code}")

print(response.content)

response.close()


Please keep in mind that the token doesn't need to be base-64 encoded or combined with the username, unlike with Basic authentication.

[Levy, Jerry]

Well, I'm hitting it too, with curl (content ID obfuscated, but it is confirmed correct via a browser session):

curl -H "Authorization: Bearer <obfuscated>" -H 'Content-Type: application/json' https://my-server/rest/api/content/9999999999 | python -mjson.tool

returns:

{
"data": {
"allowedInReadOnlyMode": true,
"authorized": false,
"errors": [],
"successful": false,
"valid": true
},
"message": "No content found with id: ContentId{id=9999999999}",
"reason": "Not Found",
"statusCode": 404
}

Yet it does not fail with this query (same token), although it doesn't return anything of use:

curl -H "Authorization: Bearer <obfuscated>" -H 'Content-Type: application/json' https://my-server/rest/api/space?limit=10 | python -mjson.tool
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 171 0 171 0 0 1526 0 --:--:-- --:--:-- --:--:-- 1526
{
"_links": {
"base": "https://my-server",
"context": "",
"self": "https://my-server/rest/api/space"
},
"limit": 10,
"results": [],
"size": 0,
"start": 0
}

Any good way to troubleshoot why the "authorized" is false? Other ideas?

Thanks...

[Levy, Jerry]

Well, I ginned up a different PAT and it worked. Damned if I know: retried the old one, same length as the new one, double-checked that it wasn't a copy-and-paste error, but the new one is fine and the old one isn't, 
Moral of the story: if one PAT doesn't work, try another one...