OK, sorry I jump a bit late on this thread but here's how the VelocityPortletAction works and the current limitations of the model:
- VelocityPortletAction is tied to a VelocityPortlet through a registry binding. - VelocityPortlet delegates processing to the PortletAction during content rendering to execute the default buildXXX() methods as expected So that's the simple part... now the tricky one: VelocityPortletAction is also a subclass of Turbine VelocityAction, which it itself supports action events : * if an action event is directed to this Action in the URL, Turbine will use its default Action handling mechanism to dispatch the event call, which in Turbine processing happens *before* layout is loaded and thus before user profile is loaded, thus the Action executes itself with a null portlet parameter... * additionally, when events are triggered the action is invoked *a second time* during the VelocityPortlet rendering to call the buildXXX(). There's a logic test in the overloaded VelocityPortletAction.doPerform() to avoid that events are executed twice... So when an event is fired at a VelocityPortletAction, the typical process flow is: Turbine SessionValidationAction VelocityPortletAction -> event processing, no portlet available Layout Portal rendering: VelocityPortlet rendering VelocityPortletAction -> buildXXX processing with VelocityPortlet reference Currently it's the portlet/action responsability to manage to get a reference between them but I don't see any inherently correct way of doing this without dramatically changing the request processing flow or fixing the semantics of 'portlet'. > -----Message d'origine----- > De : David Sean Taylor [mailto:[EMAIL PROTECTED]] > Envoy� : lundi 14 octobre 2002 22:42 > � : Jetspeed Developers List; [EMAIL PROTECTED] > Objet : RE: Securing VelocityPortlet actions > > > > Actually, JspPortletAction will not run any of its build* > methods unless > > there's a "portlet" attribute in the request. This attribute gets > > set in the > > JspPortlet so if the action was invoked via URL, it > wouldn't run. I think > > that VelocityPortlet works in similar fashion. Well, I know it > > does, because > > I modeled JspPortletAction on VelocityPortletAction. What I > am missing? > > If I remember, calling context.get("portlet") in an action > event (doXXXX) > returns NULL. > > VelocityPortlet portlet = > (VelocityPortlet)context.get("portlet"); > > This doesn't happen until the control builds its context > > context.put("portlet", portlet ); > > > > > > > > > > > > about securing non-portlet actions? Perhaps these actions > > should become > > > > another type of portal resource and extend JetspeedAction > > > which, in turn, > > > > would be responsible for checking PERMISSION_EXECUTE. > > > > > > Yes, 'normal' turbine actions also need to be secured. > > > PERMISSION_EXECUTE, yes, that may work. I was thinking of just > > > hooking into > > > the current mode (view, customize), but yes, I like > execute permission. > > > +1 on adding it > > > > > > > I guess I didn't think this through. If we use security contraint > > to secure > > a turbine action, what do we attach it to? Unless we assume that the > > security constraint is named the same as the action. How > about if we use > > turbine permissions and roles? We could create a base > action class which > > would check for existence of permission with the same name > as the action > > class. If such permission exists that would mean the action > is secured. > > Next, it would check the user permissions to see if the user can > > execute the > > action. > > > > For Velocity Action events, I was thinking it would be attached to the > portlet or portlet instance constraint. > However, one could argue that each action event should have its own > constraints. > > As for Turbine actions, why not create a new type of resource: action. > The PortalAccessController interface doesn't support actions > Don't confuse the 2nd parameter, its an 'action' as in permission > > > public interface PortalAccessController extends Service > { > // check a portlet instance for a given permission/action > public boolean checkPermission(JetspeedUser user, Entry > entry, String > action, String owner); > > // check a portlet for a given permission/action > public boolean checkPermission(JetspeedUser user, Portlet portlet, > String action, String owner); > > // check a Portal Resource for a given permission/action > public boolean checkPermission(JetspeedUser user, PortalResource > resource, String action); > } > > The third looks promising: > > public class PortalResource implements Serializable > { > public static final int TYPE_PORTLET = 100; > public static final int TYPE_ENTRY = 200; > public static final int TYPE_ENTRY_PARAMETER = 201; > public static final int TYPE_REGISTRY = 300; > public static final int TYPE_REGISTRY_PARAMETER = 301; > > why don't we add > > public static final int TYPE_ACTION = 400; > public static final int TYPE_ACTION_EVENT = 401; > > and then new constructors > > public PortalResource(Action action ) > public PortalResource(ActionEvent actionEvent) > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
