ACE app can't get user data for particular user

Confluence Development Confluence Cloud
,
1

Hello everyone!

We use the following endpoint to retrieve user permissions: https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-users/#api-wiki-rest-api-user-current-get. For us and most users, it works well, but for a particular user, it always returns the following error:

‘Endpoint for getting current user can’t impersonate the user because no valid active user exists.’

We are using the ACT_AS_USER permission and sending a signed request back to the host as described in the ACE repository: Bitbucket.

How can this problem be fixed?

Thanks in advance for your help!

1 Like
2

Make sure you are not trying to impersonate an app user. You can’t even impersonate your own app user. In case your app is triggered by an app user, make the call as app instead.

1 Like
3

Thank you for your reply. I double-checked, and I’m sure it’s the user. I don’t see any problem with his account, except that this account uses an old type of userAccountId as described here - Rest API | custom field format for single-user and multiple-user is out-of-date - #7 by ibuchanan.

What’s strange is that this user sent the request from a browser to this endpoint and received data from the endpoint without any issues."

4

Possibly related: there is a bug in ACE’s generation of qsh that causes requests to fail from the back end when legacy userAccountIds are used directly within the URL path. This happens because ACE has a different understanding of which characters (such as “:”) are expected to be URI-encoded. This does not seem to be the case for your code though.

I see that you’re using ACT_AS_USER to call /wiki/rest/api/user/current. You might try ACT_AS_USER with /wiki/rest/api/user?userAccountId=<account> instead, as well as the latter call but without ACT_AS_USER, to see if you can if you get any different results that narrow down the source of failure.

1 Like
5

Thank you for the answer. I will check how it works. As I understand it, this endpoint can be used without user impersonation, so my problem should be solved. However, it’s still strange that the endpoint we used before doesn’t work.