사용자가 다른 부서에서 다른 역할을 할 수있는 ACL을 만들려고합니다.젠드 탐색 여러 ACL 역할
로그인 한 사용자에 따라 role::guest
또는 role::user
의 형식으로 역할이 부여됩니다.이 사람의 이름은 userRole
입니다. 모든 부서에 액세스 할 수있는 role::superuser
도 있습니다.
또한 ACL에 부서별 역할을 department::role
(예 : bookings::user
) 형태로 추가했습니다. 이것은 departmentRole
입니다.
사용자 부서별 역할은 Zend_Auth
ID로 저장됩니다.
액세스 제어 파트는 Zend_Acl
을 확장하고 isAllowed
기능을 오버라이드하여 작동합니다. 이렇게하면 각 사용자를 성공적으로 허용하거나 거부합니다.
public function isAllowed($role = null, $resource = null, $privilege = null)
{
$identity = Zend_Auth::getInstance()->getIdentity();
$userRole = $identity->role;
$departmentRoles = $identity->departmentRoles;
if (parent::isAllowed($userRole, $resource, $privilege))
{
return parent::isAllowed($userRole, $resource, $privilege);
}
else {
foreach ($departmentRoles as $departmentRole)
{
if(parent::isAllowed($departmentRole, $resource, $privilege))
{
return true;
}
}
}
return false;
}
내가 겪고있는 문제는 Zend_Navigation
에는 Acl 인스턴스와 단일 사용자 역할이 필요하다는 것입니다. 내비게이션 메뉴를 만드는 내보기 스크립트는 단일 사용자 역할에 대해서만 유효성을 검사하는 $this->navigation()->accept($page)
을 사용합니다.
각 사용자마다 여러 개의 Acl 역할을 가질 수 있고 Zend_Navigation에서 액세스 할 수있는 메뉴 항목을 표시 할 수 있습니까?
더 나은/다른/올바른 접근법이 있다면 공유하십시오.
감사
편집 :이 방법이이 작업을 수행 할 수있는 올바른 방법이 될 수 없다 생각하고 저를 얻었다 isAllowed()
의 핵심 기능을 타고 이상의 의미가 있음을
사실.
이제 ACL 모델에서 모든 사용자, 부서 및 연결을 가져 와서 관련 부서에서 다양한 역할로 구성된 각 사용자에 대한 배열을 만들어 루프합니다. 그런 다음 각 사용자에 대해 하나의 역할을 만들고 이전에 생성 된 배열에서 역할을 상속합니다.
이
내가 또한 자원으로 사용자를 추가하고 관련 관리자 및 부서 관리자 권한 등 자신의 세부 사항을 개정 할 수 있습니다 의미도 지금까지 잘 작동하고 그것은 또한 내가 하나를 전달할 수 있다는 것을 의미Zend_Navigation과 메뉴 구조에 대한 역할은 부서 역할과 관련이 있어야합니다.
나는 더 좋은 접근법을 연구하기 위해 며칠을 보냈으며 여러 개를 사용하는 것이 올바른 방법이 아니라는 것에 동의합니다. 'isAllowed()'와 같은 핵심 함수를 오버라이드해야한다는 사실은 그것을 증명합니다. – Gavin
내 생각/결과를 확인하는대로이 대답을 수락합니다. – Gavin