Chapter 8. Fine-grained access control
This chapter covers
- Implementing authorization using the Pundit gem
- Writing a custom RSpec matcher
- Enforcing authorization for future-proofing your code
- Building a completely custom form for managing a user’s roles
At the end of chapter 7, you learned a basic form of authorization based on a Boolean field called admin on the users table. If this field is set to true, the user is an admin user, and can therefore access the create/destroy functions of the Project resource, as well as an admin namespace where they can perform CRUD on the User resource.
In this chapter, you’ll expand on authorization options by implementing a broader authorization system using a Role model. The records for this model’s table define the roles that specified users will have on specific projects in your system. Each record tracks a user who has a specific role, the project to which the role applies, and the type of role granted. You’ll create three types of roles in your system:
- Viewer— For people who will be able to read everything on the project but not edit anything.
- Editor— For people who will be able to read everything and also create and update tickets on the project.
- Manager— For people who will be able to read everything, manage tickets, and also administrate some facets of the project itself, including editing the project’s details. They won’t be able to delete the project, though—that’s reserved for admins of the site.