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.
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.
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.
I tried using this endpoint to retrieve information about a user. While it works normally for other users, it fails with this one, returning the following error:
{data: {authorized: False, errors: [Array], successful: False, valid: True}, message: com.atlassian.confluence.api.service.exceptions.PermissionException: User not permitted to view user profiles, statusCode: 403}
As I understand it, if I make this request from the application user, I should have access to all users if I have “READ” permission. Could you please provide a link to the bug regarding legacy IDs?
Unfortunately, I do not know if there is an official bug logged for the legacy ID issue–it’s just something I have noticed myself when developing apps for the platform. (Note that I do not work for Atlassian.)