Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: How to keep Users out of the private child site?
Hi all,
We're using Liferay CE 7.3.3 and we'd like to have a site hierarchy where content is shared from a parent site to a child site, but only a subset of the parent site's users (marked by membership to a UserGroup) should be able to access the private pages of the child site.
Our current setup looks like this:
- The ParentSite is set as default association to each new user, so all our Users are members of that parent site.
- The ChildSite is a child of ParentSite, using content, structures and templates from the ParentSite.
- The ChildSite is set to "private", which means that "A Site Administrator must explicitly invite a User to join and then add them to the Site. Private membership Sites don’t appear in the My Sites app." according to the docs.
- Users are added to the ChildSite by adding them directly (I'll call those "explicit members") or adding them to a UserGroup which is member of the ChildSite.
- The private pages of the ChildSite only have permissions for the owner and SiteMembers.
So far, after sifting through ControlPanel, Liferay docs, the internet and some of Liferay's code, I'd think that a User who is a member of ParentSite, but not an explicit member of neither ChildSite nor the UserGroup that is member of ChildSite can NOT access the private pages of ChildSite. After all, I did not find any mention along the lines of "SiteMembers of a ParentSite are automatically SiteMembers of a ChildSite".
But, according to my tests, apparently any authenticated User can access the private pages of the ChildSite -- I even removed a User from the ParentSite and tested again: That User can still access the private pages of both sites (but I'm willing to put that down to caching issues).
Does anybody have an inkling of an idea where my line of thinking is wrong? Or how do I have to configure the Sites so that content sharing from my ParentSite to ChildSite does work, but SiteMembership is not inherited?
Thanks for any idea,
Dave
Hi Dave,
I've read through your post and what I think is
1. It makes sense to me that all members of the parent site would be members of the child site--in fact, I imagine that's a big part of the reason you'd want child sites--membership inheritance. I might be thinking about this wrong, not having recently messed with this functionality.
2. It does not make sense to me that someone who's neither a parent or child site member would be able to see the private pages of the child site.
My first timpulse is that, if you don't want site membership inheritance, you don't want a child site at all. You want a separate site whose membership is granted by inclusion in the User Group.
Hi Russell,
Thanks for your answer.
Yes, I agree that membership inheritance would be one reason to have child sites -- but the docs (that I found) do advertise child sites more along the lines of content inheritance, which is the main reason why we did model the second site as a child site. There's basically no mention of users being inherited automatically, especially since the site settings say that every member must be invited by a site administrator -- so that did come as a surprise to us.
So, we're looking to share content (and page fragments etc) down to the child site, but only a subset of the users should be inherited. Organizations do have a setting to adhere to strict membership management (organizations.membership.strict=true in portal.properties), but I don't see anything like that for a site hierarchy.
As an aside: I really need a tool to determine why a particular user has a particular permission; because there's nothing in the UI to debug that ... I don't even know why my users can see the private pages of the child site, because I cannot see if it is because of inherited SiteMembership or because someone set the wrong permission somewhere or because of a mechanism I'm not even aware of.
Yeah, the first thing to solve might be figuring out why you can't get rid of any single User from that child site--that could be mucking up the testing. Maybe try to remove the default associations aspect?
A Permission Checker tool would be interesting--I've requested more robust Control Panel views around Users and Permissions in the recent past (User tables with complex filtering ability), but I wouldn't hold my breath that this type of thign will get into the poroduct soon.
Tested removing default associations, but same picture. There's another possibility ... the ParentSite I mentioned is built from the default site that is created on the first Liferay initialization run. It also is the Group returned by PortalUtil.getDefaultCompanyGroup for the only company in our instance.
Could it be that a User is automagically a SiteMember of the DefaultCompanyGroup and there's no way to change that?
Yes, absolutely. I would definitely test outside of the default site.
Powered by Liferay™