Overriding Roles / Permissions

[ADobkin]

In the wiki page documenting the permissions.ini file, there is a section on overriding existing roles. I have tried using this feature many times, but have not yet been able to get it to work properly. I am wondering if there are some limitations with what I am trying to do, since I am more interested in using this to restrict/revoke existing permissions rather than adding new ones.

For example, let's say I want to remove the "find" permissions from the READ ONLY role. I put the following in the main permissions.ini file for my application (not in the xataface directory):

Code: Select all

[READ ONLY extends READ ONLY]
        find = 0
        find_list = 0
        find_multi_table = 0


However, the find action still shows up and works, indicating that this configuration is being ignored. Is it supposed to work this way, or am I misunderstanding the intent?

Thanks,
Alan

[shannah]

That should work. Double check that your user is actually getting the READ ONLY role on that table.

[ADobkin]

You are correct. It does work when I explicitly set the user for the READ ONLY role. However, I was using the role USER, which is extended from READ ONLY in the original Xataface permissions.ini file. That seems to be the problem.

So, if I override a basic role that is used (extended) in other roles, shouldn't that carry forward to those other roles?

[shannah]

Unfortunately roles are extended by way of a copy at the time it is loaded in. So if you have:

Code: Select all

[ROLE1]
   a = 1
   b = 1

[ROLE2 extends ROLE1]
    b = 0

[ROLE1 extends ROLE1]
    a = 0


Then ROLE2 is effectively:

Code: Select all

a = 1
b = 0


Because it extends from ROLE1 before it was replaced. So it is dependent upon the order in which the roles are loaded.
FYI the order in which permissions.ini files are loaded are:

1. xataface's permissions.ini
2. module permissions.ini files
3. application permissions.ini file

-Steve

[ADobkin]

Okay, thanks for clarifying the how the roles are processed. That definitely explains the behavior I was experiencing.

So, it sounds like all of the extended permissions from a lower-level permissions.ini file need to be redefined in the higher-level permissions file if any of the "upstream" roles have been extended or overridden. The worst case is my example of changing the READ ONLY role in the application permissions.ini file, since all of the other roles are extended from READ ONLY by default. That means it is necessary to recreate every role (EDIT, DELETE, OWNER, USER, ADMIN, etc.) locally, or change the base one universally in the Xataface permissions file each time a new version is released. Is that correct, or is there an better way to manage changes to the READ ONLY role?

FYI the order in which permissions.ini files are loaded are:

1. xataface's permissions.ini
2. module permissions.ini files
3. application permissions.ini file

Would it be correct to say that number 4 is the table permissions.ini file?

Thanks,
Alan

[ADobkin]

I have spent countless hours testing various options with the roles in permissions.ini, and I discovered a major problem with the model I was using.

My understanding was that a role could be completely re-defined (vs. being extended) in the application-level permissions.ini file. For example, the READ ONLY role gives a handful of permissions out by default that I may not want to make available. So, I could simply put the following into my applications permissions.ini file:

Code: Select all

[READ ONLY]
view = 1

This does appear to work as expected. However, the problem comes into play when I try to redefine any other role, which has already been extended in the Xataface permissions.ini from the default READ ONLY role. For example:

Code: Select all

[EDIT]
edit = 1

In my testing, this section is completely ignored. All options are passed through from the main Xataface permissions.ini file, and nothing listed here is respected. All other roles that depend on this role (extend it) are affected by this.

The good news is that there is a workaround, which is to extend the EDIT role based on the new READ ONLY role, like this:

Code: Select all

[EDIT extends READ ONLY]
edit = 1

Now, EDIT gives just view and edit permissions, and not all of the other default permissions (find, rss, export, etc.).

So, my question is: What is supposed to happen if an existing role is re-defined without using the extended keyword?

[ADobkin]

FYI, I have also discovered a bug in the module permissions.ini behavior regarding the order these files are loaded. Please see:

http://bugs.weblite.ca/view.php?id=800

[sworden]

I'm trying to restrict permissions for particular tables. For a few tables I want those with the EDIT role to only have READ-ONLY access. I tried various versions of extending permissions in a permissions.ini file in a particular table's folder but that did not work, I believe because I am actually restricting rather than extending. I tried this in that file as well:

[EDIT]
view = 1
edit = 0
new = 0

but nothing works. What am I missing?

[Iridium]

Would it be correct to say that number 4 is the table permissions.ini file?

Hello,

it seems that my Xataface (ver. 1.3.2 3355) ignores permissions.ini file from tables folders.
I modified Dataface/PermissionsTool.php

Code: Select all

class Dataface_PermissionsTool_Instance {
-skip-
function __construct($conf = null,$table=null){
      if ( $conf === null ){
         import('Dataface/ConfigTool.php');
         $configTool =& Dataface_ConfigTool::getInstance();
         //modification is here
         $app =& Dataface_Application::getInstance();
         $query =& $app->getQuery();
         $table = $query['-table'];
         $conf = $configTool->loadConfig('permissions',$table);
         //end of modification
      }
      $this->addPermissions($conf);
   }
-skip-
}


Now Xataface loads permissions.ini from tables foldes, as well as main permissions.ini
Steve, how do you think, is it acceptable solution?

[shannah]

Placing permissions.ini files inside particular tables directories isn't supported, and it is a little more complex than you might think. This change would not be sufficient to add support. We would also need to change the way that permissions are loaded in the first place so that the proper permissions tool is loaded for the proper table/record. If you want to customize the permissions for a particular table, you would not do this by changing the permissions.ini file for that table. You would do that by specifying different permission sets to be returned from the getPermissions() or getRoles() methods of the delegate classes. The permissions.ini file doesn't actually assign permissions - it just defines the global set of permissions and roles that *can* be assigned.