Return-Path: Delivered-To: apmail-jakarta-jetspeed-dev-archive@apache.org Received: (qmail 45912 invoked from network); 22 May 2002 14:16:43 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 May 2002 14:16:43 -0000 Received: (qmail 10493 invoked by uid 97); 22 May 2002 14:15:10 -0000 Delivered-To: qmlist-jakarta-archive-jetspeed-dev@jakarta.apache.org Received: (qmail 10381 invoked by uid 97); 22 May 2002 14:15:09 -0000 Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jetspeed Developers List" Reply-To: "Jetspeed Developers List" Delivered-To: mailing list jetspeed-dev@jakarta.apache.org Received: (qmail 10209 invoked by uid 98); 22 May 2002 14:15:08 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: From: Glenn Golden To: "Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)" Subject: Security for Portlet State (customize, maximize, minimize, close) not working Date: Wed, 22 May 2002 10:22:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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! **************************************** 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"? Thanks. - Glenn -------------------------------------------- Glenn R. Golden, Systems Research Programmer University of Michigan School of Information ggolden@umich.edu 734-615-1419 -------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: