Page access control

Interchange can control user access to pages in directories in or under the PageDir in a number of ways.

If a directory has no ".access" file, then files in that directory will not be subject to the access control described on this page.

If a directory contains a ".access" file, with a size greater than zero, then no access will be granted unless one of the following is true:

• The user's hostname or IP matches one of the values set using the MasterHost local configuration directive.
• The user is logged in, using HTTP basic authentication, and the username matches the value set using the RemoteUser local configuration directive.

If a directory contains a zero-sized ".access" then access control will be switched on, and any of the following access control mechanisms may be used:

.access_gate file

If a file called ".access_gate" is present then it will be scanned for page-based access control rules.

The following is an example ".access_gate" file:

Each record starts with the name of the page to be controlled, followed with a colon (:).  Page names may be suffixed with ".html", but that is optional.

After the colon, you should either use a literal "Yes" or "No" to determine access, or you may include some ICML tags to perform some processing prior to returning "Yes" or "No".  "True" and "1 are aliases for "Yes", and "False" and "0 are aliases for "No".  A blank rule will be treated as "No", and access will be denied.

If a page name is "*" then the rule applies to any page that is not named elsewhere in the ".access_gate" file.  If page access is to be allowed by default then set the "*" page's rule to "Yes".  Similarly, if page access is to be denied by default then either set "*" page's rule to "No" or just leave the rule blank.

If the ".access_gate" file contained content as shown in the above example, then the following page access control rules will be enforced:

• Access to the "foo" page will only be granted if the user is logged in as "kevin".
• Access to the "bar" page will only be granted if the user is logged in as "kevin", or if the "allow_bar" scratchpad variable is set to a non-blank, non-zero value.
• Access to the "baz" will always be granted.
• Access to all other pages in the controlled directory will only be allowed if the user is logged in via [userdb].

MV_USERDB_REMOTE_USER variable

If the "MV_USERDB_REMOTE_USER" Variable is set to a non-zero, non-blank value, then any user logged in via [userdb] will receive access to all pages in the directory.

Note This facility will be overridden if an ".access_gate" file is found in the controlled directory.

MV_USERDB_ACL_TABLE variable

If the "MV_USERDB_ACL_TABLE" Variable is set to a valid table name in the website's database then the userdb tag can be used to control access with simple ACL logic.

The MV_USERDB_ACL_COLUMN Variable is used to specify the column, in the "MV_USERDB_ACL_TABLE" table, that should be used for ACL-based user authentication.

The following local configuration will set up access control using the "acl" column, in the "userdb" table, as the ACL store.

Of course, you don't need to use the userdb table;  Any table with a primary key column called "username" and the specified "MV_USERDB_ACL_COLUMN" will do.  The "MV_USERDB_ACL_COLUMN" must be defined, using either a BLOB (binary large object) or a TEXT datatype.

With the above configuration, access to the "somedir/somepage" page can be granted for the currently logged-in user with the following command:

Similarly, access to the "somedir/somepage" page can be revoked with the following command:

See the set_acl and check_acl sections of the Interchange user database documentation.

Note This facility will be overridden if an ".access_gate" file is found in the controlled directory, or if the MV_USERDB_REMOTE_USER variable is set true.