Hi, I want to secure some endpoint in my Connect app by checking if current user is Jira administrator. The codename of corresponding global permission is “ADMINISTER” (got it from /rest/api/2/permissions). I’m trying to use /rest/api/2/user/permission/search with combination of account id, the permission and project / issue key but it works only for project permissions - when I check for global permissions the endpoint says that “Invalid permission name specified”.
Does anyone encounter such a problem and / or found a solution? Is there any other way to check if given user is Jira admin? I cannot use context query string parameter because, as I mentioned, I’m not trying to secure a Connect module, I’m trying to secure custom REST endpoint on my server.
Unfortunately, this endpoint requires ACT_AS_USER scope.
In some other thread, we agreed with @kkercz that ADMIN scope should be enough for apps to check users permissions. That is because Jira UI allows administrators to check other users permissions.
ACT_AS_USER is more for acting as users (adding comments, logging work, ets.), while checking permissions is more ADMIN type of work.
I hope you guys can fix this hole because we are not able to protect our app properly without decent permissions API.
No updates on that?.. That’s frustrating. The app should be able to check permissions and groups without admin and act_as_user permissions. Both have too much power with no good reason for that. That’s just insecure and looks ridiculous since now Atlassian pushes Cloud and Security.
We’re having to move a lot more of our api calls to be ACT_AS_USER for read only access due to the changes that’s happening to the rest api. Ideally that scope would be broken down into more levels (ACT_AS_USER:read, ACT_AS_USER:write etc).
It sure would be nice if we could get more scopes in general though (such as “request_permission_levels_for_any_user”.
I’m afraid I don’t know of any near-future plans in this area. But this is definitely a valid feature request, so I would suggest creating a ticket in ACJIRA for us to properly track it and gauge interest.
In addition to that, let me say that we are aware that the current set of scopes available to apps is too coarse-grained and does not allow apps to properly define their intent to customers (e.g. if the app wants to check if someone is a global admin, then perhaps it shouldn’t have to declare scope “ADMIN”, but – maybe – “CHECK_PERMISSIONS” instead). We are hoping to improve this situation eventually, but it’s too early to provide any details or timelines.
@raimonds.simanovskis that’s true, but I need to secure custom REST endpoint that is provided by my app’s server, so I can’t use descriptor here. I can pass the query string param to the frontend, but I want to secure backend as well so that any malicious users won’t be able to use my REST endpoint.
@raimonds.simanovskis yes it’s possible solution. But this is not appliable for app’s API. So I have to introduce some kind of sessions to be ensure that my API called within context with admin user. It’s ok but it looks like unnecessary complication.
@thomas1 unfortunately it’s not an option. Users can tweak product access for different groups. So it possible to setup the instance where site-admins (or jira-administrator or anything else) will not have access to administer pages at all
it is indeed a very good news, thanks for extending this endpoint! I checked it and it works like it should.
The only problem I see is that it’s not possible to check permissions of anonymous users. Are there any plans to extend this endpoint so that it covers also this use case?
Hi, I would like to propose another solution to the problem that most of the marketplace vendors have, i.e. authorization of the custom endpoints in ac-express and ac-spring-boot frameworks. However, it would require Atlassian help.
What we really need is a secure way to check whether our endpoint is called by a user with the same roles that are defined by conditions used in connect modules in atlassian-connect, i.e. user_is_admin, user_is_project_admin, user_is_logged_in.
Basically, we want to restrict our endpoints in the same way we restrict access to the pages/panels where they are supposed to be used.
We could have that information in a token received by AP.context.getToken(). This token is sent to app’s server anyway and it contains context claims already, e.g. issueId, accountId, etc. This token is decoded on server side, context claim would need to be exposed by ac-express, ac-spring-boot, but this is already happening: https://ecosystem.atlassian.net/browse/ACSPRING-88
It would be secure and wouldn’t force us to declare scopes that we don’t need, what is more it, calls to mypermission would no longer be needed. Right now, most vendors avoids securing their endpoints being afraid that it will impact apps performance. 1 more call to Jira on each endpoint. You could say permissions can be cached, but that solves 1 problem and at the same time introduces many more.
At the moment there’s the possibility of checking anonymous user permissions by making a request as an anonymous user without providing an account ID. I don’t know about any plans of extending it any further at the moment.
I hope that solves your problem, if not I’ll try to look some more into it.
@MaciejStanuch you’re right, I was able to get permissions for anonymous users but I had to omit both accountId in the request’s body and Authorization header. When the header was present but no accountId then returned permissions were for user / addon represented by Authorization header.