Page security not working in 2.6.2GA?

[nollie]

Hello

I'm working with jboss-portal-2.6.2.GA-bundled on Windows. I have unzipped and started the server. I haven't changed a single config file.

When I try to apply page level security constraints through the Admin portlet, I don't see any difference in behavior. I have restricted the weather page to only allow Admin users to view, viewrecursive, personalize, and personalizerecursive, yet when I try to view that portlet as a user who has not logged in, I can still see the page and the portlet.

When I apply the same settings to the portlet instance, I immediately see the results I am expecting: the page opens but the weather portlet is absent.

Is this a bug or am I doing it wrong? I've been through the manual and the reference but I don't see my mistake. I really want to be able to restrict access to a page and send people to the default homepage when they try to access that page.


Nollie

[theute]

There are several threads on the subject.
Security is additive. you have a parent object with has view-recursive right.

[nollie]

Yes. The parent of the Weather page is the portal itself.

The portal has given "Role Unchecked" view and viewrecursive permissions so that unauthenticated users can navigate the portal - all pages inherit those security settings so I don't have to set them again and again.

What I want to do is restrict access to the Weather page so that only admins can see it. Surely this is possible, right? Your answer seems to imply that I would have to remove view/view recursive from the portal and instead set that for every page other than the weather page?

I appreciate your help in understanding this.

nollie

[peterj]

nollie, your assumption is correct: you have to remove view/view recursive from the portal and set it for every page or portlet instance.

For other threads on this topic, see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98753

and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115712

[hamptont]

This make managing the page security very difficult if this is true. The portal pages are a tree and each node in the tree "should" be able to declare the security for itself and it's subtree overriding inherited attributes if desired.

For example the tree below

 A
 /\
 B C
 /\
 D E

If node A is unrestricted and view/view recursive then nodes B & C should be visible by default to all. However, node C should be able to override inherited attributes and change security to be restricted for itself and it's subtree. Node C should also be able to terminate recursion of inherited attributes.




Tom

[nollie]

"PeterJ" wrote:
nollie, your assumption is correct: you have to remove view/view recursive from the portal and set it for every page or portlet instance.

Thanks for your response Peter - that was driving me nuts. I have to say though, that this is the answer I didn't want to hear. The portal I'm working on has over a hundred pages and I'm only interested in securing 2 or 3. Given this permission granting scheme I have to add markup to 100 pages (and all future pages) so that I can hide my admin tools.

The security scheme would be fine if one could override at any node. I could have a public portal, allow most of my pages to inherit that, and then put markup on 3 pages to check for the Admin role.


Nollie