portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Securing VelocityPortlet actions
Date Mon, 14 Oct 2002 20:42:29 GMT
> 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:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message