portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Security for Portlet State (customize, maximize, minimize, cl ose) not working
Date Thu, 23 May 2002 13:02:54 GMT
David -

If you see the logic in how the default permissions work now, then what's
the point of having the roles and the ACL in there at all?

As the code is curreltly written, the only part of the system that actually
checks against the ACL is BasePortletSet, when deciding to show the pencile
(allowCustomize) for a set of menus or tabs - the other checks (those that
involve portlets) skip the ACL completely and go right for the defaults.

This is inconsistent and cannot be right.

I'm looking for a sensible statement that defines what this default
permissions stuff is about.

For non-logged in users, it makes perfect sense.  If we don't know who the
user is, we don't have an ACL, so use the default permissions set for
non-logged in users.

For logged in users, we have an ACL, based on the roles assigned to the
user.  There's a default role, currently set in the jr.p to "user" that new
users get.  That's really our default set of permisions, but it's
controllable by our users - other roles can be used.

As I see it, we need to remove the default permission set for logged in
users, and better integrate that for non-logged in users (so it's used
consistently in the proper places).

- Glenn

> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com] 
> Sent: Wednesday, May 22, 2002 11:00 AM
> To: 'Jetspeed Developers List'
> Subject: RE: Security for Portlet State (customize, maximize, 
> minimize, close) not working
> 
> 
> 
> 
> > -----Original Message-----
> > From: Glenn Golden [mailto:ggolden@umich.edu]
> > Sent: Wednesday, May 22, 2002 7:23 AM
> > To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> > Subject: Security for Portlet State (customize, maximize, 
> > minimize, close) not working
> > 
> > 
> > Define the role "user" permissions in the admin interface -
> > leave only "view" checked.
> > 
> > Portlets for a user (the user has role "user" only) still
> > have minimize, maximize, close, configure icons.
> > 
> > When VelocityPortletContril.buildActionList() checks permissions:
> > 
> > StateFullPortletWrapper.allowCustomize()
> > PortletWrapper.checkPermission()
> > JetspeedSecurity.checkPermission()
> > JetspeedDBSecurity.checkPermission() (line 222)
> > JetspeedDBSecurity.checkPermission() (line 234)
> > 
> > Here it check's the RegistryEntry for the portlet for
> > security, and seing none, calls "checkDefaultPermission()".
> > 
> > If it had seen a role for the Entry, and the user's acl has
> > the role, it goes on to call "checkPermission()".
> > 
> > * Why the two different calls?
> > 
> > Further tracking reveals... In checkDefaultPermissions(), we
> > get the set of permissions for the 
> > "CONFIG_DEFAULT_PERMISSION_LOGGEDIN"., which is "*". The "*" 
> > matches the permission and it is granted.  WRONG!
> > 
> > * Why are we going for default permissions, when I have a
> > logged in user with an ACL?
> > 
> > * * *
> > 
> > Proposal: This code:
> > 
> >     public boolean checkPermission(RunData runData, String
> > permission, RegistryEntry entry)
> > 
> > In JetspeedDBSecurityService is wrong.  It's the only place that
> > checkDefaultPermission() is called, and I believe it should
> > not be doing so. checkPermission(rundata, premission) seems 
> > the proper call.  Just because an Entry has no specific role, 
> > doesn't mean that we should *ignore* the user's role derived 
> > ACL, right?
> > 
> > I'll fix this - but if anyone has another opinion, please speak up!
> > 
> 
> I see the logic of the way it is now. 
> If no security is defined for the entry, then use the default 
> settings from the JRP.
> 
> What your saying is that if there is no security entry, then 
> check to see if any of the user's roles has the permission, 
> and grant access based on that check.
> 
> My original attention was to skip all security checks if no 
> security was defined for a resource, and always grant access. 
> I think I've stated before that my opinion is that portlet 
> security checks should be optional and should not be executed 
> if they are disabled (by default) At that point I was told to 
> go work for M$, oh well... :)
> 
> Perhaps you can make your approach part of the JRP configuration?
> 
> > ****************************************
> > 
> > Another thing - When BasePortletSet.allowCustommize() is
> > called, why does it check for "PERMISSION_INFO" permission?  
> > Does anyone know what "info" means? Why is this not 
> > "PERMISSION_CUSTOMIZE"?
> 
> Seems like a bug (and an easy fix)
> 
> > 
> > Thanks.
> > 
> > - Glenn
> >  
> > --------------------------------------------
> > Glenn R. Golden, Systems Research Programmer
> > University of Michigan School of Information
> > ggolden@umich.edu               734-615-1419
> > --------------------------------------------
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands, 
> > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 

--
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