Overview

This document explains how to explicitly disable and enable access to tables in your Xataface application.  The short version is as follows:

To disable access to tables add rules to the [_disallowed_tables] section of your conf.ini file.

To enable access to a table that has been disabled, add rules to the [_allowed_tables] section of your conf.ini file.

Instructions & Examples

Your Xataface application can open up your entire database to the world wide web.  Even if you don't have a table listed in the [_tables] section of your conf.ini file, you can use Xataface's URL conventions to access the table directly.  e.g. index.php?-table=foo  will show the contents of the table named foo if it exists.

In some cases, you may want to lock down certain tables so that they cannot be accessed directly from your Xataface application.  This is possible by using the [_disallowed_tables] section in the conf.ini file.

Example 1 : Disallow access to the invoices table

In the conf.ini file:

[_disallowed_tables]
invoices_rule = invoices

Now if a user attempts to use the invoices table from your application (e.g. index.php?-table=invoices), they will receive a forbidden error.

Anatomy of the [_disallowed_tables] section

The [_disallowed_tables] section can contain 0 or more rules of the form:

rule_name = rule_pattern

where rule_name can be any string to identify the rule, and rule_pattern is either the name of a table to be disallowed or a regular expression matching tables to be disallowed.

Note that rule_name can be anything, and doesn't affect operation of the rule.

e.g.

invoice_rule = invoices

is identical to

my_invoice_rule = invoices

which is identical to

foo = invoices

i.e. The rule_name is just a name for the rule to help you remember what it is for.

Example 2: Disallowing access to the invoices, people, and jobs tables

In the conf.ini file:

[_disallowed_tables]
a=invoices
b=people
c=jobs

Note that these rules are identical to:

[_disallowed_tables]
rule_1=invoices
rule_2=people
rule_3=jobs

Using Regular Expressions for Patterns

Any pattern beginning with a forward slash '/', is treated as a regular expression by Xataface.  Rules of this kind can be used to disallow access to all tables matched the regular expression.

Example 3: Disallowing access to all tables whose names contain the string 'private'

[_disallowed_tables]
rule_1 = "/private/"

This rule would disallow access to tables with names like "private", "private_table", "users__private", "my_private_table", or any other table with the word private in it.

Example 4: Disallowing access to tables with names beginning with an underscore '_'

[_disallowed_tables]
rule_1 = "/^_/"

Example 5: Disallowing access to tables with names ending with '__history'

[_disallowed_tables]
rule_1 = "/__history$/"

Explicitly allowing access to tables using the [_allowed_tables] section

Sometimes you may wish to explicitly allow access to certain tables.  Some examples of reasons for this include:

• You have disallowed access to an entire set of tables using a regular expression, but you want a few of the tables matched by this regular expression to still be accessible.
• Xataface disallows access to certain tables (e.g. history tables) by default, and you want to override this behavior to allow access to these tables.

Example 6: Allowing access to the 'people' table

[_allowed_tables]
rule_1 = "people"

This example doesn't really do too much, unless access to the people table was disabled in the [_disallowed_tables] section.  In that case, this rule would override the disallowed tables rule.

Example 7: Disallow access to tables with "private" in the name, but allowing access to the "private_info" table

[_disallowed_tables]
rule_1 = "/private/"

[_allowed_tables]
rule_2 = "private_info"

Implementation Details

Xataface uses the [_disallowed_tables] and [_allowed_tables] configuration options to filter web requests.  They do not affect API access to these tables.  For example, if you specify that a table named "foo" should be disallowed, then any request with -table=foo in the GET parameters will fail.  However, you can still access the foo table using Xataface API.  If you need to obtain information from the "foo" table in a trigger or a custom action, you can do this.  The user just cannot perform actions directly on this table through the web browser.

Essentially these rules prevent tables from being published to the web, however they are still accessible to the application developer without limitation.

The order in which Xataface handles the rules are described simply in the following flow chart: