I'm having difficulty understanding the expected behavior of the 'viewrecursive' constraint action. If I define a page with a viewrecursive security constraint, I would expect any subpages to inherit that same constraint. For example, given a deployment structure like: | <page> | <page-name>A</page-name> | ... <!-- page contents --> | <page> | <page-name>B</page-name> | ... <!-- page contents --> | <!-- no explicit security constraint --> | </page> | <security-constraint> | <policy-permission> | <role-name>RoleA</role-name> | <action-name>viewrecursive</action-name> | </policy-permission> | </security-constraint> | </page> | I would expect that page 'B' would be viewable by (and only by) 'RoleA' users. Instead, page 'B' ends up with an [unchecked: viewrecursive] constraint. The implementation of org.jboss.portal.core.metadata.PortalObjectMetaData implies this is intended behavior: | if (securityConstraints == null) | { | if (this instanceof PortalMetaData || this instanceof PageMetaData) | { | // Default is view recursive | securityConstraints = new SecurityConstraintsMetaData(); | RoleSecurityBinding binding = new RoleSecurityBinding(PortalObjectPermission.VIEW_RECURSIVE_ACTION, SecurityConstants.UNCHECKED_ROLE_NAME); | securityConstraints.getConstraints().add(binding); | } | } | If this is really intended, then what are the semantics of 'viewrecursive'? It doesn't seem to have any effect on subpages at all, if those pages will always default to [unchecked viewrecursive] Meanwhile, I'll just provide an explicit security constraint on each page, but I feel like I shouldn't have to. p View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983758#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...