JIRA Cloud API returns 401 instead of 404

winterchillz

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.

Andy Heinzer

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