Important Change to the /rest/api/$/user endpoint coming soon for Jira Cloud

In order to improve security guarantees on the Get User REST API endpoint in Jira Cloud, this endpoint will now require the calling user to have the Browse Users and Groups permission to be able to access results. We are updating the API to enforce this requirement.

What this means for Apps?

If your app is accessing the endpoint using User Impersonation then the user that is being impersonated will require the browse users and groups permission to access this endpoint going forward.

Example request:

curl --request GET \
 --url '/rest/api/2/user?accountId=5b10ac8d82e05b22cc7d4ef5' \
 --user 'email@example.com:' \
 --header 'Accept: application/json'

Forbidden response status code:

403

This means that if your app used this functionality, and your users have restricted browse users and groups permissions, they may notice a change in the way your app behaves. You should ask them to request the administrator gives their user browse users and groups access in Jira global permissions .

If your connect app is accessing the endpoint using the Application User the app will continue to require READ Scope as is currently the case, and you will not see any difference to how your app functions.

This change is now available to all who have signed up for Jira Cloud Vendor First Release Group.

If you’d like to see these changes on your instance first, before they go out to customer instances, please ensure you are enrolled in the Jira Cloud Vendor First Release Group - you can sign up here.

I’m not trying to be a pain but another thing I need to sign up for? While I can’t speak for other vendors all I want is:
A) be able to have one instance that has all upcoming potential changes that might break me as soon as it’s available.
B) one instance that gets the changes first when things roll out.

This sign up for this, oh sign up for this is seriously worrisome. It seems to be a lot of waste of everyone’s time to me (both mine and Atlassian’s)

Edit: the above stuff had rant tags.

Now to this change - will this be documented somewhere? Will a user be able to look up their own group?

10 Likes

Oh. Timelines for this to be rolled out?

3 Likes

If you already have an instance you signed up on the Ecosystem Beta Group list then this Jira Cloud Vendor First Release Group is the same thing. Our apologies for that not being clear. There was a rename of the list recently to better align that it’s not beta functionality you’re signing up for but to be in the first cohort of the release.

3 Likes

How about until Atlassian can give us a reliable platform to understand what you’re shipping to our instances, you put breaking changes on hold?

Use the functionality being built for Enterprise Cloud, show us what features are enabled on our instances, allow us to toggle them, we need to be able to test various combos. This whole process we’re dealing with is ridiculous. Would Atlassian accept this type of behavior from AWS as a platform vendor?

Edit: before you give me a generic “we’re working to make things better” response again, here’s a question:

How many changes requiring opt-in have you rolled out in the last 3 months? How many of them were breaking? If this is hard to answer, then you have a serious problem. We’re talking basic change logs here.

And think back to how the CSAT numbers are trending.

11 Likes

I’m not trying to be a pain but what’s the difference between that and Stateful Project in Jira Cloud - sign up for feature preview ?

2 Likes

We agree with @boris.

We do have a meeting scheduled for the end of next week about a working escalation path with @WarrenChen who has been great about setting that up at our request.

This need was known but made all the more evident by such a roll-out which broke two of our top apps for 9 hours. It took two hours to get Atlassian attention.

I state this here as a specific example and extra reason to freeze breaking changes.

4 Likes

Currently we are using /rest/api/2/user?accountId={accountId} with user impersonation in several places to get the information about the current users (where accountId parameter is set to the current accountId). Theoretically we could replace it everywhere with /rest/api/2/myself but it would be nice if you could allow user requests for impersonated users when they request information about themselves.

2 Likes

What Raimonds said.

Can we please get a customer facing document that our support team can direct users to?

We have similar scenario as @raimonds.simanovskis. We are making /rest/api/2/user?accountId={accountId} and /rest/api/3/user?accountId={accountId} call at multiple places as an add-on. AccountId - is the currently logged in user. We are using atlassian-connect-sprint-boot/ atlassian-connect-express framework for our apps. Will the add-on be able to get currently logged in user information via above API?

How can I get to Ecosystem Beta Group?

@aagrawal2 Is this change of the user endpoint also coming to Confluence Cloud?

Thanks @rwhitbeck couldn’t have put that better myself.

We’ll be using (and re-using) this vendor first release group for all Jira releases so y’all get updates FIRST, so if you’re not already signed up please get yourself signed up.

If you are signed up then you don’t need to do anything.

So just answered my own question (since nobody from Atlassian has spoken up). An app that has “act_as_user” scope cannot impersonate a user and have it look up that user’s own group. We’re going to be adding in a check in our front end that basically says “Have the admin add the permission to you or contact Atlassian Support”.

It would be nice though if we could get a permission that is just for browsing groups (and I’m guessing other apps might need users browsing) since the current browse-user-groups permission is very broad (and abused by Jira itself it seems). I would put in a feature request - but not sure where (and pretty certain that it would just sit there).

Would be nice if somebody from Atlassian would speak up and how they view the impact of this change will impact apps (because I would think they can look at the traffic patterns for the data calls) as well as what they’re doing to minimize the impact?

Or is Connect just dead? (slight tongue in cheek comment - but I am starting wonder about the investment Atlassian is doing into it).

2 Likes

@nmansilla since this change seems to break Automation for Jira as well - can we get an understanding on how Atlassian will be tackling the problem there so that we can follow suite?

1 Like

Hello @aagrawal2 / @rwhitbeck

Will this change affect following scenario :

  • App built using atlassian-connect-framework with READ/WRITE scope
  • App built using atlassian-connect-express with READ/WRITE/ADMIN scope.
  1. Does the add-on-user have ‘Browse Users and Groups’ permission if the plugin have above scopes?
1 Like

One of our team members requested for their system to be added to Jira Cloud Vendor First Release Group but we have not heard back. Is there any process to check if this has been enabled?

1 Like

Hello,

  1. Obviously I am joining to the question of @sfg: we have atlassian-connect application which provides PluginDescriptorResponse to Jira Cloud containing the field “scopes” with the values
    { READ, WRITE, ADMIN, PROJECT_ADMIN, DELETE, ACT_AS_USER }. Our app manipulate Jira Issues (create, update, delete and assign) on behalf of the users. Also, it searches or users and gets users lists. As I understand these user search and get operations are running on behalf of the “add-on user” which has “ADMIN” privilege. Can this app need additional “browse users and groups” privilege or an appropriate new scope to be added?

  2. Is there any planed time for this change?

We’re still waiting on this. Requests via the AppWeek Slack have gone nowhere. @nmansilla / @mpaisley / Not sure who else… This is whole process is insane.

Edit: got this resolved via AppWeek slack. I think the right approach here is don’t test anything, when stuff breaks tell customers Atlassian isn’t serious about supporting developers and fix in prod. Apparently our repeated feedback about the low quality of the developer experience isn’t statistically significant.

1 Like

Hi Ivan,

Yes, we are aware of this solution. It might come up in the future, as we have yet to analyse the effort needed on that, but there are no plans as of yet for near future.

Cheers.