Hi, our Connect app performs edits on pages. If the user sets page or space restrictions (only allowing certain users to edit a certain page or pages in a space), then our app’s system user is no longer able to edit the page. This is unintuitive for our users, since the app has the “read” and “write” scopes and is expected to have global access to the Confluence instance.
Is this behavior expected? We feel it would be more intuitive if Connect app system users can bypass all page and space restrictions.
We know of two possible solutions to the current situation:
- The user must give our system user explicit access, when using restrictions on a page/space.
-
User impersonation: we have not tried this yet since it requires an additional scope for our app.
Are there other solutions? Or is the current behavior indeed unexpected? Thanks!
1 Like
@MareinKnings yes the behavior is expected . The suggested solutions seem fine and either way an explicit access or an impersonation should help you achieve page edits by your connect app.
Cheers
2 Likes
+1 to @JatinChopra’s response @MareinKnings. Consider what the documentation says about security for Connect apps:
- Authorization via scopes and app users : Scopes are permissions that are defined in the app descriptor. The app has its own app user with permissions controlled by the admin. The set of allowed actions is the intersection of the scopes and the permissions of the app user. This is the normal authorization method, which you should use unless you need to make server-to-server requests on behalf of a user.
We’ve certainly tried to explain our design intent that “Apps are people too!” At the very least, you have some docs to which you can point confused users and then they can share their confusion with us.
1 Like
Thanks @JatinChopra and @ibuchanan! We’ve opted to try out User Impersonation and this method seems to be a good solution for us (with so far one caveat for which I’ve created a new topic).