Chapter 8. More authorization
This chapter covers
- Expanding with a more advanced system
- Setting permissions to control user actions
- Implementing a seed of data for the app
At the end of chapter 7, you learned a basic form of authorization based on a boolean field on the users table called admin. If this field is set to true, identifying admin users, those users can access the CRUD functions of the Project resource as well as an admin namespace where they can perform CRUD on the User resource.
In this chapter, we expand on authorization options by implementing a broader authorization system using a Permission model. The records for this model’s table define the actions specified users can take on objects from your system, such as projects. Each record tracks the user who has a specific permission, the object to which the permission applies, and the type of permission granted.
The authorization implemented in this chapter is whitelist authorization. Under whitelist authorization, all users are denied access to everything by default, and you must specify what the user can do. The opposite is blacklist authorization, under which all users are allowed access to everything by default and you must block what they may not access. You use whitelist authorization for your application because you may have a large number of projects and want to assign a user to only one of them. Whitelist authorization involves fewer steps in restricting a user to one project.