Wiki source code of Access Rights
Version 33.1 by Irina Hrehorciuc on 2016/05/05
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
23.1 | 1 | {{warning}} |
| 2 | Since XWiki 5.0, a new [[Security Module>>extensions:Extension.Security Module]] is in place. While it is almost compatible with the previous right system, it introduce some subtle differences. For the most accurate information, you should refer to the [[Security Module Documentation>>extensions:Extension.Security Module]]. | ||
| 3 | {{/warning}} | ||
| 4 | |||
 |
7.1 | 5 | {{box cssClass="floatinginfobox" title="**Contents**"}} |
| 6 | {{toc/}} | ||
| 7 | {{/box}} | ||
| 8 | |||
 |
12.1 | 9 | [[Rights can be managed>>platform:Features.RightsManagement]] or configured to work on different scopes or layers. Permissions set at a wiki wide level will be overridden by permissions set at a space level which in turn are overridden by permissions set at a page level. |
 |
1.1 | 10 | |
| |
12.1 | 11 | You can give a user access to edit pages in only one space by denying them access to the entire wiki then explicitly granting them access to edit in the given space. |
| 12 | |||
| |
19.1 | 13 | When multiple permissions are set at the same level, deny permissions always overridde the other ones. Denying **view** access implicitly denies **edit** access also. |
| |
12.1 | 14 | |
 |
18.5 | 15 | {{warning}} |
| 16 | If a user is not able to edit a page despite being explicitly granted permission, double check that a group which the user is a member of isn't denied access to that page. | ||
| 17 | {{/warning}} | ||
| |
12.1 | 18 | |
| 19 | Based on those simple rules and a few types of activities which can be permitted or disallowed, complex permissions constructs can be built. | ||
| 20 | |||
| 21 | = Permission Types = | ||
| 22 | |||
| |
18.5 | 23 | * **view** : This gives the user the ability to view a document or load it using the API. |
| 24 | * **comment** : This gives the user the ability to add a comment. | ||
| 25 | * **edit** : This gives the user the ability to edit the page and all of its objects. | ||
| 26 | * **delete** : This gives the user the ability to put the page into the recycle bin. | ||
| 27 | |||
| |
12.1 | 28 | == Special permissions == |
| 29 | |||
| |
18.5 | 30 | * **admin** : This permission is special because it can only be granted on a space or an entire wiki. Admin status is "undeniable" in that an admin of a wiki cannot have their admin status denied for a space. Technically speaking, admin grants a user view, comment, edit, and delete permission with the added ability to permanently delete a page from the recycle bin. |
| |
12.1 | 31 | |
| |
24.1 | 32 | * **programming** : This is the holy grail of permission. A programmer is allowed to execute arbitrary java code in the wiki and can thus gain control of the system user which the wiki is running under. Obviously this permission should be treated with respect. Any page which was last saved by a programmer is blessed with the power to run dangerous scripts so to minimize security concerns, programmers should be encouraged to register additional user names for the day to day changes which do not require such power. Because it effects the entire wiki (or wiki farm), programming permission can only be set on ##XWiki.XWikiPreferences## and in a multi-wiki environment (farm), it can only be set for users of the main wiki. Note that having programming rights imply having the admin rights. |
| |
12.1 | 33 | |
| |
18.5 | 34 | * **register** : This permission is usually only granted or revoked for the guest pseudo-user (XWiki.XWikiGuest) and gives the guest the power to register on the wiki. This permission can only be set on ##XWiki.XWikiPreferences## and is available in the administration interface. |
| 35 | |||
| |
24.1 | 36 | * **subwikicreation** (since 5.2 M2) : This permission allow the user to create subwikis. It can only be set on ##XWiki.XWikiPreferences## and it can only be set for users of the main wiki. |
 |
20.1 | 37 | |
| |
7.2 | 38 | = Wiki Access Configuration = |
| |
18.5 | 39 | |
| |
7.1 | 40 | The first thing you will 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: |
| 41 | |||
| 42 | * [[Open Wiki>>#HOpenWiki]]: anyone can edit pages (including non registered users) | ||
| 43 | * [[Public Wiki>>#HPublicWiki]]: only registered users can edit pages but registration is open to anyone. This is the default configuration of the default wiki (the wiki provided as a XAR on the [[download page>>xwiki:Main.Download]]). | ||
| |
12.1 | 44 | * [[Public Wiki with confirmed registration>>#HPublicWikiwithconfirmedregistration]]: like ordinary public wiki but newly registered users must enter a token which is emailed to them. |
| |
7.1 | 45 | |
| |
18.5 | 46 | Also, a common use case in your wiki access configuration can be to [[prevent regular users to create new spaces>>#HPreventregularusersfromcreatingnewspaces]]. |
 |
17.1 | 47 | |
| |
7.1 | 48 | == Open Wiki == |
| 49 | |||
| |
18.5 | 50 | You can configure your wiki to be open, so that everyone can edit and comment without registering or logging in. To do this simply add a user called ##XWiki.XWikiGuest## and grant him the permissions you want to be granted to guests. |
| |
7.1 | 51 | |
| |
18.5 | 52 | {{warning}} |
| 53 | There is currently no way to hand each guest a temporary account based on their IP address so an open wiki on the public internet may not be a good decision. | ||
| 54 | {{/warning}} | ||
| 55 | |||
| |
7.1 | 56 | == Public Wiki == |
| 57 | |||
| |
18.5 | 58 | Nothing to do. This is the default configuration. |
| |
7.1 | 59 | |
 |
23.2 | 60 | === Captcha for guest users for commenting === |
| |
7.1 | 61 | |
| |
23.2 | 62 | {{info}}Since [[XWiki Enterprise 2.3M1>>xwiki:ReleaseNotes.ReleaseNotesXWikiEnterprise23M1]]{{/info}} |
| 63 | |||
| |
18.5 | 64 | It is nice to allow guests to comment on a page, often the most helpful people are unwilling to go to the bother of registration and it creates a more open atmosphere. Unfortunately comments can contain links which can be used as a vector for search engine spam. To keep your site open while preventing automated commenting, you can require 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 so you don't need to worry about guests' idle surfing causing the [[captcha module>>extensions:Extension.Captcha Module]] to use too much of your server's CPU power. |
| 65 | |||
| |
7.1 | 66 | You can require guests to fill out a captcha for posting comments on a wiki or space level. You can require it on the wiki level but remove that requirement for a single space, or you can require it only for one or more spaces but not the entire wiki. |
| 67 | To turn on comment captcha requirement, go to wiki or space administration, click on the "Rights" section and notice the checkbox toward the bottom labeled "Require unregistered users to solve a captcha when posting a comment on a page". Check that box and guests will be required to solve a captcha to comment. | ||
| 68 | |||
| |
18.5 | 69 | {{info}} |
| 70 | This setting does not allow guests to comment, it only denies them permission to comment without a captcha on pages where they already had it. To allow commenting, you will have to check the normal "allow comment" checkbox for unregistered users. | ||
| 71 | {{/info}} | ||
| 72 | |||
| 73 | Example: | ||
 |
18.3 | 74 | {{image reference="CaptchaComment.png"/}} |
| |
7.1 | 75 | |
| |
12.1 | 76 | == Public Wiki with confirmed registration == |
| 77 | |||
| |
18.5 | 78 | To require users to register with a valid email address, you can require them to confirm their registration. To do this, open the administration interface for the wiki and navigate to the registration section: |
| |
12.1 | 79 | |
| |
18.5 | 80 | * "Use email verification" sends an email to the email address that the user registered with. Be sure the [[SMTP server>>platform:AdminGuide.Configuration#HConfiguringtheSMTPserver]] is configured correctly |
| 81 | * "Check Active fields for user authentication" will prevent the user from logging in until they have entered the token which is sent in the email | ||
| 82 | * "Validation e-Mail Content" is the content which will be placed in the email | ||
| 83 | |||
| |
12.1 | 84 | === Options === |
| |
18.5 | 85 | |
| |
12.1 | 86 | ; Email address confirmation |
| 87 | : Set "Check Active fields for user authentication" and "Use email verification" to "YES". Changes to "Validation e-Mail Content" are optional but must still contain the link to activate the account. | ||
| 88 | ; Friendly welcome message | ||
| 89 | : Set only "Use email verification" to "YES" and change "Validation e-Mail Content" so that it doesn't mention verification since it's not needed. | ||
| 90 | ; Registration subject to admin approval | ||
| |
18.5 | 91 | : Set "Check Active fields for user authentication" and "Use email verification" to "YES" and change "Validation e-Mail Content" so that it explains that the registration is subject to approval and most importantly, remove the validation link. An admin can then change the "active" setting in the object editor on the user's document (the editor for the admin is located at: //{{{http://127.0.0.1:8080/xwiki/bin/edit/XWiki/Admin?editor=object}}}//) |
| |
12.1 | 92 | |
| |
18.5 | 93 | {{info}} |
| 94 | To require the user to provide an email address when registering, see the registration page configuration, part of the [[Administration Application>>extensions:Extension.Administration Application]]. | ||
| 95 | {{/info}} | ||
| |
12.1 | 96 | |
| |
17.1 | 97 | == Prevent regular users from creating new spaces == |
| 98 | |||
| |
18.5 | 99 | You can restrict the creation of new spaces to users with administrative privileges by following these steps: |
| |
20.1 | 100 | |
| |
18.5 | 101 | * In the global rights, deny write access to the ##XWikiAllGroup## group and the ##XWikiGuest## user and allow edit access to the ##XWikiAdminGroup## group |
| 102 | * In each space rights, allow write access to the ##XWikiAllGroup## group | ||
| |
17.1 | 103 | |
| |
12.1 | 104 | = An overview of permissions = |
| |
7.1 | 105 | |
| |
18.5 | 106 | Here is a full listing of all the rights available in XWiki Enterprise and their default setting: |
| 107 | |||
| |
6.1 | 108 | * //**Right name:** brief description of the right// |
| 109 | ** //Availability: at what level can you set this right?// | ||
| 110 | *** //Page: this right can be set at the page level// | ||
| 111 | *** //Space: this right can be set at the space level// | ||
| 112 | *** //Wiki: this right can be set at the wiki level// | ||
| 113 | ** //Default status: is the right allowed or denied when the checkbox is left blank?// | ||
| |
18.5 | 114 | *** //**ALLOWED**: this means that users **CAN** perform the given action if no other right is set// |
| 115 | *** //**DENIED**: this means that users **CANNOT** perform the given action if no other right is set// | ||
| |
6.1 | 116 | ** //Priority order: which setting wins over another if an user has 2 different settings?// |
| 117 | ** //Checking order: at what level is the right checked first?// | ||
| 118 | * **View:** whether users can see the page | ||
| |
3.1 | 119 | ** Availability: |
| 120 | *** Page | ||
| 121 | *** Space | ||
| 122 | *** Wiki | ||
| |
18.5 | 123 | ** Default status: **ALLOWED** |
| |
2.1 | 124 | ** Priority order: deny > allow > no setting |
| |
3.1 | 125 | ** Checking order: page > space > wiki |
| |
6.1 | 126 | * **Comment:** whether users can add a comment to the page |
| |
3.1 | 127 | ** Availability: |
| 128 | *** Page | ||
| 129 | *** Space | ||
| 130 | *** Wiki | ||
| |
18.5 | 131 | ** Default status: **ALLOWED** |
| |
2.1 | 132 | ** Priority order: deny > allow > no setting |
| |
3.1 | 133 | ** Checking order: page > space > wiki |
| |
6.1 | 134 | * **Edit:** whether users can edit and save modifications to the page |
| |
3.1 | 135 | ** Availability: |
| 136 | *** Page | ||
| 137 | *** Space | ||
| 138 | *** Wiki | ||
| |
18.5 | 139 | ** Default status: **ALLOWED** |
| |
2.1 | 140 | ** Priority order: deny > allow > no setting |
| |
3.1 | 141 | ** Checking order: page > space > wiki |
| |
6.1 | 142 | * **Delete:** whether users can delete the page |
| |
3.1 | 143 | ** Availability: |
| 144 | *** Page | ||
| 145 | *** Space | ||
| 146 | *** Wiki | ||
| |
18.5 | 147 | ** Default status: **DENIED** (unless you're the document creator) |
| |
2.1 | 148 | ** Priority order: deny > allow > no setting |
| |
3.1 | 149 | ** Checking order: page > space > wiki |
| |
6.1 | 150 | * **Admin:** whether users can manage administration settings for the space / wiki |
| |
3.1 | 151 | ** Availability: |
| 152 | *** Space (Automatically includes the view, comment, edit, delete rights) | ||
| 153 | *** Wiki (Automatically includes the view, comment, edit, delete, register, program rights) | ||
| |
18.5 | 154 | ** Default status: **DENIED** |
| |
2.1 | 155 | ** Priority order: allow > deny > no setting |
| |
3.1 | 156 | ** Checking order: wiki > space |
| |
6.1 | 157 | * **Register:** whether users can create new user accounts |
| |
3.1 | 158 | ** Availability: |
| 159 | *** Wiki | ||
| |
18.5 | 160 | ** Default status: **ALLOWED** |
| |
2.1 | 161 | ** Priority order: allow > deny > no setting |
| |
3.1 | 162 | ** Checking order: wiki |
| |
11.1 | 163 | * **Program:** whether protected APIs & Groovy code available in wiki pages last saved by this user |
| |
3.1 | 164 | ** Availability: |
| 165 | *** Wiki | ||
| |
18.5 | 166 | ** Default status: **DENIED** |
| |
2.1 | 167 | ** Priority order: allow > deny > no setting |
| |
3.1 | 168 | ** Checking order: wiki |
| |
22.1 | 169 | * **Subwiki Creation:** whether users can create subwikis |
| |
21.1 | 170 | ** Availability: |
| 171 | *** Wiki | ||
| 172 | ** Default status: **DENIED** | ||
| 173 | ** Priority order: allow > deny > no setting | ||
| 174 | ** Checking order: wiki | ||
| |
2.1 | 175 | |
| |
16.1 | 176 | = Note on permission inheritance = |
| 177 | |||
| |
18.5 | 178 | When a permission is explicitly set for a given group or user at a certain scope (page, space or wiki) then other groups and users must also have the right explicitly set as well, at this scope or a scope upstream. |
| |
16.1 | 179 | |
| |
18.5 | 180 | For example, when you decide to explicitly allow the view right for "GroupA" on a given space, users that are not members of "GroupA" must have the view right explicitly set either on the given space or on the whole wiki to be able to view the space as well. |
| |
16.1 | 181 | |
| |
12.1 | 182 | = Further Reading = |
| |
18.5 | 183 | |
| |
15.1 | 184 | * Permissions management can easily be done using the [[rights management interface>>platform:Features.RightsManagement]] |
| |
14.2 | 185 | * The "administration interface" is documented in the [[Administration Application>>extensions:Extension.Administration Application]] |
 |
17.3 | 186 | * You can of course get more information about permission management from {{scm path="xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java"}}the code itself{{/scm}}. |
