I’m developing a plugin that manages custom attachments. Users can add a specific entity to the issue and it builds in an issue edit dialog.
When a user creates an entity, in fact, the request goes to our server and the request has an issue id as a parameter. The user shouldn’t be able to attach an entity to the issue he doesn’t have access to. Meanwhile, malicious users just can reproduce the same query with another issue id parameter created by that attachment to the issue he is not supposed to touch or even see.
That is the task - we need to verify if the user has access to the issue using Atlassian api.
The first thing that comes to mind is to check the issue with API https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-get
But it returns the whole issue info nevertheless if the user can access it or not.
Meanwhile, the request is not anonymous. We include into JWT token, it looks this way
{“iss”:“com.myapp.integration.jira”,“iat”:1636665790,“exp”:1636694590,“qsh”:“somehash”,“sub”:“5f9122b229bd8a006f7bfd05”}
If you want to check if the current user has certain permissions for a given issue or project, you might want to check Get my permissions API.
If you want to verify another user’s permission, maybe Get bulk permissions can help - here, you can pass the account ID of the user whose permission you want to check.
Thank you for the response! It answers the initial question, but I believe I have another issue.
Get my permission API works the same for me - it says that actions are allowed for the issue.
For “Get bulk permissions” we need to have administrator privileges that my users don’t have.
Meanwhile, I have a “sub” field in my jwt token which refers to the user. One has access to the current project/issue, another doesn’t. And all API methods behave like both users have access.
The first part of the token decodes this way
{“typ”:“JWT”,“alg”:“HS256”}
The second one is
{“iss”:“com.myapp.integration.jira”,“iat”:1636967319,“exp”:1636996119,“qsh”:“321d88fa83e504209fbfadc07287e1c8d5ed28f8651d030468f442cb0c23c0fe”,“sub”:“5f9121b229bd8a005f7bfd05”}
If there were problems with iss/iat/exp/qsh, it should react with authorization error.
But for some reason it works absolutely the same even if sub is not defined. Random sub causes 401 error, it means that is is taken into account somehow. Maybe there is some place where I need to mention that sub is mandatory for me?
Can it be an Atlassian API bug, or is it on my side only?
Meanwhile, I have a “sub” field in my jwt token which refers to the user. One has access to the current project/issue, another doesn’t. And all API methods behave like both users have access.
This is an interesting case. Not yet sure if this is an Atlassian API bug, but for me I’ll do the following checks first:
If I know the email and API token of both users (assuming test accounts), I’d call the API via CLI curl or postman, just to validate that the API is working fine. If indeed it returns both users have access when they shouldn’t, then you might have a reason to believe that this is a bug. If curl results that one user should have access and the other do not (as expected), then try (2)
Just to be absolutely sure that you’re passing the correct user in your requests, I’d call a Get current user for both users in your app (using the JWT). Sometimes the reason why an API returns the same results when they shouldn’t is because the user is actually the same. Actually, the two scenarios in your first post might point to this one.
Are you using a connect app? If so, what scope/s are you using?
Top of mind, these are the three things I will verify. Hope at least one of these can help you out.