Is security constraint enforcement implemented for portlets? Constraints work fine for me when used with pages and folders.
But on the level of portlets, whether I configure a 'deny' constraint with jetspeed-portlet.xml (at app level or portlet level) or using the Admin portlet to edit the portlet metadata, my portlet still renders itself on the page without complaint even when the user's not logged in. It happens even if I delete the user view/edit Permission that's created by default for my portal app war. I am guessing that this doesn't bother people because they use only page-level security? Or they secure only one page's instance of a portlet via a fragment? Just to check that it's not my portlet specifically, I stuck an instance of j2-admin::RegistryApplicationsList on my subsite home page (portlet should have constraint 'admin' from its app) and it too gets displayed even when a user's not logged in. Maybe it's a configuration flag somewhere, or maybe I've just failed to grasp how the security inheritance and permission/constraint combination works. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
