Verifying users permissions - Jira modules conditions

Hello guys

While using Jira module, it’s project page, we use conditions to have conditional access to plugin resources. For instance, we may define what permissions user should have or what project property should contain. It works great unless user has directly link to our resource and there is a problem.

So, I’d like to know:

  • Does it should not work out of the box? Does all of these conditions should not be checked also before rendering the page?
  • How you guys, other vendors handle this case? For instance, we have to check all of these conditions on our server before returning destination view to user to prevent JWT leak.

I’d like to know your opinion and approach to the described case.

Cheers,
Kamil.

If I understand your question correctly, you want to ensure that the user can’t access a page that is rendered by your app unless they have the necessary permissions. You’ve discovered that declaring conditions on the relevant module in your app descriptor enables you to hide links to your page under certain circumstances; but users can still see the page if they enter the page’s URL in to the browser’s address bar. Is that correct?

In short, your app needs to check that any request it receives is authorised. That means you have to check that the user submitting the request has permission to view any content that your app returns. The conditions that you specify in your module declaration only affect the visibility of certain UI elements.

1 Like

You understood the question correctly and I understand that any received request has to be verified.

However, it would be great if Atlassian provides checking permissions mechanism before render the page. To be honest, we have to maintenance and remember about both of places (descriptor and own checking mechanism).

Furthermore, what if a plugin is simple frotend application and can not return anyother view without AP script? Will it not expose AP library for nonauthorized users and ability to access plugin resources e.g /rest/atlassian-connect/1/addons/{addonKey}/properties?

I am considering if it could not be out of the box feature.

Cheers,
Kamil.

One helpful thing is that you can include context parameters in your URLs: path parameters and query string parameters. Those parameters can include information about the permissions that the user has, populated by Jira Cloud itself. If the JWT from Jira validates correctly, then you know that information is reliable.

1 Like

Thank you!

I didn’t know I am able to use conditions and permissions in context parameters. It’s perfect, we wanted to prevent making the requests to Jira instance.

Cheers,
Kamil.

I try to include entity property context parameters in query parameters, but it seems impossible to use it with params. I’ve found the same issue here: Condition as context parameter, but the solution is still not known.

Maybe do you know how to pass params list? I’ve tried some combinations base on https://developer.atlassian.com/cloud/jira/platform/context-parameters documentation, but there’s no success result.

You have to declare your context parameters in the module definition in your app’s descriptor. For example, here is the definition of a dialog module:

    "dialogs": [
      {
        "key": "dialog-create-risk-register",
        "url": "/dialog/createriskregister?project={ac.projectId}&globalAdmin={condition.has_global_permission(permission=ADMINISTER)}",
        "options": {
            "chrome": false
        }
       ...

Then one can invoke that module from JavaScript using the Atlassian Connect JavaScript API; for example, AP.dialog.create.

What your app’s web service receives is a call to the URL specified in the module (/dialog/createriskregister... in our case), with parameter values provided by Jira Cloud.

There is no problem with basic variables. I try to use entity properties conditions, for instance: allowed={condition.entity_property_contains_any_user_role(propertyKey=any-property-key,objectName=name,entity=project)} . It does not work and allowed key in request is empty.