Page Security & Membership
[Plugin: Page Security by Contexture] sub-page Cascaded Groups (4 posts)

  1. Charles640
    Posted 4 years ago #

    It looks like if I have a secured page, and put a sub-page under it, the limits on the top page cascade down to the sub-page. It always seems to me that one should put the more general page on the top, and the more restricted pages underneath it.

    e.g., in my case, the top page is open to all members. One of the ones underneath it is open only to members of one committee.

    Is there any way for me to state "subtract the group 'member'" from the cascade options?

    (just FYI, I have more than 35 years of IT experience, and 10 of them were specific to the security field.)


  2. Matt van Andel
    Plugin Author

    Posted 4 years ago #

    You are absolutely correct in that permissions of parent content "cascade down" to subpages. The general thinking here is that if you need to protect a page or section, then permissions should only get MORE restrictive as you travel down the hierarchy. In other words, permissions work like this:

    "If I am protected, the user must match at least one group attached to me." That recurses up the chain with each parent/ancestor - so the user must effectively belong to at least one group from each protected page in the current page's hierarchy.

    For instance, you might set up a system like this.

    -- Parent 1 - Restricted to group "Registered Users". Users must be logged in to access.
    ----- Child 1 - Restricted to group "Staff". Users must be logged in AND a member of "Staff" to access.
    -------- Descendant 1 - Restricted to group "Managers". To access, user must be a member of "Staff" (inherited from Child 1) AND "Managers" to access
    -------- Descendant 2 - No additional restrictions. User must simply be a member of "Staff" group.
    -- Parent 2 - No restrictions. Anyone can access (including anonymous).

    Currently, there is no way to "override" requirements inherited from a parent, but I think PSC should be able to meet your needs based on your example. You can further control content access by assigning it to a different parent with the permissions you want it to inherit. This way, your site structure ends up being dictated by your desired permissions, but in most use-cases, this actually ends up helping usability. :-)

  3. Charles640
    Posted 4 years ago #

    Thanks Matt. I'm still a bit confused. You said "If I am protected, the user must match at least one group attached to me." But Descendant 1 is restricted to Managers, but inherits Staff. Since you only need to match one group, that would imply that all Staff members would meet it. But your explanation implies not that the user matches one, but that the user matches both. The latter makes sense, but doesn't match your quoted requirement.

  4. Matt van Andel
    Plugin Author

    Posted 4 years ago #

    Hey Charles. I apologize if that wasn't clear.

    It's not just a matter of matching one group, period... it's a matter of matching one group per page, including not just the current page, but each parent and ancestor that has protection.

    So if you had a [protected] page hierarchy that was 2 pages deep, the check would work like this...

    > User must belong to at least one group in the current page...
    > This page has a parent with additional protection, so...
    > User must ALSO belong to at least one group in this parent page...

    Hope that helps.

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Page Security & Membership
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic