Wiki source code of Access Rights

Last modified by Thomas Mortagne on 2023/10/10

Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 = Basic rules =
6
7 * XWiki provides the ability to set wiki wide rights, granular page level rights and the ability to have programmatic rights, in case you need more control. Thanks to the different levels of control offered by XWiki, it's easy to manage the access to actions like: read, edit, comment etc.
8 * You can create groups of users in order to manage the rights of a category of people more easily.
9 * Permissions set at a wiki wide level will be overridden by permissions set at a page level, which have priority.
10 * When multiple permissions are set at the same wiki/page level, check the priority order of the right in [[permission type>>Documentation.AdminGuide.Permission types.WebHome]] to know if access will be allowed or denied.
11 * When a right has been allowed at a given level, it gets implicitly denied to anyone else at the same level. This only applies to the right allowed. If only "View" is set to a user/group at this level, all other rights like "Edit" are still inherited. Using this implicit deny behavior is recommended over applying explicit denial.
12 * The scope of the right applied ("Page" or "Page & Children") affects the implicit denial. If the right is applied for the page only, pages below the current page will still inherit the wiki/higher level pages rights.
13 * Implied permissions like VIEW of the EDIT right are not implicitly denied when EDIT is set. User/Groups with the VIEW right are still inherited if the page has EDIT explicitly set for a User/Group.
14 * On the contrary, an explicit denial does not block inheritance for the right denied.
15 * When a permission is explicitly set for a given group or user at a certain scope (page or wiki) then the other groups and users must also have the right explicitly set as well if they need access. For example, when you decide to explicitly allow the view right for "Group A" on a given page, users that are not members of "Group A" must have the view right explicitly set on the given page to be able to view it as well.
16 * The wiki owner and the superadmin account always have full admin privileges regardless of the rights configured.
17 * The EDIT right also controls page creation rights. Denying EDIT at the wiki level will not allow a user/group to create pages anywhere unless Allowed at the Page & Children level. Denying EDIT on on Page/Space will deny editing the main page, but allow pages to be created in the space.
18
19 = Wiki Access Configuration =
20
21 The first thing you may want to do is configure a **policy access** for your wiki. Depending on what you intend to use your wiki for, you have several options: you can configure your wiki to be public, so that people can edit and comment without necessary being registered or logged in or you can limit the access only to registered users, by configuring a private wiki.
22
23 == Open Wiki ==
24
25 To have an open wiki where everyone can perform actions like comment or edit, all you have to do is configure the permissions you wish to give to the Guest user, from the Rights administration page, as shown in the following screenshot:
26
27 {{image reference="guest-permissions" width="650px"/}}
28
29 Letting guests comment on a page creates a more open atmosphere. Often, the most helpful people are unwilling to bother with registration. However comments can be a vector for search engine spam. From a security point of view, you can keep your site open while preventing automated commenting by requiring guests to fill out a captcha before commenting. The captcha will not be displayed or even loaded until they click on the comment window to type their message.
30
31 {{image reference="CaptchaComment.png"/}}
32
33 To find out more please access the [[Documentation.AdminGuide.Captcha configuration.WebHome]] tutorial.
34
35 == Public Wiki with Confirmed Registration ==
36
37 [[Documentation.AdminGuide.Public Wiki with confirmed registration.WebHome]] means users are required to register with a valid email address. To do this, open the administration interface for the wiki and navigate to the registration section, where you will find several configuration options:
38
39 * **Use email verification**
40 * **Check Active fields for user authentication**
41 * **Validation e-Mail Content**
42
43 Make sure you have performed the e-mail configuration on your instance. You can find more info in the [[Extensions>>extensions:Extension.Mail Application]] page.
44
45 {{warning}}
46 Before enabling the "Authentication Active Check" make sure your user is active. Edit your User Profile in object mode and look for "Active" property in XWiki.XWikiUsers object. Make sure it is set to "Active".
47 {{/warning}}
48
49 == Private Wiki ==
50
51 A Private Wiki means that only specific users can see the wiki content, browse it, edit it etc. Guests will not be able to see the content of the wiki.
52
53 To be able to prevent the access of unregistered users, you must check the options **Prevent unregistered users from viewing/editing pages, regardless of the page or space rights** from Administration > Users > Rights
54
55 (((
56 {{image reference="RestrictedAccessGuests.png"/}}
57 )))
58
59 You should note that if you "Prevent unregistered users from viewing all pages" there are currently some limitations:
60
61 * Color Themes are pages and thus your current Color Theme won't be accessible for unregistered users who'll get the default Color Theme. To fix this, you'll need to give view access to unregistered users on your Color Theme page.
62 * In addition to the Color Theme not being available, the icon font will not be rendered visible, hiding the Search and Hamburger Menu links in the upper-right corner. They are still accessible, but invisible.
63 * Forgot Username and Forgot Password functionality will not be available. See [[JIRA-14544>>https://jira.xwiki.org/browse/XWIKI-14544]].
64
65 = Main Wiki Access Rights =
66
67 To change rights for the main wiki, log in as Administrator, click the {{image reference="DrawerMenuIcon.png"/}} button to open the drawer menu, then click on "Administer Wiki".
68
69 {{image reference="AdministerWikiMenu.png"/}}
70
71 In the wiki administration page, click on the "Rights" link from the vertical menu to the left.
72
73 {{image reference="AdministrationRights.png"/}}
74
75 Next, select the users or groups for which you want to set a permission for. Note that if you are on the main wiki, you are editing the rights for global users and groups. Global user/groups are defined on the main wiki. If you are editing rights on a sub-wiki level, you can choose Local users/groups which are users/groups defined for the sub-wiki only or Global users/groups.
76
77 {{image reference="GroupRights.png"/}}
78
79 Click once on a check-box to allow a right, twice to deny it and three times to clear the right and use the default values. Note that rights entries are saved automatically.
80
81 = Sub-Wiki Access Rights =
82
83 You can consult the specific [[Documentation.AdminGuide.Sub-Wiki access rights.WebHome]] documentation page to make sure you set correctly the sub-wiki access rights.
84
85 = Page Access Rights =
86
87 {{info}}
88 Starting with XWiki 7.2, we have introduced the possibility to create pages inside other pages. This feature is called Nested Pages. Check the [[Content Organization page>>Documentation.UserGuide.Features.ContentOrganization]] to understand better how it works.
89 {{/info}}
90
91 == Setting Rights for a Page and Its Children ==
92
93 If you have a page A and there are several other pages created as children of page A, you can set rights for page A (as parent) and the children pages can inherit the same rights.
94
95 To edit the access rights for a page, simply navigate to that page, click the cog button, then on "Administer Page". You will be redirected to a UI ("WebPreferences") with 2 options in the menu on the left under "Users & Groups":
96
97 (((
98 {{image reference="PageMenuNonTerminal.png"/}}
99 )))
100
101 * **Rights: Page & Children** - allows to set the permissions scheme that will apply on the current page and all its children.(((
102 {{image reference="PageAndChildrenRights.png"/}}
103 )))
104 * **Rights: Page** - allows to set the permissions scheme that will apply on the current page only.(((
105 {{image reference="PageRights.png"/}}
106 )))
107
108 Click once on a check-box to allow a right, twice to deny it and three times to clear the right and use the default values.
109
110 == Setting Rights for a Terminal Page ==
111
112 A terminal page is a wiki page that cannot have children and it is usually created by applications and scripts. Terminal pages don't have a "Preferences" document. This is the reason why, in order to set the access rights for a single page, you will have to click the editing pen icon, then choose "Access rights".
113
114 (((
115 {{image reference="PageMenuTerminal.png"/}}
116 )))
117
118 = Further Reading =
119
120 * Find our more about [[Documentation.AdminGuide.Permission types.WebHome]].
121 * The "administration interface" is documented in the [[Administration Application>>extensions:Extension.Administration Application]].
122 * You can of course get more information about permission management from the code itself.

Get Connected