Roles & MM

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Roles & MM

Adam Franco
Administrator
Hi Dan (and all),

We will soon be rolling out a system of global guest accounts across campus and in preparation I'm auditing our Drupal site to ensure that guest accounts can in no way modify content. To start off we are disabling guest logins on our main site, but in the future may wish to allow guest logins for commenting and submission of webforms. In this future case we are concerned that an editor might mistakenly grant add-subpage or edit permissions to a guest account and we want to prevent any MM page addition/editing by certain roles.

Below is an outline of how I'm thinking of solving this issue. I'm mostly wondering if this approach makes sense or if there is a better way to allow user accounts into the Drupal database without allowing privilege escalation via MM permissions.


1. Separate role for "Institution Members", restrict "Authenticated Users"

I created a role for "Institution Members" non-guests with normal user permissions and left the built-in "Authenticated Users" role with the same permissions as anonymous users with the exception of add comments. The Drupal roles/permissions works well for this and guests can't add new content or work with non-mm-aware features.

2. Restrict node-editing permissions based on role perms

Role permissions for existing content get overridden by mm_content_node_access() however, potentially allowing users to edit content even if they don't have one of the 'edit own node_type content' permissions assigned to their role. This is something I can get around by implementing the mm_node_access hook in my own module to force permissions to FALSE if the users roles don't allow content editing:

function mymodule_mm_node_access($op, $node, $account) {
  if ($op == 'create') {
    // Likely redundant since it seems that this check is happening on the content add page.
    if (!user_access($op . ' ' . $node->type . ' content', $account))
      return FALSE;
  }
  elseif ($op == 'update' || $op == 'delete') {
    if ($op == 'update')
      $op = 'edit';
   
    if (!user_access($op . ' any ' . $node->type . ' content', $account) && !user_access($op . ' own ' . $node->type . ' content', $account))
      return FALSE;
  }   
}

3. Restrict MM page permissions based on role perms

There currently is no mm hook that allows modules to override MM page permissions like the mm_node_access hook allows. To prototype this I've tried adding a new hook invocation, 'mm_user_can_alter', to mm_content_user_can() that modules could implement to override mm permissions:

function mm_content_user_can($mmtid, $mode = '', $usr = NULL, $bias_anon = TRUE) {

...

        // Allow modules to override access.
        foreach (mm_module_implements('mm_user_can_alter') as $module) {
          call_user_func_array($module . '_mm_user_can_alter', array($mmtid, $account, &$_mmuc_cache[$mmtid][$uid]));
        }

       
        _mm_content_access_cache($cid, $_mmuc_cache[$mmtid][$uid], $mmtid);
      }
    }
  }

  if (!empty($mode)) return $_mmuc_cache[$mmtid][$uid][$mode];

  return $_mmuc_cache[$mmtid][$uid];
}

Implementing this hook with something like the following can block MM page edits/additions for roles that don't have a given permission:

function mymodule_mm_user_can_alter($mmtid, $account, &$perms) {
  if (!user_access('change mm pages', $account)) {
    $perms[MM_PERMS_WRITE] = FALSE;
    $perms[MM_PERMS_SUB] = FALSE;
    $perms[MM_PERMS_APPLY] = FALSE;
  }
}



Thanks for any feedback you can provide!

Adam

--

Adam Franco
Senior Software Engineer - Web Applications
Library and Information Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=684358

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles & MM

Dan Wilga-2
Hi Adam,

On 12/11/12 4:15 PM, Adam Franco wrote:
1. Separate role for "Institution Members", restrict "Authenticated Users"

I created a role for "Institution Members" non-guests with normal user permissions and left the built-in "Authenticated Users" role with the same permissions as anonymous users with the exception of add comments. The Drupal roles/permissions works well for this and guests can't add new content or work with non-mm-aware features.
We do something similar to this for admission applicants: we leave them in "authenticated user" and created a separate group for all non-applicant users. "Authenticated user" can view everything a basic logged-in user can, but cannot create or edit any content (role-base restrictions); they can comment.
2. Restrict node-editing permissions based on role perms

Role permissions for existing content get overridden by mm_content_node_access() however, potentially allowing users to edit content even if they don't have one of the 'edit own node_type content' permissions assigned to their role. This is something I can get around by implementing the mm_node_access hook in my own module to force permissions to FALSE if the users roles don't allow content editing:
If you don't allow the guests (in the authenticated user role) to "edit/create node_type content", they shouldn't have this access. This is what we do.
3. Restrict MM page permissions based on role perms

There currently is no mm hook that allows modules to override MM page permissions like the mm_node_access hook allows. To prototype this I've tried adding a new hook invocation, 'mm_user_can_alter', to mm_content_user_can() that modules could implement to override mm permissions:
This is not something I can support. mm_content_user_can() is supposed to be the result of a database query. Arbitrary alters cannot be inserted at any level but mm_content_get_query() without potentially affecting the way MM operates in other contexts.
-- 
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=684365

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles & MM

Adam Franco
Administrator
In reply to this post by Adam Franco
Thanks for the feedback, Dan. It's good to hear that you are successfully making use of self-registered accounts without too many problems.


Adam

--

Adam Franco
Senior Software Engineer - Web Applications
Library and Information Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244



On Tue, Dec 11, 2012 at 4:49 PM, Dan Wilga <[hidden email]> wrote:
Hi Adam,

On 12/11/12 4:15 PM, Adam Franco wrote:
1. Separate role for "Institution Members", restrict "Authenticated Users"

I created a role for "Institution Members" non-guests with normal user permissions and left the built-in "Authenticated Users" role with the same permissions as anonymous users with the exception of add comments. The Drupal roles/permissions works well for this and guests can't add new content or work with non-mm-aware features.
We do something similar to this for admission applicants: we leave them in "authenticated user" and created a separate group for all non-applicant users. "Authenticated user" can view everything a basic logged-in user can, but cannot create or edit any content (role-base restrictions); they can comment.
2. Restrict node-editing permissions based on role perms

Role permissions for existing content get overridden by mm_content_node_access() however, potentially allowing users to edit content even if they don't have one of the 'edit own node_type content' permissions assigned to their role. This is something I can get around by implementing the mm_node_access hook in my own module to force permissions to FALSE if the users roles don't allow content editing:
If you don't allow the guests (in the authenticated user role) to "edit/create node_type content", they shouldn't have this access. This is what we do.
3. Restrict MM page permissions based on role perms

There currently is no mm hook that allows modules to override MM page permissions like the mm_node_access hook allows. To prototype this I've tried adding a new hook invocation, 'mm_user_can_alter', to mm_content_user_can() that modules could implement to override mm permissions:
This is not something I can support. mm_content_user_can() is supposed to be the result of a database query. Arbitrary alters cannot be inserted at any level but mm_content_get_query() without potentially affecting the way MM operates in other contexts.

--
Dan Wilga                                 [hidden email]<mailto:[hidden email]>
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: <a href="tel:413-542-2175" value="+14135422175">413-542-2175
Amherst, MA  01002

---

You are currently subscribed to monster_menus as: [hidden email]<mailto:[hidden email]>.

To unsubscribe click here: http://lists.middlebury.edu/u?id=685438.780c6126d238396bdd2f98c1d84c15c7&n=T&l=monster_menus&o=684365

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]<mailto:[hidden email]>

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=684391

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles & MM

Dan Wilga-2
In reply to this post by Adam Franco
Well, technically they are not self-registered. We import the applicants from our ERP in the same way we do the rest of our users.

On 12/12/12 11:55 AM, Adam Franco wrote:
Thanks for the feedback, Dan. It's good to hear that you are successfully making use of self-registered accounts without too many problems.


Adam

--

Adam Franco
Senior Software Engineer - Web Applications
Library and Information Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244



On Tue, Dec 11, 2012 at 4:49 PM, Dan Wilga <[hidden email]> wrote:
Hi Adam,

On 12/11/12 4:15 PM, Adam Franco wrote:
1. Separate role for "Institution Members", restrict "Authenticated Users"

I created a role for "Institution Members" non-guests with normal user permissions and left the built-in "Authenticated Users" role with the same permissions as anonymous users with the exception of add comments. The Drupal roles/permissions works well for this and guests can't add new content or work with non-mm-aware features.
We do something similar to this for admission applicants: we leave them in "authenticated user" and created a separate group for all non-applicant users. "Authenticated user" can view everything a basic logged-in user can, but cannot create or edit any content (role-base restrictions); they can comment.
2. Restrict node-editing permissions based on role perms

Role permissions for existing content get overridden by mm_content_node_access() however, potentially allowing users to edit content even if they don't have one of the 'edit own node_type content' permissions assigned to their role. This is something I can get around by implementing the mm_node_access hook in my own module to force permissions to FALSE if the users roles don't allow content editing:
If you don't allow the guests (in the authenticated user role) to "edit/create node_type content", they shouldn't have this access. This is what we do.
3. Restrict MM page permissions based on role perms

There currently is no mm hook that allows modules to override MM page permissions like the mm_node_access hook allows. To prototype this I've tried adding a new hook invocation, 'mm_user_can_alter', to mm_content_user_can() that modules could implement to override mm permissions:
This is not something I can support. mm_content_user_can() is supposed to be the result of a database query. Arbitrary alters cannot be inserted at any level but mm_content_get_query() without potentially affecting the way MM operates in other contexts.

--
Dan Wilga                                 [hidden email]<mailto:[hidden email]>
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: <a moz-do-not-send="true" href="tel:413-542-2175" value="+14135422175">413-542-2175
Amherst, MA  01002

---

You are currently subscribed to monster_menus as: [hidden email]<mailto:[hidden email]>.

To unsubscribe click here: http://lists.middlebury.edu/u?id=685438.780c6126d238396bdd2f98c1d84c15c7&n=T&l=monster_menus&o=684365

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]<mailto:[hidden email]>

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685500.19fa7de7038497527f6a88cf1629251d&n=T&l=monster_menus&o=684391

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]



-- 
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=684398

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]

Loading...