David, > > > > No, I don't have any insight for you yet but I'm trying to make sure I > > understand your intent here. You want to secure portlet and its > action as > > one (i.e. portlet action should always use security of the portlet it is > > associated with), right? And you don't want to do something like > > that in the > > base action class: > > > > JetspeedSecurity.checkPermission(rundata, > > JetspeedSecurity.PERMISSION_VIEW, > > portlet); > > Exactly, but I can't get to the 3rd parameter 'portlet' - it > should be soooo > easy but its not > > > > > Whatever we come up with, has to be done with JspPortletAction as > > well. What > > +1
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? > > > 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. Best regards, Mark C. Orciuch Next Generation Solutions, Ltd. e-Mail: [EMAIL PROTECTED] web: http://www.ngsltd.com > > > > > > > -----Original Message----- > > > From: David Sean Taylor [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, October 11, 2002 11:50 PM > > > To: Jetspeed Developers List > > > Subject: Securing VelocityPortlet actions > > > > > > > > > I'd like to use the Jetspeed Security registry for securing access to > > > Velocity portlet actions. > > > I believe that Velocity portlet action events are very big > > > security hole in > > > Jetspeed, and it should be fairly simple to plug it, one would think. > > > A few weeks ago I reviewed the code, and it was the same old > > situation: we > > > are in the action, but do we have access to the portlet.... > > > > > > To make a long story short, I failed to get access to the > portlet in the > > > action when I needed it -- when an action event kicks off, it > > doesn't know > > > about its portlet. Correct me if Im wrong....I can just hear > > Raphael "its > > > easy, just do this..." and I hope he does, really. > > > > > > But since the action kicks off before the instance is created, > > > its even more > > > difficult to get the portlet instance security-ref. > > > > > > Any insight on how to get the security constraints during an > > action event? > > > I would like to put this code in one of the base classes. I don't > > > want to be > > > checking security in each and everyone of my action events. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
