Инструменты пользователя

Инструменты сайта


limb2:en:access_policy

Access policy basics

Limb2 has 2 tier permission system

  • Object access. The access system determines the user's permissions for the requested object: read, write or both
  • Actions access. The access system determines whether the user is allowed to perform the requested action over the object

These steps are sequent and tightly connected. An action requires a set of ObjectPermissions to be accessible by user. So it's not enough for a user to have an ActionAccess only - the user must have specific permissions for the requested object too. Sounds a bit complicated, a good example should make everything clear hopefully.

Limb uses only resolving (positive) access records. So user accumulates permissions from all the groups he participates in with his own permissions. Currently there is no way to restrict any user to have access to some object if any group that user participates in has access to that object.

Objects access

In Limb 2.3 we have simplified our access policy a log. We have removed read and write permissions separation. Now user can just have access to an object or not. If user doesn't have permission to get access to an object then in most cases the user is not aware of the object existence at all. The only possible way to see such objects is to directly use site_object::fetch() method.

You can browse and set user permissions(group based) for objects at with Limb GUI using /root/admin/objects_access page.

Actions access

Action is a set of some operations. Defined in the site object controller actions may apply directly to the site object or…perform whatever you need. To perform an action the user must have a permission to execute it.

Limb provides a GUI to control actions access at /root/admin/controllers (/root/admin/classes in Limb 2.2.x) page. The administrator sets what actions are accessible by user groups. As mentioned above Limb doesn't has a GUI to set actions permission for individual users. We have not faced any case that required such functionality in our practice so far, yet it's not a problem to implement one.

Each action requires the certain set of object access permissions described in the site object controller. Lets look into one small example to make everything clear:

Small example

Suppose we have some article_controller. It supports only 2 actions: 'display' and 'delete':

class article_controller extends site_object_controller
{
    function _define_actions()
    {
        return  array(
          'display' => array(
           [[...]]
          ),
          'delete' => array(
           [[...]]
          ),
        );
 
        parent :: site_object_controller();
    }
}

Ok, let's imagine we have 3 article objects in out system: 'article1', 'article2' and 'article3'.

Our user is a member of 2 groups: 'visitors' and 'admins'.

Objects permissions that user groups have for objects are:

            article1   article2   article3
visitors               ok         ok 
admins      ok         ok          

And user groups actions access as follows:

            display        delete
visitors    true           false
admins      true           true

It means that our user is allowed to display all articles (since the user is a member of visitors and admin groups), can delete all articles.

Обсуждение

Ваш комментарий. Вики-синтаксис разрешён:
  _   __  ____    ____     __  ____ 
 | | / / / __ \  / __/ __ / / / __ \
 | |/ / / /_/ / _\ \  / // / / /_/ /
 |___/  \____/ /___/  \___/  \___\_\
 
limb2/en/access_policy.txt · Последние изменения: 2010/11/10 10:02 (внешнее изменение)