With release => 3.0.0 beetRoot uses a simple user-role authorization which can be applied to templates and handlers. Furthermore, you can apply visibility to HTML template fragments
by using additionally actions (template type index
, view
, add
, edit
) and entities.
Note: Roles are translated in the web masks if a language translation exists for these roles. The translations for roles in your translation files web/lang/app/lang_*.properties
must begin with role.*
, e.g. role.administrator
.
Strict authorization is applied in handlers:
Overwrite the hasAccess-methods
, e.g.:
@Override
public boolean hasAccess(Session userSession) {
return userSession.getUserRoles().contains("Administrator") ||
userSession.getUserRoles().contains("Operator");
}
Visibility with authorization tags in HTML templates (roles, entities and actions are case-insensitive):
-
Positive role authorization:
{$if-role=Administrator:} ... {$endif-role;}
or more than one role:
{$if-role=Administrator,Operator:} ... {$endif-role;}
-
Negative role authorization:
{$if-!role=Controller:} ... {$endif-!role;}
or more than one role:
{$if-!role=Controller,Operator:} ... {$endif-!role;}
-
Positive entity authorization:
{$if-entity=tasks:} ... {$endif-entity;}
or more than one entity:
{$if-entity=tasks,properties:} ... {$endif-entity;}
-
Negative entity authorization:
{$if-!entity=products:} ... {$endif-!entity;}
or more than one entity:
{$if-!entity=products,variants:} ... {$endif-!entity;}
-
Positive action authorization:
{$if-action=edit:} ... {$endif-action;}
or more than one entity:
{$if-action=add,edit:} ... {$endif-action;}
-
Negative action authorization:
{$if-!action=index:} ... {$endif-!action;}
or more than one entity:
{$if-!action=index,view:} ... {$endif-!action;}
Note:
- Negative/positive authorization tags shouldn't be cascaded!
- Different types of authorization tags can be cascaded in the order role -> entity -> action.
If you need a more sophisticated authorization like a full ACL with groups and workflow authorization roles, we suggest that you use the current role object as a sub-role / workflow authorization role and create another entity that acts as a role group. Then implement the ability to associate the sub-roles with the role group and specify in the handler to which authorization granularity you want to grant access to (role group or sub-roles).
Click here to go to the main page.