0 Replies Latest reply on Nov 7, 2006 9:13 AM by Peter Halverson

    Behavior of 'viewrecursive' security constraint

    Peter Halverson Newbie

      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