Addon user restriction

[b...@site9.com]

We're testing the release candidate of our add-on in the OnDemand environment and I'm having trouble restricting access to the addon for a given project. My understanding is that this should be accomplished by simply removing the addon user from the project's permission scheme/roles.

My test project has the default permission scheme, which grants every permission to the "atlassian-addons-project-access" Project Role. I have removed the addon user from that Project Role for the test project, but the addon still renders and functions normally. I see that the addon user is also a member of the global "users" group, which also has some permissions on the project ( via the Users Project Role ), so perhaps that is the problem? It appears that the addon user cannot be removed from the "users" group.

[b...@site9.com]

Anyone have any insight on this? Am I missing something obvious?

[Patrick Streule]

Hi,

You are right: Connect currently puts the add-on user into the 'users' group to grant a basic set of permissions. If the add-ons asks for WRITE (or higher) scope, it is also added to the 'atlassian-addons-project-access', which grants more permissions (and the scopes take care of allowing or denying certain actions).

You currently cannot remove the add-on user from the 'users' group, and removing the project role for the add-on user from a specific project will only revoke the additional permissions (there are no 'negative permissions' in JIRA).

So if you want to prevent the add-on from any operations on that project, you'd unfortunately have to change the permission setup in a way that splits the 'users' group into a group of real users and add-on users and then only associate the real users with the 'Users' project role.

Regards,

Patrick

[b...@site9.com]

Thanks for the clarification Patrick. I ask because about a month ago I was trying to wire up a remote condition that would prevent our addon's primary web panel from rendering in specific projects. Seb replied that the new security scheme would handle my needs out of the box. Something was also mentioned about project-access eventually being part of the addon installation process. Is that still in the works?

https://groups.google.com/forum/#!searchin/atlassian-connect-dev/remote$20condition/atlassian-connect-dev/vi4oAnyxx1I/YRlab64i5qAJ

[Peter Brownlow]

Hi Ben,

If you want to make your add-on render only for certain users in certain projects then you can do that today. On your linked page you wrote "I'm trying to use a remote condition to limit access to our add-on on a per-project basis" and I have an ACE add-on that does almost exactly this.

If you put a remote condition on the web panel then you can decide at run-time whether or not to display. https://developer.atlassian.com/static/connect/docs/concepts/conditions.html

In my add-on I store per-project configuration, I have "{project.key}" in my "should display" endpoint URL and I return { "shouldDisplay": false } if configuration has not been saved for the specified project key.

The configuration that I am storing is a list of groups whose members are allowed to use the add-on. You could additionally add "{user.key}" to your "should display" endpoint and return false if the user is not a member of any specified group.

The JIRA REST endpoint to hit to get a user's group memberships is "/rest/api/2/user?expand=groups&username=<user>", which will return JSON representing a user. It contains a "groups" member, which is an array of group names.

For the GUI where the groups are selected I have this:

Here are some code snippets showing how to populate it:

    <form class="aui">

        <input type="hidden" id="project_key" value="{{project_key}}">

        <input type="hidden" multiple id="project-groups-select">

        <input type="hidden" id="token" value="{{token}}">

    </form>

    var projectKey = $("#project_key").val();

    var token = $("#token").val();

    var groupsSelector = $("#project-groups-select");

    groupsSelector.auiSelect2({placeholder: "Select groups",

                         multiple: true,

                         width: "copy",

                         query: function (query) {

        AP.request({

            url: "/rest/api/2/groups/picker?query=" + query.term,

            type: "GET",

            success: function(response) {

                var data = {results: []};

                $($.parseJSON(response).groups).each(function (index, group) {

                    data.results.push({id: group.name, text: group.name});

                });

                query.callback(data);

            },

            error: function(response) {

            }

        });

    }});

    groupsSelector.on("change", function(e) {

        var type;

        var id;

        if (e.removed) {

            type = "DELETE";

            id = e.removed.id

        } else if (e.added) {

            type = "POST";

            id = e.added.id;

        }

        $.ajax({

            url: "projectconfig/" + projectKey,

            type: type,

            data: { groupname : id },

            headers: {

                'X-acpt': token

            },

            success: function(response) {

            },

            error: function(response) {

            }

        });

    });

-Peter