In the previous article we setup the PostgreSQL database.
You are now ready for the next step: setting up the authentication. Feel free to refer to the part 3 branch of the GitHub repository if needed.
This is the 3rd installment of my Developing A Cross-Platform iOS & Android Social Media App series.
We are now going to be setting up the authenthication for our api. Our goal for part 3 is to implement authentication and prepare for creating our first endpoints.
So how do we achieve this? There is a ruby gem called
devise. It handles everything auth related on a Ruby on Rails app, but it is not designed to be api only. Don't worry, we can still use it on our api with some adjustments. For simplicity, we will only be using devise to handle our
User model and provide some helper methods for us.
Devise is packed with features so if at any point you want to tinker around with it, you already have it installed.
First we will need to install the following libraries:
devise : will be used to handle our User model
bcrypt: used by devise to keep passwords salted, hashed
Add these lines to your
Gemfile and run
gem 'devise' gem 'bcrypt', '~> 3.1.7'
Once all the gems are installed, we need to install
devise. Keep in mind that devise will create a bunch of views for the frontend, we won't be using them. Run:
$ rails generate devise:install
Once devise is installed, we can generate the User model. Run this command so that devise can create the model and migrations for us:
$ rails generate devise User
The next step would be to migrate our database. Let's look at the migration it created under
... class DeviseCreateUsers < ActiveRecord::Migration[6.0] def change create_table :users do |t| #... t.string :email, null: false, default: "" t.string :encrypted_password, null: false, default: "" #... t.string :reset_password_token t.datetime :reset_password_sent_at #... t.datetime :remember_created_at #... t.timestamps null: false end add_index :users, :email, unique: true add_index :users, :reset_password_token, unique: true #... end end
Let's walk through some of the lines:
class DeviseCreateUsers: This is the name of the migration and it is self documenting in that we can tell this migration creates users for us
create_table :users do |t|: This tells us that the migration will create the table
users in our PostgreSQL database
t.string :email, null: false, default: "": This adds a column of the
string type called
null: false and will default to
"" due to
t.string :encrypted_password, null: false, default: "": Similar to above, this created an
encrypted_password column. This does not save the password in plain text. Devise will only put encrypted passwords in this column.
We will handle password resets on our own, so these two are not necessary, we can comment these out:
t.string :reset_password_token t.datetime :reset_password_sent_at
This migration also adds indexes for
reset_password_token as seen below:
add_index :users, :email, unique: true add_index :users, :reset_password_token, unique: true
You can remove the
reset_password_token index but we will need the
We still have one more thing left before we can run the migration: implementing uuids to replace our ids. Instead of having our ids be
..., our ids would look like:
Why is this important? UUIDs are globably unique and make it far easier to merge datasets. Overall, it is ideal for scalable applications, such as the one we are building. Your project may not be the next big social media app, but converting to UUID in the future would be far more of a pain than setting it up now.
Keep in mind that there are some cons such as it being harder to debug an incremeting id vs a UUID. There is also the performance cost. UUIDs would be 4 times the storage size of an incremeting id. PostgreSQL has native support for UUIDs but it still has a performance impact. At such a small scale, you won't notice the slow performance, but imagine when it is scaled up to a popular production app. For this series, we will stick with UUID, but don't default to UUID without looking at the pros and cons for your next app.
Luckily, UUID is very simple to enable in our migrations. To do this we would need to take a look at these lines:
def change create_table :users do |t|
We would need to use the
pgcrypto extension so we enable it using
enable_extension 'pgcrypto' and changing the id column to uuids by adding
id: :uuid. As a result the lines above should be updated to:
def change enable_extension 'pgcrypto' create_table :users, id: :uuid do |t|
Once this is complete, we can run
$ rake db:migrate to run our migrations.
If you accidentally ran the migrations, you can rollback the migrations using
$ rake db:rollback. Keep in mind that you should almost never do this unless the migration hasn't been commited yet. This is because changing an existing migration that others have already applied to the database would cause issues. You especially do not want to do this when a migration is applied to production. We will cover the proper approach in the future.
Rolling back and applying migrations may not always work. There are commands you can run as a last resort, but only as a last resort. These should not be the go-to solution since this can cause issues if you aren't careful. Migrations may fail or not be applied when deploying to production or when other developers pickup your code.
One option is running
$ rake db:reset to reset the entire database. Of course, don't do this on production as it will reset your database completely. Only use this as a last resort. (After a reset, you should import your most recent database backup if you have one)
In other cases you may need to manually delete the automatically generated
schema.rb file by running
$ rm db/schema.rb. Sometimes, Rails thinks the migration is applied already and doesn't update the schema.rb file.
Of course, these issues could be usually avoided all together by never editing a migration after you migrate and commit.
In the next part, we will check out the model that devise created!