[jbossseam-issues] [JBoss JIRA] Updated: (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=all ]

Chris Rudd updated JBSEAM-1544:
-------------------------------

        Summary: Extend @Restrict annotation to allow specifying the "action" and "args" parameters for the s:hasPermission call.  (was: Extend @Restrict annotation to allow specifying the "actionthe "args" parameter fro hasPermission a valuebinding for the instance instead of always passing null.)
    Description: 
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.


  was:
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. 

One could provide additional attributes to the @Restrict annotation such that one can specify the instance parameter of thte default s:hasPermission() that gets generated. Additionally the "root" object (the component that the interceptor is running against) would need to be exposed so that it can be accessed genericly (this would be due to the defining of the Home object via configuration, where the annotation has to be the same for every instance). I suggest "component" as the name to bind it to :
i.e. @Restruct(instance=#{componet.instance}) . This would expose the current component as "component" then the createDefaultExpr would produce "#{s:hasPermission(<component name>, <method name>, compoent.instance)}"

Additionally it would be nice to ve able to override the "action" to use (instead of always using the method name).





> 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
>
> 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