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

[Gavin King (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBSEAM-1544?page=all ]

Gavin King closed JBSEAM-1544.
------------------------------

    Fix Version/s: 1.3.0.BETA1
       Resolution: Done
         Assignee: Gavin King

OK, well I definitely dont want to do it by complexifying @Restrict, but I just committed something to CVS that will let you use:

@Restrict("#{s:hasPermission(org.jboss.seam.component.name, org.jboss.seam.method.name, org.jboss.seam.this.instance)}")


Why don't you try that out for me and let me know if it works?

> 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