User verification

Asked

Viewed 95 times

1

I have a program that has 5 níveis de autorização, the Administrador, Gerente, Operador, Usuário and Convidado. But for each level it gives a different access to the system.

Sketch of verification:

<?
include("../sai_clas/sai_conecta.php");
?>

    <? if($_SESSION("cb_acess_usua") == 0) {
        Chama os dados validos para o administrador!
    }
    ?>

In the case of the above code, sai_conecta.php is what keeps my connection to the bank. Ai is then checked to determine if the user’s access code is equal to 0 (in which case it would be the administrator), where all data is sent to it allowed.

Note: I don’t know if Cod. above is right, it’s just a sketch!

My doubt in itself is, how to do this check, so call the data according to the level of authorization!

I call this check through a main menu, that when the user selects the 'option it will open only the data that is allowed to it!

Example of a part of menu:

<div class="menuitem" onmouseover="over(2)" onmouseout="out(2)">
    <a href="../sai_prin/menu_com_abas_dist">
    <font face="arial" >Distribuição</a>
</div>
  • Put more information, your idea, and maybe just as your system should behave this I think crucial, through the authorizations?

  • It is too broad, your question, and it has no doubt, specifies! It is difficult to understand and there is a factor on the site when it has no conditions of response or too broad (as I believe this is) the question can be closed! Try to talk about the doubt in you...

2 answers

1

You may be creating a control list for access, the permissions the user has based on his profile within the system. A library that provides a framework for this is the Zend_Acl.

To ACL is composed of three basic functions, are they:

  1. Profile (Roll)
  2. Features (Resource)
  3. Permissions (Permissions)

Profile

The following code defines three base profiles - guest, membro and admin - from which other profiles can inherit. Next, a profile identified by someuser is established and inherits the other three profiles. The order in which these roles appear in the array $parents is important.

When necessary, Zend_acl search for access rules defined not only for the consulted profile (someuser), but also on the profiles from which the consulted profile inherits (guest, membro and admin):

$acl = new Zend_Acl();

$acl->addRole(new Zend_Acl_Role('guest'))
    ->addRole(new Zend_Acl_Role('member'))
    ->addRole(new Zend_Acl_Role('admin'));

$parents = array('guest', 'member', 'admin');
$acl->addRole(new Zend_Acl_Role('someUser'), $parents);

$acl->add(new Zend_Acl_Resource('someResource'));

$acl->deny('guest', 'someResource');
$acl->allow('member', 'someResource');

echo $acl->isAllowed('someUser', 'someResource') ? 'allowed' : 'denied';

Create Access Control List

One access control list(ACL) can represent any set of physical or virtual objects you want. For demonstration purposes, however, we will create a Basic Content Management System (CMS), the ACL, which maintains several layers of groups in a wide variety of areas. To create a new object ACL, we will instantiate the ACL parameter-less:

$acl = new Zend_Acl();

The CMS will almost always require a hierarchy of permissions to determine the creation resources of your users. There may be a group Guest to allow limited access to demonstrations, a group Staff for most users of CMS which carry out most of the day-to-day operations, a group of Editor for those responsible for publishing, reviewing archiving and deletion of content, and finally a group Administrador whose tasks may include all those of the other groups, as well as the maintenance of sensitive information, user management, backup and export.

This set of permissions can be represented in a profile record, allowing each group to inherit group privileges pai, and the provision of separate privileges for only its single group. Permissions may be expressed as follows:

inserir a descrição da imagem aqui

For this example, Zend_Acl_Role is used, but any object that implements Zend_Acl_Role_Interface is acceptable. These groups may be added to the registration profile as follows:

$acl = new Zend_Acl();

// Adiciona grupos para o perfil de registro usando Zend_Acl_Role 
// O guest não herda os controles de acesso
$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);

// Staff herda o guest
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);

/*
Alternativamente, o acima pode ser escrito:
$acl->addRole(new Zend_Acl_Role('staff'), 'guest');
*/

// Editor de herda de Staff
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');

// Administrador não herda os controles de acesso
$acl->addRole(new Zend_Acl_Role('administrator'));

Now that the ACL contains the relevant profiles, rules can be established that define how resources can be accessed by the profiles. No specific features have been defined for this example, which is simplified to illustrate that the rules apply to all resources. Zend_Acl provides an implementation where rules only need to be assigned from general to the specific, minimizing the number of rules needed, because resources and functions inherit the rules that are set about their ancestors.

Therefore, we can define a fairly complex set of rules with a minimum amount of code. To apply basic permissions as defined above:

$acl = new Zend_Acl();

$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');
$acl->addRole(new Zend_Acl_Role('administrator'));

// Somente guests podem visualizar o conteúdo
$acl->allow($roleGuest, null, 'view');

/*
Alternativamente, o acima pode ser escrito:
$acl->allow('guest', null, 'view');
//*/

// Staff herda o privilégio de ver/view de guest, mas também precisa de privilégios
// adicionais
$acl->allow('staff', null, array('edit', 'submit', 'revise'));

// Editor herda os privilégios "visualizar, editar, enviar", e "revisar" de
// staff, mas também precisa de privilégios adicionais
$acl->allow('editor', null, array('publish', 'archive', 'delete'));

// Administrador não herda nada, mas é permitido todos os privilégios
$acl->allow('administrator');

Consult an ACL

We now have a ACL flexible that can be used to determine whether requesters are allowed to perform functions throughout the web application. Making queries is quite simple, using the method isAllowed():

echo $acl->isAllowed('guest', null, 'view') ?
     "allowed" : "denied";
// permitido

echo $acl->isAllowed('staff', null, 'publish') ?
     "allowed" : "denied";
// negado

echo $acl->isAllowed('staff', null, 'revise') ?
     "allowed" : "denied";
// permitido

echo $acl->isAllowed('editor', null, 'view') ?
     "allowed" : "denied";
// permitido por causa da herança de guest

echo $acl->isAllowed('editor', null, 'update') ?
     "allowed" : "denied";
// negado, porque não há nenhuma regra para permitir "update"

echo $acl->isAllowed('administrator', null, 'view') ?
     "allowed" : "denied";
// permitido porque para administrador é permitido todos os privilégios

echo $acl->isAllowed('administrator') ?
     "allowed" : "denied";
// permitido porque para administrador é permitido todos os privilégios

echo $acl->isAllowed('administrator', null, 'update') ?
     "allowed" : "denied";
// permitido porque para administrador é permitido todos os privilégios

Further reading on respect for the subject:

1


A more efficient way, would you determine the verification within the selection menu.

Example:

<div class="menuitem" onmouseover="over(2)" onmouseout="out(2)">
<?
    if($_SESSION['SS_cb_aces_usua']<2)
    {
    echo'<a href="../sai_prin/menu_com_abas_dist.php">Distribuição</a>';
    }
?>
</div>

As you determined in the code, clicking on the distribution would call a separate menu. In the above Cod he does a check showing the data only for those who have authorization from 0 to 2 (I don’t know if it would be 0 to 5 the number that determines each one).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.