On 28-08-2008 at 16:30, marijan milicevic wrote: > Hi all, > > after reading stripes book decided to switch my security implementation > from > http://www.stripesframework.org/display/stripes/Securing+Stripes+With+ACLs > to: > http://www.stripesframework.org/display/stripes/Security+Interceptor+for+custom+authorization > > but soon realized(eh..read: got exceptions al over the place ;-)) > that later implementation has a serious drawback(in mine case) and that > is it's tag usage: > > <s:useActionBean var="xx" bean="foo.Bean" /> > <security:allowed bean="xx"> > > Now, if you have a navigation which is a layout-definition, > and you have beans that preload stuff based on some parameter/user input, > you are kinda screwed cause your bean cannot be instantiated (if there > are exceptions).
One of the assumptions of the security interceptor I wrote, is that for Sttipes to execute the event handler the bean must exist. This can be done in several ways: - via the usual Stripes event handling (for the bean called "actionBean") - via the stripes tag useActionBean (which can also call an event handler) Both of these are created (and have their properties set) when used. It is therefore always possible to use them for security as well. Or so I thought; as you're getting exceptions, this may be wrong. So to find out what's happening, I'll list what I understand from the entire process with respect to the security tag: 1. An action bean in instantiated by Stripes. 2. The security tag finds the bean instance and the Method that will handle the named event (or the default event handler if no event is named) 3. The security manager is asked to check if access is allowed 4. The security manager returns Boolean.TRUE if so, Boolean.FALSE if not, or null if some information is missing. 5. The tag shows it's content (or not) based on this result. Based on testing I did, I think that it's unlikely that steps 2, 3 or 5 create problems. My guess is steps 1 and/or 4. You mentioned that your bean cannot be instantiated, suggesting the problem is in step 1. Why is that? > Also, my navigation contains references to something like 20 or more > action beans, > so even if it would run without NPE's, preloading all those beans just > to check the roles, > is a lot of overhead..(especially knowing that calling > context.request.isUserInRole(..) should be enough...) This is indeed one of the weaknesses of the security interceptor. On the other hand, the bean object is short lived and doesn't have much properties populated (if any). The memory nor the call stack will be overly burdened by this I think. Especially compared to the rest of the request handling. Just my two cents. Oscar -- ,-_ "[Think before you act.] /() ) Life is hard, but it's a lot harder when you're stupid." (__ ( -- Redd Fox =/ () ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
