This page aims at explaining how access rights work in XWiki. It will help you configure access rights on your wiki so that every user can only see and do what he should be allowed to.

Wiki Access Configuration

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:

• Open Wiki: anyone can edit pages (including non registered users)
• Public Wiki: 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).
• Private Wiki with password: registration is closed
• Private Wiki with token for registering:  registration is closed but users knowing the token can register

Open Wiki

You can configure your Wiki to be open, so that everyone can edit, comment without registering or logging in.

Public Wiki

Nothing to do. This is the default Way. If you want that only people with a verified Email Address can edit pages, you have to set "Use email verification" AND "Check Active fields for user authentication" to "Yes" in Administration/Registration.

Requiring guests to fill out a CAPTCHA in order to comment (Since: Enterprise 2.3M1)

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 need not worry about guests' idle surfing causing the captcha module to use too much of your server's CPU power.

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.
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.
Note: 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.

Result:

Private Wiki with password

Global rights

In Global rights set User:XWikiGuest, Groups:, Level:register, Allow-Deny:Allow.

Registration

In Preferences under Registration set Use email verification:yes. fill the other fields appropriately.

Private Wiki with token

TODO

• Find out more about XWiki access rights here

This page aims at explaining how access rights work in XWiki. It will help you configure access rights on your wiki so that every user can only see and do what he should be allowed to.

An overview of rights

Here is a lists of all the rights available in XWiki Enterprise and their default setting.

• Right name: brief description of the right
  • Availability: at what level can you set this right?
    • Page: this right can be set at the page level
    • Space: this right can be set at the space level
    • Wiki: this right can be set at the wiki level
  • Default status: is the right allowed or denied when the checkbox is left blank?
    • ALLOWED: this means that users CAN perform the given action if no other right is set
    • DENIED: this means that users CANNOT perform the given action if no other right is set
  • Priority order: which setting wins over another if an user has 2 different settings?
  • Checking order: at what level is the right checked first?
• View: whether users can see the page
  • Availability:
    • Page
    • Space
    • Wiki
  • Default status: ALLOWED
  • Priority order: deny > allow > no setting
  • Checking order: page > space > wiki
• Comment: whether users can add a comment to the page
  • Availability:
    • Page
    • Space
    • Wiki
  • Default status: ALLOWED
  • Priority order: deny > allow > no setting
  • Checking order: page > space > wiki
• Edit: whether users can edit and save modifications to the page
  • Availability:
    • Page
    • Space
    • Wiki
  • Default status: ALLOWED
  • Priority order: deny > allow > no setting
  • Checking order: page > space > wiki
• Delete: whether users can delete the page
  • Availability:
    • Page
    • Space
    • Wiki
  • Default status: DENIED (unless you're the document creator)
  • Priority order: deny > allow > no setting
  • Checking order: page > space > wiki
• Admin: whether users can manage administration settings for the space / wiki
  • Availability:
    • Space (Automatically includes the view, comment, edit, delete rights)
    • Wiki (Automatically includes the view, comment, edit, delete, register, program rights)
  • Default status: ALLOWED
  • Priority order: allow > deny > no setting
  • Checking order: wiki > space
• Register: whether users can create new user accounts
  • Availability:
    • Wiki
  • Default status: ALLOWED
  • Priority order: allow > deny > no setting
  • Checking order: wiki
• Program: whether users can use protected APIs & Groovy code in wiki pages
  • Availability:
    • Wiki
  • Default status: DENIED
  • Priority order: allow > deny > no setting
  • Checking order: wiki

Execution order

The full answer lies in the code.