How to handle GOAWAY response

[Constantin Noll]

Hello,

I use the Jira ReST API to collect all users with their groups and roles.

Therefore, I call the search[1] to get all users and then I call each single user detail page[2] to get the roles and groups for the user. (If there is a better way, please tell me.)
From time to time, I get a GOAWAY response from the server.

When I do a retry, I get through in most cases.
But sometimes I don't.

I cannot figure out when a GOAWAY is supposed to happen from the API docs.

Is retrying the expected handling for a GOAWAY?
Then, I could increase the retry count.
I'd like to fix it the right way.

Kind regards
Constantin

[1] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-users/#api-rest-api-2-users-search-get
[2] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-users/#api-rest-api-2-user-get

[Hugo Navia]

Hi Constantin,

May I ask you to provide a bit more information?

It would be useful to know why do you need the groups and roles. Also, any chance you get access to the DB? It might be easier and faster this way.

Finally, I see on the side that this is for an OnPrem instance but the links you just shared are for Cloud instance. I'll wait for your reply.

By the way, the Rest API for Server/DC is this one:

https://docs.atlassian.com/software/jira/docs/api/REST/9.8.1/

Kind regards,

Hugo.

[Constantin Noll]

Hello Hugo,

thanks for your fast reply :)

I collect the data for our UAM tool.
This UAM tool queries more than 100 different systems and stores some basic account information. One of these systems is Jira, other are Servicedesk, Confluence, gitlab and so on.
We need to do so to get an overview which employees can access which systems and which rights do they have there in an automated way.

AFAIK the groups and roles contain this information for Jira and Servicedesk.

For servicedesk I also collect the organizations, this is a bit easier.
For organizations I can do a list all organizations, then get the members of each organization and map them.
The same would be possible for the groups.
But I don't see an endpoint to list the members of a role.
So I decided to query the user detail page to get the roles and as the page contains the groups, too. I also read the groups from there.

Obviously, this procedure creates a lot of requests.

I expected to get an 429 Too Many Requests response.
Some endpoints documented this. But I didn't.
Therfore I get a GOAWAY, which I cannot see in the documentation, maybe it's the same.



I had also preferred to get a direct DB access, but the other side preferred me to use the API :)

Thank you for the hint with the onPrem API documentation.
I corrected this in our documentation.
It seems that the endpoints we used stayed the same.

Kind regards
Constantin

[Hugo Navia]

Ok that clarifies things up.

So, the situation is a bit complex because of this:

1. Roles are objects created for the system that projects will use
2. Users and groups are assigned to roles per project and not in the system configuration
   • This means that you need to get the users and their roles per project
3. Groups might be assigned to roles which means that all users assigned to a specific group with specific roles will get the same role as long as they are part of the group.

Now, what you can use is a combination of the following APIs:

• Get project roles

GET /rest/api/2/project/{projectIdOrKey}/role

This one will returns all roles in the given project Id or key, with links to full details on each role.

Using this API you can trim the link and leave only the ID of each role. This is how it looks (id's might differ as this is how it looks in my VM):

{
"Developers": "http://localhost:8080/rest/api/2/project/12250/role/10001",
"Administrators": "http://localhost:8080/rest/api/2/project/12250/role/10002",
"Users": "http://localhost:8080/rest/api/2/project/12250/role/10000"
}

• Now that you get the roles ID's existing in a project, the following API will return all the users and groups assigned to each of the roles per ID:

GET /rest/api/2/project/{projectIdOrKey}/role/{id}

 This will return the details for a given project role in a project.

The result should look something like this:

{
"self": "http://localhost:8080/rest/api/2/project/12250/role/10001",
"name": "Developers",
"id": 10001,
"description": "A project role that represents developers in a project",
"actors": Array[5][
{
"id": 17780,
"displayName": "Group 1",
"type": "atlassian-group-role-actor",
"name": "GroupName",
"avatarUrl": "http://localhost:8080/secure/useravatar?size=xsmall&avatarId=10153"
}
{
"id": 16491,
"displayName": "User 1",
"type": "atlassian-user-role-actor",
"name": "username1",
"avatarUrl": "http://localhost:8080/secure/useravatar?size=xsmall&ownerId=ahpanganiban&avatarId=10330"
}

I think you should be able to build the rest as you will have the group names and user names assigned to different roles and, from there, use other API's to identify the users in each group.

I hope this is clear enough for you. Else, let me know and I will try to provide an example script, although it might take me a bit of time.

Kind regards.

Hugo.

[Constantin Noll]

Thank you a lot :)

It will take me a while to implement this way, but i think I got it.

For organizations and groups:
1. list all groups / organizations
2. list user in group / organization
3. done

For roles:
1. list all projects (api/2/project)
2. list all roles for each project (/rest/api/2/project/{projectIdOrKey} + /role) ->
3. list grantees for each project role (/rest/api/2/project/{projectIdOrKey}/role/{id})
    -> "type": "atlassian-group-role-actor" grantee is a group
    -> "type": "atlassian-user-role-actor" grantee is a user
4. list user in group
5.done

This not only reduces the number of requests, but creates a better data quality.
In my approach I missed the project roles.

The user profiles contain only one applicationRole, that is `jira-servicedesk`.
I don't know how I could get this one, but the role seems to be not interesting at all.
The project roles are the ones I need.

Thank you again
Constantin

[Hugo Navia]

Glad to know it helps you. I think you can also paginate the requests and also run the script as a session instead of making one call at a time. This way, you will auth just once and the rest will be a few calls inside one session.

I'm not sure If I'm clear enough (just waking up from a night with insomnia) 😅.

Let me know if I can help you with anything😊

Kind regards.

Hugo.

[Hugo Navia]

By the way, and before I forget. Do you need all the groups or only those that are being used?

I'm asking this because with just the second part you can get all of those groups that are being actually used in projects and the users as well, including the roles.

Kind regards.

Hugo.

[Constantin Noll]

It helps :)

I won't need the user detail page anymore, which saves me thousands of requests. (>6000 user)

This will show up in the execution time in the end.

And the data quality increased. The user detail page only contains one role which is an application role, but I didn't get the project roles at all.

To answer your question: I need all groups.
If I'd only collect the used groups the history could look like a group was deleted first and created later again.

Kind regards
Constantin

[Hugo Navia]

Awesome, glad to know it worked.

Let me know if I can help you with anything else.

Kind regards and happy coding 😊

Hugo.

[Constantin Noll]

Hi @Hugo Navia 

I reimplemented the code and saved 75% of time for our Servicedesk.
That's great!

The execution time ist dependent on the number of projects and project roles and not dependent on the number of users.

For our Jira I got a problem with the permissions and we don't know what permissions are needed to access the necessary endpoints.
In Servicedesk I got full admin access, but for Jira its more restrictive.

Can you help here? We want to keep the permissions as low as possible.
Maybe we can create a special bundle for this user.

Here is a list of endpoints I call during the collection:

1. [+] https://jira.congstar.net/rest/api/2/user/search?username=.
       Works and I get all data
2. [/] https://jira.congstar.net/rest/api/2/project
       Works, but I just see a "Personal Taskboard".
       I have to see all projects and also projects which gets added over time.
3. [-] https://jira.congstar.net/rest/api/2/role
       No permission.
4. [-] https://jira.congstar.net/rest/api/2/project/12500/role/10001
       12500 is the Personal Taskboard
       10001 is Teammember
       No permission.
5. [+] https://jira.congstar.net/rest/api/2/groups/picker
       Works and I get all data
6. [-] https://jira.congstar.net/rest/api/2/group/member?groupname=myGroup
       myGroup is a groupname I get from the call before.
       No permission.
7. [-] https://jira.congstar.net/rest/api/2/applicationrole
       No permission.

Kind regards
Constantin

[Hugo Navia]

These are the permissions you need:

• /rest/api/2/project
  • Projects are returned only where the user has Browse Projects or Administer projects project permission for the project.
•  /rest/api/2/role
  • Administer Jira global permission
• /api/2/project/12500/role/10001
  • Administer Projects project permission for the project or Administer Jira global permission.
• /rest/api/2/group/member?groupname=myGroup

  • Either of Browse users and groups global permission or Administer Jira global permission.

• /rest/api/2/applicationrole
  • Permissions required: Administer Jira global permission.

Those are the minimum permissions you will need to get the information you're looking for.

Let me know if you need any help with these.

Happy coding and kind regards.

Hugo.