Connect: Permission exception when setting space permissions

A month ago a new endpoint was shipped which allows space permissions to be added via user impersonation.

Doc: https://developer.atlassian.com/cloud/confluence/rest/api-group-space-permissions/#api-api-space-spacekey-permission-post

For the impersonated user all permissions are set:

Payload:

{
  subject: { type: 'user', identifier: '5e3352d0e504e30cabd3e0e4' },
  operation: { key: 'read', target: 'space' }
}

StatusCode: 403
message: com.atlassian.confluence.api.service.exceptions.PermissionException: User isn't authorized to modify permissions.


Additional question:

The api docs specify that: This object represents a single space permission. Permissions consist of at least one operation object with an accompanying subjects object.

  • Does this mean that we can create/update multiple permissions at the same time? Is there an example for it?
  • what is the id field for in the post field? This should not be set by us as it is assigned by atlassian anyways?
  • The example is broken. The operation key: administer and target: page are a non valid combination.
2 Likes

I just had a two week long back and forth conversation with the support and will post their answers here to provide more clarity for everyone else looking for the same information. Bold are my comments.

  • Does this mean that we can create/update multiple permissions at the same time? Is there an example for it?

" It is not possible as of now, as Atlassian hasn’t provided the option. The only way is to create a script that could get executed recurringly for every user. "

  • The example is broken. The operation key: administer and target: page are a non valid combination.

" In the example, it is not shown as a combination but just a presentation among all the available options" I still think developers would benefit much more from actually runnable examples instead of these more or less valid schemas. But this is a different discussion.

  • what is the id field for in the post field? This should not be set by us as it is assigned by atlassian anyways?

You can leave it or fill it by yourself. If you won’t fill it, the system will it up by itself." I assume that it is always a better idea to leave it blank, otherwise you might run into collisions or atlassian does nto accept it at all.


And now to the core question:

StatusCode: 403
message: com.atlassian.confluence.api.service.exceptions.PermissionException: User isn't authorized to modify permissions.

I checked internally to confirm the same and I shall inform you that this API resource doesn’t work by the connect apps (not even while user impersonation).
If you see: Ecosystem Roadmap for developers - #10 by BobBergman, you can find that it states that “Apps cannot access this REST resource.” .

This means the endpoint is dead for connect apps. @ElaineH has commented in the very next post that “For Connect apps, OAuth 2.0 user impersonation” provides a user context. The trello card (Trello) also says Oauth2 impersonation is supported. Non connect RESTCalls with API-Tokens and basic auth grants access to this resource, which does not require more user involvment than installing an app with ACT_AS_USER permission. Therefore, for me it is either an oversight by the developers or simply a bug.