David,
> > 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 );
>
I based my assumptions on observing the debug statements for invoking
http://localhost/jetspeed/portal/action/portlets.browser.DatabaseBrowserActi
on:
[Mon Oct 14 15:49:49 CDT 2002] -- DEBUG -- Action: building action context
[Mon Oct 14 15:49:49 CDT 2002] -- DEBUG -- Action: try executing events
[Mon Oct 14 15:49:49 CDT 2002] -- DEBUG -- Action: calling doPerform
[Mon Oct 14 15:49:49 CDT 2002] -- DEBUG -- VelocityAction: retrieved
context: org.apache.velocity.VelocityContext@a6eb8e45
[Mon Oct 14 15:49:49 CDT 2002] -- DEBUG -- VelocityAction: retrieved
portlet: null
Portlet was null and therefore action did not proceed. I guess I should have
asked for an example of this being a security hole.
>
> For Velocity Action events, I was thinking it would be attached to the
> portlet or portlet instance constraint.
I'm in agreement here.
> However, one could argue that each action event should have its own
> constraints.
>
Why? Portlet action serves a portlet and should be meaningless without it.
> 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)
>
That is exactly what I had in mind (except that you went more granular by
constraining individual action events - cool!). But how do we associate a
turbine action with security constraint? Surely not with actions.xreg? Or do
we "embed" security contraint within an action (via hardcoding or property
entry)?
Best regards,
Mark C. Orciuch
Next Generation Solutions, Ltd.
e-Mail: [EMAIL PROTECTED]
web: http://www.ngsltd.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
