Wednesday, April 15, 2009

myfaces-extval-add-on - @SecuredAction

you might already know that you can use myfaces extval for much more than validation. this new add-on shows how simple it is to provide add-ons for different problem domains. it's available at

@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.

the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.

@SecuredAction offers several features - here are some short examples:

that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.

the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:

it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:

furthermore, in case of denied access, you can automatically add a (global) error message via:

the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.

//use an existing message bundle
SecuredAction.MESSAGE_BUNDLE, "");

//use an existing message bundle var-name

SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");

in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role

the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.

it's also possible to define specific pages which need a secured action method:

to define different scenarios, it's possible to use multiple annotations at one method. you can do that via: