Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

JIRA Cloud API returns 401 instead of 404

winterchillz July 12, 2024

Hi everyone,

I'm observing an odd behaviour with the JIRA cloud API when attempting to add or remove a watcher to/from an issue when the payload provided is not an accountId (ie, a username or an e-mail) as per the documents. 

The documentation states that if the user provided in the payload is not found, a 404 error will be raised, which is what I'd expect to see considering I've provided a malformed payload, however, the API instead returns a 401, which states that authentication credentials are missing, which is an incorrect error code given the circumstances.

This is what a valid call would be:

curl --request DELETE '<url of the instance>/rest/api/2/issue/<issue key>/watchers?accountId=<account ID>' --user <mail>:<token>

and, as expected, that returns a 204 code.

If you have happened to provide the wrong type of data for accountId (say, an e-mail instead):

curl --request DELETE '<url of the instance>/rest/api/2/issue/<issue key>/watchers?accountId=<email>' --user <mail>:<token>

I'd expect to receive either a 404 or maybe a 400, instead I get a 401 when my credentials are, in fact, valid.

2 answers

1 accepted

0 votes
Answer accepted
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 22, 2024

Hi @winterchillz 

If I understand the concern here is that this REST API endpoint in question is returning a 401 when supplying an email address, instead of a different error code like a 404. 

That particular endpoint is a bit different from other endpoints in the fact that each user can control their own watches, but there is an additional permission requirements are needed when managing any other users that might be watchers on that issue.

Unfortunately, the use of email address and/or full name has been deprecated for that endpoint for some time.  Only the account Id is officially supported now.   But I believe this can explain why supplying an email address here would return an authorization failure.   Any value supplied here that isn't that user's own account id would require the system to do a check to see if the user making the call has ALL the permissions needed to remove other user. 

That specific endpoint noted response changes due to GDPR changes.  Note that for the 'emailaddress' and 'displayName' fields, there is a note of "Depends on the privacy setting."  Even though you might be a site-admin and org-admin, and have the project level permission to manage watchers, the end user in Atlassian Cloud today have additional privacy restriction options whereby they can choose to hide their email address from the admins in some cases. 

Because of this privacy restriction, it's possible your account can't gain the permissions to lookup the user account by their email address alone via some REST endpoints, even though it might have been possible to do this at some point in the past before these GDPR changes. In this case, I expect that using the email address here would only be expected to work if the call is coming from that same user account OR the user account in question has selected to share their email address with you in their personal settings on id.atlassian.com

Moving forward, I'd always recommend using the account Id here.

I hope this helps.

Andy

Brant Schroeder
Community Champion
July 22, 2024

Thanks Andy

winterchillz August 1, 2024

Hey Andy, pardon the late reply, this indeed explains the behaviour, thank you so much both to you, for taking the time, as well as Brant for orchestrating the resolution to my query!

0 votes
Brant Schroeder
Community Champion
July 14, 2024

@winterchillz welcome to the Atlassian community

Are the credentials valid for that issue and what you are trying to do on that issue.  For instance are you able add or remove a user with the credentials in the application as a watcher.  Your credentials might allow you to login to the application but if you do not have the proper permissions on the Jira issue you would get a 401 error.

winterchillz July 15, 2024

Hi Brant, thank you!

The credentials are correct and contain the necessary permissions, the core of the issue I'm describing is the fact that the JIRA API returns the wrong HTTP code and I'm certain of that since providing the correct payload works.

Brant Schroeder
Community Champion
July 15, 2024

@winterchillz if you are getting the proper information back when you submit a proper payload and it is broken when you send in a missing watcher.  It sounds like a bug.  I would suggest submitting it here: https://jira.atlassian.com/secure/Dashboard.jspa?selectPageId=10440 

winterchillz July 19, 2024

Hey Brant, thanks a lot for the tip!

I tried to file a bug ticket but I got an error saying:

User '326843d41917' doesn't have the 'Edit Issues' permission
Brant Schroeder
Community Champion
July 22, 2024

@winterchillz It looks like the bug submission just goes to the Atlassian support page.  I will escalate it here since you are on the free plan.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events