Exception_Warning: Declaration of RedSparkFramework_RsModule_Cms_Controller_Asset_IncParsedHtmlFile::getFormArray() should be compatible with that of RedSparkCore_RsModule_Cms_Controller_Asset_ListExtended::getFormArray()

Acl

Access Control Lists

The Redspark_Acl takes the Zend_Acl component and implements the 3 Rs: Roles, Ressources and Rules.
Also some more methods are added, making the use of ACL with role-inheritance easier.

Redspark_Acl

Redspark_Acl extends the Zend_Acl for more features, default implementations and an action-resource concept.

Concept and definitions

Roles

In Redspark are a few default roles. This is neccessary to distinguish between frontend and backend and choosing the right design to render. Additionaly, the Redspark_Acl queries all modules, implementing the Redspark_RsModule_Abstract_Controller_Interface_Roles interface for more roles to define.

World

The first role is "World" (deprecated also "world"), which means everybody. The deprecated "world" alias is not supported in Redspark > 1.4.x. All actions for example, allowed for world can be executed from front- and backend.

Base/Guest

This role matches for all users, that are not logged in. This role inherits from world, which means all world usable actions are by default also accessible for non-loged in users. A deprecated alias for this is "guest". The deprecated "guest" alias is not supported in Redspark > 1.4.x.

Base/Member

This role matches for all users, that are logged in into the frontend. It inherits from world, meaning there is no restriction for world-accessible actions. A deprecated alias for this is "member". The deprecated "member" alias is not supported in Redspark > 1.4.x.

Base/Admin

This role matches for all users, that are logged in into the backend. It inherits from world, meaning there is no restriction for world-accessible actions. This role inherits from world, too. A deprecated aliases for this is "admin". The deprecated "admin" alias is not supported in Redspark > 1.4.x. There is a finer granulation of this role, divided into several adminlevels ("adminlevel_0" to "adminlevel_6"). The lower the level, the higher the rights. All adminlevel_* roles inherit from the standard admin. so if you want to restrict something to the main admin, you have to check for adminlevel_0. The Syntax for adminlevel roles has changed to Group/AdminLevel/* in Redspark 1.5.x. The ""adminlevel_* notation is no longer supported.

Resources

resources can be defined via the Redspark_RsModule_Abstract_Controller_Interface_Acl interface. Actions are typically the main case for resources, but not the only ones. In action-context, the resource are internaly refered to as "rights". All available actions will be registered to a resource with the following pattern: <Module>/action_<Action>

Rules

The ruleset describes, which role can do what with which resource. In redspark these are mainly of the kind Role ALL Action (resource). Here again, will be all modules queried, implementing the Redspark_RsModule_Abstract_Controller_Interface_Acl interface.

Using Redspark_Acl

Check for Permission

To check if the current user has permission to an action, the following code can be used (Note, that the authorize Plugin does this for you).

<?php

        
/* Get Redspark_Acl from the Broker */
        
$acl Broker::getAcl();
        
        
/* Get my current role */
        
$myrole $acl->getMyRole();
        
        
/* Define the resource to query */
        
$resource 'Cms/action_ShowSite';
        
        
/* check if resource exist */
        
if (!$acl->has($resource)) {
            return 
false;
        }
        
        
/* check permission */
        
if (!$acl->isAllowed($myrole,$resource)) {
            return 
false;
        }
        return 
true;
    
?>
Check if current user is an admin

To check if the user is (inherits from) and admin, you have to get its role and then check the parents.

<?php

        
/* Get Redspark_Acl from the Broker */
        
$acl Broker::getAcl();

        
/* check if the given role is fullfilled by me */
        
$isAdmin $acl->isRole('Base/Admin');
    
?>

Configuration examples

ACL is used to detect wheter the current action belongs to frontend or backend. This decision is considered, too, for design detection and translate detection. Also look at the translate documentation for more information on translate detection. The following permissions are common cases:

Action is available to everyone and always displayed in frontend (even if user is logged in as member or admin).
Translation is used from frontend.
			
		
Action is only available for admin and only displayed in backend.
Translation is used from backend.
			
		
Action is only available for members and only displayed in member design.
Translation is used from frontend.
			
		
Action is available to everyone and displayed in each individual design. The following order applies then:
  1. If logged in as member -> member design
  2. If logged in as admin -> backend design
  3. Else -> frontend design
The translation is always taken from backend.
			
			
			
		
Action is only available for members and admins. Will be displayed in the according design, depending on the login type. If user is logged in as both, the member design should be prefered. Note: This constellation is not recommended as an admin has no member id and vice versa.
The translation is taken from the frontend.
			
			
		

Template detection via ACL

The template detection is done with following rules:

  1. IF role=World THEN use frontend template
  2. IF role=Base/Member and user is logged in as member THEN use member template
  3. IF role=Base/Admin and user is logged in as admin THEN use admin template
  4. ELSE use frontent template

Tutorials

Die eigene App

Kuborgh GmbH

Hamburg 040 819 773 770 Köln 0221 276 66 96 info@kuborgh.de www.kuborgh.de

RedSpark Community

RedSpark Community

Community Website
RedSpark Apps

RedSpark Apps

Zur Übersicht
RedSpark Download

RedSpark Basispaket

Zum Download
Key facts