JQL queries containing issuekey or issue will have the error messages and response code changed

Jira Development Jira Cloud Announcements
,
1

What is changing?

JQL queries with issuekey or issue will be returning different error messages and status codes in case of nonexisting project or lack of permissions. The unauthorized user will get 400 status and message: "Issue does not exist or you do not have permission to see it.” instead of current behaviour where the error message exposes the existence of project/issue. The change also introduces warning messages for searches like issuekey in (…) where one or more of the given issuekeys do not exist. With the new behaviour, the user will get the response with status 200, existing issues, and the warning message with information about the issues that could not be found instead of failing the whole search as it was done till now.

Why is it changing?

This change is presented to prevent the possibility of enumeration issue keys and identifying project existence. After this change is rolled out, there will be no way for unauthorized users to recognize whether the issue/project does not exist or they have no permission to see it.

What do I need to do?

If your app uses JQL queries containing issuekey or issue you should check whether, in case of searching for a non-existing issue or issue that is not permitted to be seen, your app will handle the response correctly.

By when do I need to do it?

Because this is related to a security vulnerability with a short SLA, we will be rolling out this change in 1 month. Please have your apps updated by 2021-06-24T22:00:00Z.

4 Likes
2

Hi there,
Can you give some examples of what we’ll be seeing?

In the case where I submit a request to /rest/api/3/search with a jql of IssueKey in (ISS-23, ISS-25) if my user is blocked from seeing ISS-25 - what’s the payload I will get? I would assume that I would still get ISS-23? Or will I get a 400?

What’s the timeline for the Developer First Rollout tenants to get this?

3 Likes
3

Hi, thanks for bringing the question!

Yes, the behaviour that you presented in the scenario is the desired one.

In case of a user having permissions for ISS-23 and with no permissions for ISS-25, request to /rest/api/3/search with a JQL like “IssueKey in (ISS-23, ISS-25)” will result in the 200 status, fully detailed ISS-23, and the proper warning message telling about the ISS-25.

Answering your second question, it is going to be enabled for Developer First Rollout tenants in early June.

1 Like
4

Hi @BartoszCzerwonogrodz ,

  1. We could see this error being returned for 2 of our customers. It might have been an unintentional early rollout and it looks like it prevented customers from using the search with any issue keys. Let me know if you’d like to get more information.

  2. How can we get access to Developer First Rollout Jira instance?

Did I understand correctly that for issuekey=NOTTHERE-1 Jira will return 400 but for issuekey in (NOTTHERE-1, IMTHERE-1) I’ll get a 200 with IMTHERE-1 in results?
How about issuekey=NOTTHERE-1 OR issuekey=IMTHERE-1 and other variants?

  1. Are there any changes in the behaviour of id in (...) searches? Currently the search becomes non strict if there are more than 25 issue ids in the list.

Thanks!

2 Likes
5

Answer to my question 2. is this form Jira Cloud: Developer-First Rollouts for Ecosystem App Developers

2 Likes
6

Hi! Thanks for your interest!

Let’s go with the questions:

  1. "Issue does not exist or you do not have permission to see it.” - this is not a new error message in Jira, so there is a pretty big probability to meet it when playing around with JQLs. We are confident that the change was enabled only on our internal instances and did not touch the customer instances. Yet, if you feel that your customers did not spot anything like this before, we will be more than happy to get your feedback.

  2. I am glad that you were able to handle the second one on your own.

  3. Exactly, going with issuekey=NOTTHERE-1 the user will get 400 and the errorMessage.
    In case of issuekey in (NOTTHERE-1, IMTHERE-1) user will get 200, IMTHERE-1, and the warningMessage about the NOTTHERE-1. The change here is that there will be no longer a whole search failing because of one missing issueKey. In other words, if there will be even one existing issue (IMTHERE-1) the user would have permission to see the whole search will result in 200 and the issue (IMTHERE-1).
    As it goes about issuekey=NOTTHERE-1 OR issuekey=IMTHERE-1 - same story here, all the existing issues will be returned with 200 and warningMessage for the non-existing/not permitted or 400 and the above-mentioned errorMessage in case if there will be no existing/permitted issues found.
    As it goes about issuekey=NOTTHERE-1 OR issuekey=IMTHERE-1 - all the queries with “=” operator will be failing with 400 in case of a non-existing issueKey. The change here is that the wrong project key will also cause failure.

  4. Could you please elaborate a bit more here. I do not know if I understand you correctly.

Hope I cleared it up a little.

1 Like
7

Thanks for your response.

1 - I thought that this is a new message. No issue then.

4 -
At the moment the following query fails with errors
id in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25) because none of the issue exists.
It’s enough to provide more than 25 ids for the query to be accepted: id in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26)

Please do not change this behaviour :wink:

8

Oh, now I see what you mean, so the new behaviour will be consistent with the current one in this matter. To say it at loud, for JQL like id in (...) and the number of passed non-existing ids <=25, it still will fail with the errors. Passing >25 ids will be going smoothly.

The only change in here is going to be with the case when there will be 1 existing issue among those <=25. In a situation like this, there will be status 200 returned, 1 existing issue, and the warning messages for the rest. Same story with the >25 but without the warning messages.

9

Hey @BartoszCzerwonogrodz ,
Thanks for confirmation.

My Jira instance is now enrolled in Developer First Rollout but this query:
https://MYJIRAADDRESSGOESHERE.atlassian.net/rest/api/3/search?jql=key in (SP-19,SP-9999)
returns {"errorMessages":["An issue with key 'SP-9999' does not exist for field 'key'."],"warningMessages":[]}

This query returns 200 with SP-19 in the results:
https://MYJIRAADDRESSGOESHERE.atlassian.net/rest/api/3/search?jql=key in (SP-19)

SP-9999 is a made up key. I guess the first query shouldn’t reveal the information about existence of SP-9999 and it should return 200 and SP-19 in the results?

10

Good timing, the change has been just enabled for the Developer First group, so now you can play around and feedback will be appreciated.

Please note that there were some changes in the behaviour that you asked in question number 3 - see the changes in the previous post.

1 Like
11

Announcement

2021-06-10T22:00:00Z 2021-06-11 the change is now enabled for the Developer-First Rollouts group.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.