Fine-grained permission system

[robocoder]

Superuser can define what a non-superuser can or can't do. Examples:

• can change password
• can change email address
• can add/modify/delete sites (who already has at least admin access to one or more sites)
• can add/modify/delete other users
• can use token_auth with REST API
• ...

(Some of this might overlap/conflict with the existing access sytem.)

Can be applied to an individual user or all users.

[gka]

By now it is only possible to allow or deny full viewing access to sites. Is it possible to limit the viewing access to certain plugins? This would be very helpful for anybody who likes to embed a single widget on a public page. Maybe we can introduce auth tokens that are limited to certain plugins?

[robocoder]

IIRC widget-specific access was discussed in #283.

[robocoder]

See Zend_Acl.

[mattab]

Proposed settings to add in Piwik core:

• Allow Admin users to create websites default
• Allow Admin users to create other users default
• Allow Admin users to see all other users (and assign permission) default - see New admin setting: Should admin users see the list of all users in Piwik? #2028

See also #1148

[anonymous-matomo-user]

Attachment: Patch for SitesManager plugin. Now simple Administrators can add new sites to track.
SitestManagerPatch.txt

[anonymous-matomo-user]

Hello from Codax team, Russia. We'have just posted the patch for core for the 'SitesManager' plugin.

So it allows Admin users to create websites they wish to track.

Check out the attached file.

[anonymous-matomo-user]

Hi,
I just want to support a more detailed permission system in which an admin is able to restrict view access.
In my case I want to deny view access to 'Ecommerce & Goals' for a specific user.

[robocoder]

Idea:

• add an access table that defines menu layout and access to controllers (and optionally, individual actions):

class Access {
    int id;
    string name; (either plugin or plugin+controller)
    string action;
    string label; (for menu items)
    Access parent;
    priority int; (for ordering menu items)
    string authorization; (user defineable via a GUI)
} 

• subscribe to FrontController.dispatch event; hook will pass through the request if authorization string is undefined (backward compatibility); returns 403 if authorization string is defined and user doesn't have authorization
• core/Menu/* - check authorization before adding menu/submenu items
• some of the existing checks would move into the Access table; remaining programmatic checks, such as Piwik::checkUserIsSuperUserOrTheUser(), will still have final say (for BC)
• an Authorization service to encapsulate the isAuthorized() logic

administrative UI should manage:

• access table
• role assignment and hierarchy
• menu access preview (by user or role)

[sebastianpiskorski]

+1 on this one

[sgiehl]

closing in favor of #21175