Why do requests to /search via OAuth2 (3LO) fail in some cases?

Jira Development Jira Cloud
#1

I have three Jira OAuth apps (test, staging, and production) and have been using the REST API search endpoint for an external integration to fetch a specific set of issues. The JQL in the search endpoint looks like this: <issue property name> = <id>

<issue property name> is a searchable entity property that has been defined by a companion Atlassian Connect app (declared in the descriptor using jiraEntityProperties).

In my staging environment, the API request (via OAuth2 3LO) works just fine. I get the expected 200 response. However, in my test environment, I keep getting a 400 response saying

“Field ‘<issue property name>’ does not exist or you do not have permission to view it.”

I spent some time comparing all my configurations (OAuth credentials etc) but couldn’t find any setup differences. I also replicated the request to the /search endpoint with OAuth credentials in Postman for staging and test env with the same result - 400 response in test env and 200 in staging.

Does anyone have an idea why there is a discrepancy between my apps? @sreuter

I did find this paragraph in the guide on OAuth 2 (3LO), however, I am not clear if this is the reason - my searchable entity property is already defined by a connect app.

Apps can store and read the values of entity properties (issue properties and project properties) using the REST API. However, in the current implementation of OAuth 2.0 authorization code grants, apps cannot declare searchable entity properties. This means that if your app uses OAuth 2.0 authorization code grants, it won’t be able to refer to entity properties in JQL queries.

#2

Have you tried searching for your property in the UI as a regularly logged-in user? Does searching for other fields work when you authenticate with OAuth?

My suspicion is that this isn’t related to OAuth, but somehow to the Connect app installation. Is the Connect app installed properly on your test environment?

1 Like
#3

Thanks for your help @kkercz :+1: you led me in the right direction. It looks like there is an issue with my OAuth implementation, in particular with the accessible-resources endpoint. Calling accessible-resources returns 3 sites (in this case) and in my code, I default to the first one. Unfortunately, that’s not correct and that first site indeed does not have the Connect app installed. Instead, I’d probably have to ask the user in a UI screen which site he wants to use and inform them that they need the connect app to be installed.

It would be good if the callback from the OAuth flow could return the site that the user selected in the OAuth consent screen to avoid asking them again, but I don’t think this is possible?

#4

Yes, this is not currently possible. One way is to let the user select the instance manually in a screen, in which I think the same route as you are considering to do.

1 Like
#5

Thanks for confirming this @iragudo. That’s what I am going to do :+1:

#6

@iragudo One more follow-up question: I have been trying to revoke access to the connected app in Jira. I went to my avatar > Personal settings > Manage apps (under the section “Connected apps”, brings me to /plugins/servlet/oauth/users/access-tokens). However, for all sites I see this screen:

image
image1617×550 23.5 KB

How can I revoke access to sites? Accessible resources still returns 3 sites.

#7

I believe that’s a different screen, that’s for OAuth 1.0 that has been set via app links (or OAuth dance). The screen you are looking for is in Avatar > Profile > Manage your account > Connected apps or based on this doc, https://{subdomain}.atlassian.net/people/{account_id}/settings/apps.

Cheers,
Ian

#8

Ok that works, I thought I can revoke access for individual sites. However, it seems the screen under Avatar > Profile > Manage your account > Connected apps revokes the access to all sites for a particular app.

Awesome, thanks @iragudo!

1 Like