Engineering Principles

Why Bettermenters build software the way we do

Back to Our Principles

How We Authorize Access to Our Apps

Given a need for tiered authorization rules where each tier has a strict superset of the previous tier’s privileges, we use a minimal authorization framework that assigns controller actions to minimum authorization tiers and nothing else because REST endpoints provide a natural model of capabilities, and security is too important and too difficult to manage ad hoc or at any level deeper than the service boundary.

Given an application domain has multiple different classes of user with non-overlapping responsibilities and capabilities, we build a discrete application within the same app domain per orthogonal role (e.g., career path) of end user, sharing a git repository, a core library, and database with the rest of the application domain because the most reliable way to deny authorization to an endpoint is to not have the code for that endpoint be defined at all in the running code.

We use nothing but trust root (e.g., current_user) chaining for authorization within a controller action, and do no authorization deeper in the model layer because the relationships traversed represent the best documentation of the authorized intent. If a traversed relationship is intended for read-only access, we enforce this by returning read-only models.

Next: How Our Apps Communicate

Back to Our Principles