View Source Bonfire.Data.AccessControl

See also for more docs (TODO: merge/deduplicate)

Bonfire has a slightly unusual way of dealing with access control. It's not so different from role-based access control (RBAC), but we do a few things differently and there are quite a lot of pieces to get your head around. We'll start gently.

Bonfire has a Verb table containing strings like "comment" and "delete" that represent actions a user might wish to perform. They are a basic part of the bonfire vocabulary within the codebase.

A permission is a decision about whether the action may be performed it not. There are 3 decisions we support:

  • true (permitted)
  • false (explicitly not permitted, never permit)
  • null/nil (not explicitly permitted)

It may seem odd to have the null here. We will come back to this after we've introduced a few more pieces of the puzzle.

A boundary is simply an unordered list or group of permissions. Each permission may only occur once. Any permissions that are not specified are assumed to be null. This loosely corresponds to a role in RBAC.

A Grant links a subject (user or circle) to a boundary. It determines what permissions are considered for a given subject.

A Acl is simply an unordered list or group of Grants. Subjects may appear more than once in a list (with different boundaries) and the permissions will be merged according to the following truth table:


Or in words: take the highest value where false > true > null.

At the end of this combination process, the user is only permitted if the result is true. You can see this as requiring an affirmative answer to permit something, while always allowing you a bigger no to deny when things are combined. Null values are additionally not required to be present in the database, saving us resources. That is to say we default to null if there is no relevant record.

Finally, an object is linked to one or more Acls by the Controlled multimixin, which pairs an object ID with an ACL ID. Because it is a multimixin, a given object can have multiple ACLs applied. In the case of overlap, permissions are combined in the manner described earlier.

Copyright (c) 2020 James Laver, bonfire_data_access_control Contributors

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at