DEV Community: James Giosmas

Auth in Rails Part 3

James Giosmas — Sun, 27 Sep 2020 23:07:44 +0000

Hooray we've made it to part 3 in a 3 part series on basic authentication in Ruby on Rails! Checkout Part 1 and Part 2 if you haven't already. For part 3 the goal will be to verify and protect resources with tokens.

In the previous posts we've created a Ruby on Rails API for a clothing store that has users. Now we're going to make it so only logged in users can create items. Let's generate this new resource item.

In your terminal:
rails g controller items
rails g model item

Now we setup the route and the migration, items will have a name and a price.

Now we'll setup a basic ItemsController where anyone can create an item and index all of the items.

In your terminal run rails db:migrate and start your server rails s so we can test this in Postman. A get request to localhost:3000/items should show an empty list of items. So let's make sure we can create an item with a post request.

Now let's make it so only a logged in user with a valid token can create an item. Let's update the create method in the ItemsController. When making HTTP requests the token is stored in the Authorization header so we will want access to that. If the authorization header is absent from the request we can end the conversation right there and present an error. Else, we'll want to split the token from the authorization header at " " since the header includes "Bearer " prior to the token itself. Now we want to DECODE the token (that we encoded in the AuthorizationController) so we can use it.

Let's try to add a shirt with no token present

Now let's try it with my token, the token can be obtained by making a post request to the login route with a valid username and password. Enter your token under the "Authorization" header and make sure to select "Bearer Token"

And lastly let's tamper with this token and make sure it only works with a valid token. I've added some "xxxxx" to the end of my token and will try to add a sweater to our items list.

Alright fam we've made it! The item resource has been successfully protected! Thanks again for reading and as always please let me know if you have any questions, comments, suggestions, etc. because as a developer I'm always learning so there's always more to know!

Auth in Rails Part 2

James Giosmas — Sat, 19 Sep 2020 20:39:28 +0000

Alrighty, been a busy few weeks so if you've been waiting for part 2 in my auth series I thank you for your patience! Today's goals will be to verify the identity of a user and issue signed tokens to logged in users.

Step by step for verifying a user's identity in Rails will be to create a Login route, generate an authentication_controller, create a login action, look up the user, authenticate that user, create a token, then sign it, and lastly send that signed token to the user.

Above I added line 3 of code which created the Login route that basically says any post request to the login path should go to the authentication_controller's login action. Next we'll create the authentication_controller with the following command in our terminal:

rails g controller authentication

Now inside the authentication_controller we can create the login action

This is essentially saying if the username exists and the password is correct you will be successfully logged in and receive a 200 OK status with a success message; otherwise you will receive an error message for what is incorrect and a 401 unauthorized status. Here it is in Postman:

Correct Username and Password (Status 200 OK):

Incorrect Username (Status: 401 Unauthorized):

Incorrect Password (Status: 401 Unauthorized):

Now we've made it to the step where we are going to create a token. There are a few different ways to handle login and today we'll be handling login with token based authentication. How this works is the client gives the username and password to the server and in return for a correct username and password the server sends back a token. Now the token will be sent with all future requests instead of asking for login info. One way to think about this is when entering an event you show your ID (username) and pay a cover charge (password) in exchange for a wristband (token) so you can come and go as you please without having to show ID and pay (login) again. For this token based authentication we need token encoding and this will be handled by a gem called JWT (JSON Web Token, pronounced jot). The token consists of 3 parts: a header, a payload and a signature. The header and payload are encoded which means they can be reversed easily therefore the signature is the header and payload hashed which cannot be easily reversed. Now a signed token is created that cannot be tampered with or used to impersonate another user. Now let's install the JWT gem (which is the specific token encoding we'll be using) in the Gemfile.

Simple as that and now in your terminal run bundle install

Now let's set it up and call it a day! In the authentication_controller we'll be replacing the last else statement (line 10) that had the success message about being logged in. That wasn't actually doing anything so let's change that.

So, now instead of a congratulatory message we receive a signed token. We setup a payload which is some sort of evidence, it is what the server looks up the user by to prove they're who they say they are and have permission to do what they're trying to do. Later, you'll see why it isn't a good idea to include the password as part of the payload. Then, we also setup the secret, which can be any string. I used the method that is supplied by Rails, but again could literally be any string you want. Then encode the token and lastly send it back (render it) with a signature on it.

Alright, now let's see what this gives us in Postman

We got the token! So let's see what it decodes to on JWT.io

Great now we see that is indeed the correct user_id and username so we know this signed token is doing exactly what it should be. Also, you can see if we included the password as part of the payload it could easily be exposed right here. Thanks for reading and as always please let me know if you have any questions, comments, suggestions, etc. because as a developer I'm always learning so there's always more to know!

Creating New Users in Rails (Auth Part 1)

James Giosmas — Wed, 02 Sep 2020 18:40:18 +0000

As a routine, while on the job search, I will be aiming to upload a weekly blog post, in attempts to explain something technical that I've learned or grown from. I will be starting off with a three part series on authentication (auth), not to be confused with authorization.

The goal in the first part of this series will be to create new users in Ruby on Rails and securely store their password. We will have to create a User resource and store a hashed version of the password that User created.

This will be pretty straight-forward, the biggest difference between creating users and other resources will be storing a hashed version of the password rather than the actual password. Hashing is one-way encryption. The term hashing originates from making hashbrowns. When you start with each whole raw potato it's easier to tell which pieces came from which potato, but the more you cut up, stir in, and cook, it becomes impossible to tell which piece came from which potato and even more impossible to turn them back into whole raw potatoes.

So we're going to start off by making a rails api and going from there. For this example we'll make an API for a clothing store that will have Users. To create a clothing-store API we'll simply run the following command in our terminal inside of the directory we would like it to be saved in.

rails new clothing-store --api

Once Rails works its magic, we can open our boiler-plate API. The first thing we will do is open the Gemfile and un-comment line 17 (or whichever line says something along the lines of gem 'bcrypt', '~> 3.1.7'). This is a very simple example but if we were adding any other gems this would be a good time to do so. Now in the terminal run bundle install.

bcrypt is the gem that will be hashing our passwords for us. Once again showing that Rails really does give you so much power right out of the box.

Now we can setup our routes. For this example we only want to be able to create Users so that is the only route I will be creating. More developed applications may include other resources or routes such as, list, show, new, edit, update, and delete.

Now in our terminal we have to generate a users controller by running rails g controller users.

In our users_controller.rb we need a create method. In this example that is the only method we will need. Just like routes more developed projects may include other methods such as, list, show, new, edit, update, and delete. Our users_controller.rb should look like this:

The create method is pretty simple all it is saying is when creating a new instance of a user in the User class the params taken in as the username will be the username and same for the password. Then the instance of that user will be rendered in JSON and have a status of created.

Next is generating the user model. Remember the controller is always plural and the model is singular.

Run rails g model user in the terminal

The only thing we have to do in there is tell it the User class has a secure password by simply:

Now in our migration file we must add t.string :username and t.string :password_digest. password_digest is bcrypt magic and what hashes the password. Essentially, all we are doing here is saying the username and password will be strings.

Last step is to migrate the file by running rails db:migrate in the terminal and we should be able to create a User and store a hashed password. Run rails s in the terminal to start your server and let's try it out in Postman.

Above, we see that I have created a User with username "jonas" and password "jonas1!" and after the creation of this User we can see that it would be extremely hard to decipher the password_digest back to "jonas1!".

And there you have it, creating users and a hashed password! Thanks for reading & as always, I'd appreciate any input, questions or comments.