Documentation for Confluence 4.1.x. Documentation for earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata

This has been markedly improved in Confluence 3.3. See CONF-16866.

Page Permissions and the Confluence Search Index

Modifying the page permissions requires reindexing all child pages, as well as comments and attachments on all those pages.

The reasons for this:

  • Page permissions are stored on every item in the index
  • When you search, a filter is applied to all items in the index which prevents you seeing content you don't have permission to see
  • If the permission information on attachments wasn't updated when a page permission was changed, users who didn't have permission to view the attachment in Confluence would still see that attachment in the search results as well as some of its content
  • To update any record in the index, you need to delete it from the index and re-add it (this is a limitation of Lucene)

Therefore, to update an attachment record in the index, even just to change the permissions, the attachment's content must be reindexed.

Performance Considerations

In the large majority of situations, this design should not be a problem. In large spaces with deep page hierarchies, it might be. Use performance logging for the index flush operation to assess the impact of changing a page restriction - try it on the space's home page, or a page with a lot of children, to see the performance impact of changing a page restriction.

Space Design Considerations

For some space designs, deep page hierarchies may be desirable. If possible, it's recommended to split spaces where it makes sense to do so, according to how your information is organized. One workaround – CONF-7089 – involves opening up access to just a few pages in a mostly-restricted space so as to "open" the space where space permissions close it. This may be a performance concern if the space, and attachments in the space, are large.

Workarounds

There are a few workarounds to consider:

  1. Avoid page restrictions on large page hierarchies. If you have a large hierarchy you have to protect differently to other content in the space, consider moving the hierarchy to a new space. (Space permissions are applied in a manner that doesn't have this problem, but having a large number of spaces also causes scaling issues.)
  2. Disable page permissions completely. You can do this on a space-by-space basis by not granting the "Restrict" permission in the space permissions screen.
  3. Turn off attachment content indexing. See How do I disable indexing of attachments or Configuring Attachment Size for information on how to do attachment types or size limits.

Which Pages Have Restrictions?

A database query to show which pages in your instance have page restrictions:

For page permissions:

For space permissions:

Labels:
  1. Dec 16, 2009

    The query on this page for showing all pages with restrictions is wrong. I didn't take the the time to wrap my head around the exact problems, but it lists users that do not have certain permissions for certain pages. In fact, if you change the query to a SELECT *, the page creator and other information is mismatched. I was looking for a query to show pages that are restricted directly, or by inheritance. I thought this query might have done it, and was throwing me off, showing certain users had edit permissions to a page that I had personally just created and tightly restricted.

    The following query will return all pages with restrictions, and the users or groups with those permissions, but does not show inherited permissions.

    This one correctly displays 344 matches for my instance. Whereas the SQL on this article returned 6000+.

    EDIT: Added Where clause to exclude 'deleted' pages.

  2. Nov 16, 2011

     The above statement

    Modifying the page permissions requires reindexing all child pages, as well as comments and attachments on all those pages

    is contradictory to the following statement in the Confluence Development Documentation

    The Lucene index contains enough information for searches to determine if particular results are visible to the user performing the search. So long as you're not going direct to the Lucene index yourself, and use one of Confluence's search APIs to find content, the content returned should not require any more tests for VIEW permission.

    Source: https://developer.atlassian.com/display/CONFDEV/Confluence+Permissions+Architecture

    Are permissions saved in the lucene index? If yes, in which field? i looked at the lucene index field permissionSets and found no values in it, also there are page restrictions.

    Clarification is welcome!