Private Wiki Setup

Help / Discuss
1

I want to setup a private wiki for my company and customers which uses sub pages (spaces) to separate content and to use fine grained access rights. I am using Confluence for 15 years and briefly tried XWiki in 2021 while reviewing its capabilities. Now I am setting up our production environment. The initial setup is always the most complex part because often mistakes done at beginning cannot easily be changed at a later time.

The first step was to block access to all unregistered users in the global access right settings. Then XWikiAllGroup was modified to deny view,comment,edit rights. Therefore newly added users will have default rights unless they get added to a different group.

XWikiAllGroup only gets view access to /xwiki/bin repectively /xwiki/bin/view/Main which is the Home page of the wiki.

https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki mentions some limitations but does not list any further details. I managed to load the default theme by granting XWikiAllGroup view rights to /xwiki/bin/view/FlamingoThemes/Iceberg. But I could not get FontAwesome to be loaded for those users. All menus and other icons are so far blank. How can this be changed?

The user profile should also be accessible by logged in users. Later we will add private sections for some of the users.

The navigation panel should also be loaded. Currently no further content is being loaded. I could not find a page which renders the navigation panel. How can this be changed?

It is quite strange that modifying the rights checkboxes has immediate effects i.e. users have temporarily higher/lower rights during their user setup. This makes me feel uncomfortable and I want to avoid such situations at all costs. This is a significant security issue. It would be great to log in as a different user without knowing their password to check their permissions are correct. So far, I added some test accounts for this purpose. Accessing other accounts also helps in training and maintenance.

I have more questions later on. Let me focus first on the initial setup and on other usability related topics next.

Thanks,
Christoph

2

Hi @cbratschi,

XWiki is designed, by default, as an open wiki, where any user has access on any page. Starting to cut view rights as you did will result in the behavior you described.
If you want to restrict the users access to a single space, you will actually need to give view rights to a lot of resources in order to get the full UI. So, you will need also to make sure the users have view right on some various types of pages:

  1. Skin
  2. Color theme
  3. Panels
  4. Extension points
  5. Other technical pages containing JSX and SSX objects

As you can see, this approach can increase the rights’ complexity to a level that it cannot be easily maintained.
It is recommended to use the strategy of generally allowing and explicitly denying where is the case over the strategy of generally denying and explicitly allowing where is the case.

Hope it helps,
Alex

3

Well, I tried the global allow approach and deny on a page level. But there is a big problem: deny has a higher priority than allow on the page level. For instance if access to a page is denied to all XWikiAllGroup members, any allow in other groups are ignored. I could not find a way to get an easy to manage setup that way.

The Admin Tools extensions has a page which displays all rights of spaces and application pages. It is probably easier to continue with my first approach and to configure those spaces’ access rights. Will have to try this again.

It is fine if the initial setup is more complicated, if it works and saves time later on. Configuring Confluence was always quite complicated and even their cloud version still uses the same management interface. I made some mistakes once and don’t want to repeat this again.

4

The Deny is stronger than Allow, indeed. In this case it’s a matter on how users are added to the groups. Maybe you don’t need to deny the rights to XWikiAllGroup but to use a new group and deny access for that new group.
If you deny rights on XWikiAllGroup and allow rights to another group, you are doing again some deny by default everything add allow on specific situations which is the opposite of the rights management design in XWiki.