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
