This is an old revision of the document!


Access Control

Apart from basic user account access control, you can also setup access control to specific endpoints (for example, particular web pages).

You can do this through the security files. There's one shared file at /model/defaults in your ARDI installation directory, and you can also create site-specific security files by creating a file called security.json in your site folder.

Access Control Options

Below is an example of the default security settings.

{
	"paths": {
		"api/drivers": "local",
		"api/driverdata": "local",
		"api/driverdetails": "local",
		"prometheus/live": "prometheus",
		"admin/": "admin",
		"admin/sites/purge": "restricted",
		"admin/sites/reset": "restricted",
		"admin/restore/": "restricted"
	},
	"groups": {
		"local": {
			"type": "whitelist",
			"list": ["127.0.0.1","localhost"]
		},
		"prometheus": {
			"type": "whitelist",
			"list": ["127.0.0.1","localhost"]
		},
		"admin": {
			"type": "useraccess",
			"level": "admin"
		},
		"blocked": {
			"type": "block"
		},
		"restricted": {
			"type": "isuser",
			"list": ["admin"]
		}
	}
}

Paths

The paths section contains a list of web URLs that you'd like to protect.

A url that ends with a slash (/) character protects the entire folder, while one that ends without a slash only protects that specific URL.

For example, admin/sites/purge specifically protects the page that allows you to erase your ARDI database, while admin/ protects every page in your 'admin' folder.

Each path has a matching group which defines the access control rules.

Groups

Access control rules are bundled into groups, making it easier to modify security settings (for example, it's much easier to update one group than it is to update a dozen individual paths).

Each group has a either a single security rule, or a list of them. Each security rule has a type, such as those below…

whitelist - Allows access to specific IP addresses
userlevel - Allows access to a specific user level
isuser - Allows access to a specific user
token - Requires a specific HTTP header/token

Most rules (such as whitelist, userlevel and isuser) can be set to deny rather than allow, making the 'whitelist' function work as a 'blacklist'.