[ 
http://www.stripesframework.org/jira/browse/STS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11192#action_11192
 ] 

Gregg Bolinger commented on STS-495:
------------------------------------

Sort of? LOL

Alright so I have a Resolution called View which is more or less going to 
forward to a JSP.  Maybe some other logic in there.  I'd suspect that a user 
would either have access to that event or not.  Why such fine grained control 
with a class, target, and action?  What other actions would there be?  Maybe 
the example just isn't telling enough?

The way the SecurityInterceptor works that I've worked with is it is Role 
based. How is this one different?  What sets it apart?

> EventPermission annotation for Stripes events methods
> -----------------------------------------------------
>
>                 Key: STS-495
>                 URL: http://www.stripesframework.org/jira/browse/STS-495
>             Project: Stripes
>          Issue Type: New Feature
>          Components: ActionBean Dispatching
>    Affects Versions: Release 1.4.3
>         Environment: All
>            Reporter: Andrew Jaquith
>            Assignee: Tim Fennell
>         Attachments: EventPermission.java, EventPermissionInfo.java, 
> WikiInterceptor.java
>
>
> Hi Tim and all -
> We're planning to use Stripes in an a future release of Apache JSPWiki. While 
> doing the integration, I wrote an a method annotation and supporting classes 
> that turned out to be quite generic, and could be quite useful for all 
> Stripes users. So I thought I'd write it up in the hopes of getting it into 
> Stripes 1.5. The idea is pretty simple: use the method annotation 
> @EventPermission to identify what Java Permissions would be needed to 
> successfully execute an event.
> Here's how it works. Suppose we have an Actionbean whose default event is the 
> "view()" method, but we want to make sure the caller possesses a particular 
> Permission. Here's the method signature:
>    @DefaultHandler
>    @HandlesEvent("view")
>    @EventPermission(
>       permissionClass=PagePermission.class,
>       target="${page.qualifiedName}",
>       actions=PagePermission.VIEW_ACTION)
>    public Resolution view() { ... }
> Note the @EventPermission annotation. It defines the Permission class and its 
> target and actions. The "permissionClass" attribute tells use that the 
> Permission class this method needs is "PagePermission" (a custom Permission 
> class). Note also the JSTL-style syntax in the target and actions attributes 
> -- these allow JSTL-access to bean properties for the instantiated 
> ViewActionBean. In this case, "${page}" is the bean attribute that returns 
> the value of this ViewActionBean's getPage() method. The nested syntax 
> "${page.qualifiedName}" is equivalent to getPage().getQualifiedName(). Neat, 
> huh?
> An annotation like this would collaborate with a security interceptor that 
> fires during the binding/validation stage:
> @Intercepts( { LifecycleStage.BindingAndValidation })
> public class WikiInterceptor implements Interceptor
>     public Resolution intercept(ExecutionContext context) throws Exception {
> ...
>         // Does the event handler have a required permission?
>         boolean allowed = true;
>         EventPermissionInfo permInfo = beanContext.getPermissionInfo(handler);
>         if ( permInfo != null )
>         {
>             Permission requiredPermission = 
> permInfo.getPermission(actionBean);
>             if ( requiredPermission != null )
>             {
>                 // security checking code goes here...
>             }
>         }
>         // If not allowed, redirect to login page with all parameters intact;
>         // otherwise proceed
>         if (!allowed)
>         {
>             r = new RedirectResolution(LoginActionBean.class);
>             ((RedirectResolution) r).includeRequestParameters(true);
>             return r;
>         }
>     }
> I have attached several sample source files. I have not "cleansed" them yet 
> -- so if they are of interest to you, I'll do that.  

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

        

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to