With Scrivito, you can restrict the visibility of pages to logged in users by changing the corresponding setting in the page properties accordingly.

If a page is restricted to logged-in users, visitors need to log in to the website first to be able to see it. Usually, editors can see such protected pages because they need to log in for becoming an editor.

However, by means of custom visibility categories, the visibility of content can be restricted to specific editors as well. This way, access to, for example, confidential internal content can be granted only to the staff members involved.

To enable visitors to log in, connect your Scrivito CMS to a visitor identity provider in your Scrivito dashboard, and provide your Scrivito-based web application with a means to authenticate, via Google, for example.

To be able to restrict the visibility of content to editors, set up an editor identity provider and connect it to your CMS. See below for further details.

The visibility options editors can choose from in the page properties can be configured. Like all administration tasks, this one, too, can only be performed by the members of a team that has been granted the corresponding permission, “Manage built-in visibility categories”. Learn how to manage users and teams.

If you have this permission, the main menu at the top right includes the “Manage visibility categories” item for opening the dialog that lets you do this. You can then enable and disable the built-in categories individually, depending on whether you want them to be selectable or not. Scrivito ensures that at least one visibility category is left available to editors.

That said, if you disable a category that is assigned to a page, the visibility of this page remains the same, it’s just that editors cannot apply or reapply this visibility setting to any page.

For restricting access to a page to closed visitor or editor groups, e.g. partner companies, customers, staff members, etc., Scrivito lets you define custom visibility categories, again provided that you have the corresponding permission through your team memberships.

Setting up custom visibility categories requires your editor and visitor identity provider to have user management capabilities, including the creation of groups (sometimes also called roles). The groups you set up with your IdP are the ones that can be specified in a custom visibility category. After adding users to a group in your IdP setup, specifying this group in a visibility category ensures that only those users can access pages to which this visibility category has been assigned. There’s a guide available on how to set up groups with Auth0.

When defining custom visibility categories, Scrivito is not aware of the groups you defined in your IdP setup, meaning that no selection mechanism like a dropdown or autocompletion is available when entering group names.

When changing the visibility of a page, Scrivito offers only those categories for selection that can be applied without causing the page concerned to be hidden from the editor. Editors with the “View all content” permission, however, are always offered all categories for selection, i.e. the enabled built-in ones plus all custom categories, because this permission overrules all access restrictions. So editors with this permission can apply any visibility category to a page without being a member of any of the groups the category references. This is ideal for chief editors or supervisors, etc., needing unconditional access to all content.

Note that editors not permitted to access specific content due to its visibility category (and the group membership specified in it) are also prevented from using references and links pointing to this content, e.g. in the Content Browser. In this case, a corresponding label is displayed on the editing control.

In an intranet, all website content is meant to be inaccessible to the public. So, first disable the “Publicly available” visibility category to prevent editors from accidentally assigning it to pages. Then, remove this visibility setting from all existing content to which it is assigned. If doing this manually would cause too much effort, you can create a working copy, run the following small script in the browser console, and then publish the working copy:

In connection with visibility, next to the restrict method used in the above code, instances of Obj also support unrestrict and isRestricted.