Protecting Pages and Files from Public Access

Private pages can only be viewed by visitors who have logged in and have the required access rights. Page protection is set on a page-by-page basis, and the access is controlled by the “role” of the currently logged in user.

Access Control

Private page access control is assigned to pages individually. It doesn’t matter if a page is in a hierarchy structure of any kind. You must assign each page its access control criteria.

You can quickly scan for pages with access control enabled by looking at the page list and finding the key icon in the status column.

When activated, private page support adds an access control at the bottom of the page edit form. You will see a select list with all of the available roles within the system.

The default access for a page is “public”. If you assign any other role to a page, it is no-longer available to the public and will not be indexed by search engines.

For accounts without membership features, site admins see two choices for access: “Public” or “Protected”. For sites with membership features enabled, additional roles may appear in the access control list.

Typically, the only additional role is Member. For Premium plan sites, which have the member groups features available, you can define any number of groups, and each will be listed separately in the access control list.

When a page is set to anything other than Public, if a user attempts to visit that page and is not logged in, she will be presented with the login form. If she successfully logs in and her account has a matching role assigned to it, then she will be shown the page. (If she was previously logged in during this session, she won’t see the login screen again in most cases within the same browser session.)

If a user logs in and does not have matching role credentials, she will be show the access_denied page. She can then choose to log out and log in to another account or continue visiting other parts of the site.

Pages can have more than one role assigned for access.

Admins always have access to a page, regardless of role settings. It doesn’t hurt if you assign “admin” to a page. You might want to do this if you want some secure pages that admins can see, but regular members can not.

Caching Considerations

Protected pages are not stored in the same cache as regular pages. This prevents anyone from creating a sneaky URL and bypassing the security system.

You can’t protect parts of a page, only whole pages.

Changing access settings clears that page’s cached content, but not any children pages (they are separate entities as described above).

When you change a page’s access control, it is flushed from all caches, but it is always a good idea to check that your desired access is in working order.

If in doubt, manually clearing the page cache (Settings > Clear All Caches) clears both public and private cache areas.

If you are really concerned about a page being cached, and performance isn’t critical, you can use one of the non-caching page types (such as the “Ajax Page” type in the type list of the page edit form).

Protecting Files

On a private page, you can put a link to a file, such as a PDF, and since the page is private, only people who have access to the page will be able to click that link.

However, should the link to that document be shared, perhaps by email or by posting to some other site, or if the site admin accidentally put the link on a public page, the document could be downloaded by anyone. If Google every accessed a page with the link, it could be in the Google index indefinitely, even if the link was later removed. So a brief mistake could result in a document being accessible via public search for an indefinite period.

To increase the protection for private documents, you can block access to selected files unless the person (the browser, really) accessing the file is logged in.

To set this up, you need to do two things:

1. Add a config setting with the name security.acl.folder.default and set the value to the role that is required to access this file (typically "member"). If there are multiple roles, use a comma-separated list.
2. Put the file in a folder whose name starts with secure_.

Note that there is no restriction on the filenames, and the folder name can end with anything you want, but it must start with "secure_". So a good folder name would be something like "secure_documents". Be sure not to put any file in such a folder that should be accessible by any site visitor.

If you create multiple member groups, so you have member is a group with a name other than "Member", and you want them to be able to access secure files, be sure to add the names of those roles to the setting security.acl.folder.default.