Authorizing Users to access CRUD functionality with Ruby on Rails
As developers, the safety of our application databases is one of our top priorities. Globalization and greater access to the internet worldwide have created hurdles for developers as they have to continually make sure that hackers aren’t able to manipulate data that gets injected into an application's database. Protecting data has become a constant cycle of hackers finding new and sophisticated ways to allow them access to privileged data and the developers learning from data breaches as well as thinking of new and clever ways to impede these malicious users. Ruby being an older programming language has been through this cycle countless times and through the data breaches, Ruby developers have created ways to slow down or stop breaches by creating gems like Bcrypt (https://github.com/bcrypt-ruby/bcrypt-ruby) to hash and salt passwords saved as cookies. This is fantastic for developers because it creates barriers that determined hackers have to jump over before they can get privileged data like a user’s password. However, our job as developers to protect data doesn’t stop there. We must be able to go beyond authenticating our users and the data they try to inject into our database, our code must be written so it allows the users without malicious intent to still have their data persist in our database but allow them the unique ability to access and manipulate their specific entries. In this short guide, I would like to walk you through how you can only allow authorized users the ability to manipulate data they injected into your application database.
Authentication is a principle in keeping user data safe from hackers, and with authentication, it is easier to allow authorized users to manipulate and inject data into your database. Decerning authorization comes down to how your application is going to be built around the user experience. For example, if you wanted only the user who created a post on a blog the ability to edit their own post you simply begin with user authentication and then user authorization. Bellow is the PATCH method inside the Posts controller of a simple blog application where each post belongs to a user.
If the desired user experience is to only allow authorized users the ability to edit a post you must authenticate who is trying to access that post. In the update action of this PATCH route, we begin by asking Rails to find a post inside the Post class by its ID. Once Rails has pulled the appropriate entry we then ask rails who is currently logged in requesting this PATCH route. In this example, we are asking Rails to search the User class for the ID of the current session’s user_id logged into the application. Rails is able to find the user_id foreign key inside the current session that is asking to access this PATCH route because each session's user_id value is the same value as the user who created the session when they logged into their account on the application. Rails is then able to find which user is trying to access this routes controller action and compare it to the user ID of the post to whom it belongs to because when a post is created it also creates a user_id foreign key for that post. If the post.user_id matches the currently logged in user then the post will allow the appropriate parameters to be passed in. If the parameters passed into the updates query entry are validated by Rails then the post is updated to the database and rendered as a son object for the react application to accept and render. Below is another example of Rails strong parameters and it was the short-hand way I allowed parameters to be injected into my update action. Strong parameters is another way that Rails allows only authorized data to be entered into your database by allowing mass assignment of data entries but only permitting the ones you allow. Just another way Rails is protecting our data every day.
