[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1544) Extend @Restrict annotation to allow specifying the "action" and "args" parameters for the s:hasPermission call.

[Chris Rudd (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-1544?page=comments#action_12366675 ] 
            
Chris Rudd commented on JBSEAM-1544:
------------------------------------

Yes, that works.

The only potential issue is see is that if say the Identity componet has the MethodContextInterceptor enabled, then when the SecurityInterceptor calls it the MethodContext would change to that of the Identity.checkRestriction method instead of being the @Restrict method. Currently Identity is interception type NEVER so its safe.

> Extend @Restrict annotation to allow specifying the "action" and "args" parameters for the s:hasPermission call.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-1544
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1544
>             Project: JBoss Seam
>          Issue Type: Feature Request
>    Affects Versions: 1.3.0.ALPHA
>            Reporter: Chris Rudd
>         Assigned To: Gavin King
>             Fix For: 1.3.0.BETA1
>
>
> I'm currently using a decendant of the Home objects that uses the specifis @Restrict on the update/persist and remove methods. The different Home objects are defined via configuration. This all works great, except that there isnt a way to get at the particular instance that the Home object is operating on, or alter the action that will be checked.
> I propose making the following changes to @Restrict and the SecurityInterceptor :
> @Target({TYPE,METHOD})
> @Documented
> @Retention(RUNTIME)
> @Inherited
> public @interface Restrict 
> {
>    /**
>     * Restrictions may be expressed using any EL expression, and usually
>     * include the use of s:hasRole(...) or s:hasPermission(..., /..).
>     * 
>     * @return An EL expression that defines the restriction to be checked
>     */
>    String value() default "";
>    /**
>    * If specified the value will be used for the action instead of the method name.
>    */ 
>    String action() default "";
>    /**
>     * If specified the values will be passed as the args parameter of the s:hasPermission check.
>     */
>   String[] args() default {};
> }
> Then the createDefaulExpr can use the Restrict to override the method name and args such that 
> @Restrict( action="delete", args = "component.instance" ) would generate #{s:hasPermission( <component name>, 'delete', component.instance )}, provided that the current component is exposed as "component" .
> The would allow the auto use of the component name (needed for use when defining components via configuration), yet still provide the ability to "tweak" the default Restrict check. The component would need to be exposed as "component" since the final component name is unknown until configuration time. Alternatly you could do some thing like #component.instance, and do a string replace of #component with the effective component name as part of the formatting of the defaultExpr.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira