Goldberg features role-based access control for its controller security. Users are assigned a role, which sets permissions for that user, which determines what actions they can perform and what pages they can view.
Goldberg roles can inherit singly from another role, allowing you to set up trees of roles. Each of the roles can contain zero or more permissions. When calculating the permissions for a given role Goldberg includes the permissions directly attached to that role and all the permissions attached to its parent roles, travelling recursively back up the role tree.
This arrangement allows you to assign permissions in a concise and easy to understand manner. For example you might set up a role “Guest”, with a very basic set of permissions. Then you might set up a role “Member” which inherits from the “Guest” role and adds more permissions. Subsequently if you decide to change the basic permissions that control the way the site operates, you only have to change the “Guest” role and the new permissions will cascade through to the other roles based on “Guest”.
Controllers, Actions, Pages and the Menu
Controllers and actions are the fundamental pattern for request processing in Rails. To use your controllers in Goldberg you must set them up and assign them a default permission. This permission applies by default when any of that controller’s actions are invoked.
Subsequently you can set up that controller’s actions in Goldberg, and either assign specific permissions for the actions or leave them as the controller’s default.
Goldberg also offers content pages. When an incoming request can’t be mapped to a controller/action, Goldberg tries to resolve the request to a content page. Each content page is assigned a permission when it is set up.
These settings control how a user’s menu is built. Goldberg builds a menu for a user containing only the actions and content pages to which that user has access. Note that this is not security by obscurity: even if a user were aware that other menu items existed for other users, if she tried invoking a URL for which she lacked permissions, Goldberg would block the request.
For more details on setting up applications and editing the Goldberg menu see Usage.
Goldberg’s security is designed in purely abstract terms. Unlike most other web application systems there are no hard-coded users, roles or permissions. This is not just good design—it is fundamental to the way Goldberg works, facilitating the separation between Goldberg and your application. It’s why your application doesn’t need to be concerned as to whether a user is logged in as an administrator or not: Goldberg handles that, and allows you to specify permissions as broadly or specifically as necessary without a single line of code in your application.
The only role that enjoys any kind of special treatment is the “Public” role (i.e. the role that is assigned by default to users who are not logged in). But even this role is not hard-coded: it is specified in Goldberg’s system settings.
This makes Goldberg the natural choice for business applications. You can design a role hierarchy that is as rich as is necessary, without being constrained by the trivial public/member/administrator distinction that is the anathema of most web frameworks.