REST API for Agent Status requiring Admin contrary to Atlassian docs

[danielbernard_honeywell]

As an end user, I'd been hoping to use the Bamboo REST API for interrogating the status for some of my Bamboo agents (connected to a Bamboo Server instance; v6.10.4 build 61009), but I'm getting a 403 error; "You do not have global restricted administration permission".

This doesn't seem to match with the reference docs for that version: https://docs.atlassian.com/atlassian-bamboo/REST/6.10.4/#d2e806

Specifically looking at /agent/{agentId}/status interface, I would assume it should be a 401 error, not a 403, if I don't have permission.

Our server admin indicated he believed it required admin privileges to view agent status; is that accurate? I'm hoping we have something misconfigured, and you just need to be signed in.

If admin rights are required, is that something you would consider changing? As an end user, I would that that monitoring the status for my associated agents in an enterprise environment shouldn't require elevated permissions. Especially for agents that are dedicated to my project.

I can confirm that other REST API endpoints work to some degree:

[Hyrum Steffensen _Appfire_]

Hello Daniel,

When I did a search for "You do not have global restricted administration permission", I see this Atlassian Community post, which points to this Atlassian documentation on Bamboo permissions.

Regards,

Hyrum

[Hyrum Steffensen _Appfire_]

Hello Daniel, 

Here is a list of troubleshooting steps for a 401 error. Hope it helps!

As you know, message 401 is an “unauthorized client” error. For troubleshooting, please try the following:

Check the url you are using in the scripts.

While this seems obvious, it is a good thing to check because of the discrepancy between the expected url and actual url.

Check the credentials the script is using.

Is the username and password (or oauth) correct?

Have there been any recent organizational changes or changes in user permissions made to the Jira instance? Check that the username in the script has the proper credentials in the Jira user management section.

If you cannot see certain features of Power Scripts, such as the SIL Manager, SIL Listener or SIL Scheduler, check that the user (that may be you) has the proper credentials. User authorization tends to change after migrations (particularly Jira Server to Jira Cloud). Also check that the user has the proper group permissions.

Try using the same credentials to authenticate against the same base url using a 3rd party app such as curl or Postman.

[Cross Site Request Forgery (CSRF) protection]
Check for CSRF protection. For more information, see this Atlassian documentation:
https://confluence.atlassian.com/kb/cross-site-request-forgery-csrf-protection-changes-in-atlassian-rest-779294918.html
https://confluence.atlassian.com/doc/configuring-xsrf-protection-218276695.html

-------------------

Here are some other troubleshooting steps:

Clear the cache on your browser.

Try a different browser.

Sometimes differences in browsers make for unexpected results.

Try a different computer.

There may be some settings on your computer that may change the behavior of plugins.

Try a different network.

Problems often occur because of firewall issues or proxy connectivity.

Restarting Jira

Try connecting to the target url via Postman (do you notice any difference in connection speed)?

I particularly like this article from Geeks for Geeks website. It has a thorough list of troubleshooting 401 errors.

https://www.geeksforgeeks.org/how-to-fix-a-401-unauthorized-error/

[danielbernard_honeywell]

Thanks Hyrum for the response.

I can confirm that my credentials are not an issue, as other REST endpoints (including ones that require my specific user's permissions to view) function correctly within the same session, and when run from an alternate tool (different browser, and using cURL).

Please note that the error code is a 403, not a 401. I confirmed the status code presented in the browser matches the status code sent in the header:

$ curl --head -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/agent/<agent_id>/status
HTTP/1.1 403 
Date: Wed, 09 Jun 2021 14:02:35 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1i
X-ASEN: SEN-9325228
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Cache-Control: no-store
X-Seraph-LoginReason: OK
Cache-Control: no-transform
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=ISO-8859-1
Content-Language: en-US
Transfer-Encoding: chunked
Set-Cookie: JSESSIONID=<session_id>; Path=/; HttpOnly

 Here's the response:

$ curl -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/agent/<agent_id>/status
{"message":"You do not have global restricted administration permission","status-code":403}

Per the Atlassian Bamboo REST API reference material, this interface should not be able to return a 403 error, which is why I'm wondering if our server is misconfigured to restrict permissions.

I can also confirm the system recognizes my credentials

$ curl --head -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/currentUser.json
HTTP/1.1 200 
Date: Wed, 09 Jun 2021 14:10:04 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1i
X-ASEN: SEN-9325228
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Cache-Control: no-store
X-Seraph-LoginReason: OK
X-Content-Type-Options: nosniff
Content-Type: application/json
Set-Cookie: JSESSIONID=<session_id>; Path=/; HttpOnly

$ curl -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/currentUser.json
{"name":"<id>","fullName":"Daniel Bernard","email":"<email>"}

And similarly for other permission-protected endpoints:

$ curl -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/permissions/project/plan/<project>/users
{<valid_response>}

$ curl --head -H "Authorization: Bearer <token>" https://<bamboo_url>/rest/api/latest/permissions/project/plan/<project>/users
HTTP/1.1 200 
Date: Wed, 09 Jun 2021 14:35:50 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1i
X-ASEN: SEN-9325228
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Cache-Control: no-store
X-Seraph-LoginReason: OK
X-Content-Type-Options: nosniff
Content-Type: application/json
Set-Cookie: JSESSIONID=<session_id>; Path=/; HttpOnly