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#3983758
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983758
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
