Access Restrictions Configuration

From CollectiveAccess Documentation
Jump to: navigation, search

The access_restrictions.conf configuration file

CollectiveAccess uses a Model-View-Controller structure that allows one to restrict access to each navigation module, controller or even controller action. Those restrictions are defined in access_restrictions.conf.

Syntax

The beginning of the file features a key that allows you to disable all module/controller/action-based access control. Set the following to zero if you don't want to enforce any access restrictions.

enforce_access_restrictions = 1

The second directive in this file is a big array named "access_restrictions". It consists of an arbitrary number of module/controller/action-based access restrictions. The key of each array element is either a path to a controller group ("module") in app/controllers, for example

administrate/setup

or a path to a controller in a controller group, e.g.

administrate/setup/RelationshipTypesController

or it can even feature an action (method) of a particular controller, as follows:

administrate/setup/RelationshipTypesController/Save

Note that a user must pass all applicable restriction checks before access to an action is granted (for the module he's trying to access, for the controller and for the action). Each array element (indexed by module/controller/action) can consist of an arbitrary number of access rules. These rules are arrays that describe the group of users that are allowed to access the subject. Again, a user must pass all applicable rules in order to get access. Each rule may consist of the following keys:

Entry Description Default
actions A list of user actions as defined in the user_actions.conf configuration file An empty list
operator Boolean operator that is used to connect the actions. AND means a user has to have a role with all listed actions; OR means having one of the listed actions is sufficient for access. Can be left empty (defaults to AND). AND
parameters An optional array that describes parameter values that must be valid before this rule is applied (otherwise it is simply ignored). This is useful if you want to distinguish between editing existing records and the creation of new ones. In this case you would have two rules: One that applies if the primary key value passed does not equal zero (i.e. the user is editing an existing value) and another one that applies only if the value is zero (i.e. a new record is created). For the exact format of the array please have a look at the example below. Note that we have to know the type of the parameter in advance to perform all checks correctly. You can also set the name of the parameter to type and set the value to a type code/idno (i.e. ca_list_items.idno). The rule then only applied if the subject has the given type. Please have a look at the last example below if you plan to use this feature. An empty array

Example rules

The following example uses most of the features described above.

	editor/objects/ObjectEditorController/Save = {
		create = {
			parameters = {
				object_id = {
					value = 0,
					type = int
				}
			},
			actions = { can_create_ca_objects }
		},
		edit = {
			parameters = {
				object_id = {
					value = !0,
					type = int
				}
			},
			actions = { can_edit_ca_objects }
		}
	},

Obviously it restricts access to the "Save" action of the "ObjectEditorController" in the "editor/objects" module. It features two access rules: The first one only applies if the parameter "object_id" equals zero. In this case only users that have a role with the user action "can_create_ca_objects" are allowed to perform this action. The second rule is enforced if the parameter doesn't equal zero. In that case a user is trying to save changes to an existing object and therefore has to be able to perform the action "can_edit_ca_objects". Also note that we omitted the "operator" directive in both rules. Since the action lists consist of only 1 item it doesn't matter if they're connected via AND or OR. Below is another example that makes use of the "operator" key.

	editor/occurrences/OccurrenceEditorController/Edit = {
		edit_delete = {
			parameters = {
				item_id = {
					value = !0,
					type = int
				}
			},
			operator = OR,
			actions = { can_edit_ca_occurrences, can_delete_ca_occurrences }
		},
		create = {
			parameters = {
				item_id = {
					value = 0,
					type = int
				}
			},
			actions = { can_create_ca_occurrences }
		},
	},

The following example makes use of the type parameter. The usage of this is especially useful in combination with the automatic action expansion feature in User_Actions_Configuration,

	editor/objects/ObjectEditorController/Save = {
		photography_create = {
			parameters = {
				object_id = {
					value = 0,
					type = int
				},
				type = photography
			},
			actions = { can_create_ca_objects_type:ca_objects.photography }
		},
		document_create = {
			parameters = {
				object_id = {
					value = 0,
					type = int
				},
				type = document
			},
			actions = { can_create_ca_objects_type:ca_objects.document }
		},
		photography_edit = {
			parameters = {
				object_id = {
					value = !0,
					type = int
				},
				type = photography
			},
			actions = { can_edit_ca_objects_type:ca_objects.photography }
		},
		document_edit = {
			parameters = {
				object_id = {
					value = !0,
 					type = int
				},
 				type = document
			},
			actions = { can_edit_ca_objects_type:ca_objects.document }
		},
	},

sphinx

Namespaces

Variants
Actions
Navigation
Tools
User
Personal tools