DEV Community: Emmanuel Hayford

Secure Your Ruby App with JSON Web Tokens

Emmanuel Hayford — Wed, 30 Aug 2023 11:15:47 +0000

If a web application involves users, as a matter of course, their data should be protected and secured.

Securing a web application can mean several things. In this post, we'll discuss a subset of web security that involves authentication using JSON Web Tokens (JWTs) and the Ruby on Rails web application framework.

Let's get started!

What is a JSON Web Token?

A JSON Web Token is an internet standard defined by the Internet Engineering Task Force (IETF) as a: "compact, URL-safe means of representing claims to be transferred between two parties".

Here, "claims" refers to assorted pieces of information about a subject. A claim is represented as a name/value pair where the name is always a string, and the value can be any JSON value.

The Basic Structure of JSON Web Tokens

Delving into the intricacies of JWTs is out of the scope of this post. That said, it's worth knowing the structure of JWTs.

A JWT consists of three parts, separated by a period: the header, payload, and signature.

An example JWT could look like the following:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

For the sake of readability, each part of the token starts on a new line. In practice, the parts are joined.

This token is sent from a server to a client. The client sends the token to the server to identify itself and have a request processed.

The first part, the header, contains information about the algorithm used to generate the token and the type of token. If decoded, we get something like:

{
  "alg": "HS256",
  "typ": "JWT"
}

The second part, the payload, contains a set of claims about the user. In most cases, this would be the client in a client-server setup, and it could look like:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

The signature (the last part of a signed JWT) validates the token. It is generated by encoding the header and the payload using Base64url Encoding — RFC 4648 and then concatenating them with a period separator.

Essentially, what happens with the signature bit is this:

HMAC_SHA256(
  secret,
  base64urlEncoding(header) + '.' +
  base64urlEncoding(payload)
)

HMAC_SHA256 is a type of keyed hash algorithm constructed from the SHA-256 hash function that hashes the signature. The choice of the cryptographic algorithm comes from the "alg": "HS256" in the header. If the token is unsigned, it'll only have the header and payload without the signature.

JWTs Vs. Other Authentication Methods for Your Ruby App

JSON Web Tokens, as the name implies, are token-based. On the other end of the spectrum, we have session-based authentication: a more traditional way of authenticating users. The flow of session-based authentication is quite different from that of token-based authentication.

The flow of session-based authentication might look like the following:

A user or client sends a request which contains user credentials.
The server authenticates the user, stores a session, and returns a session ID stored as a cookie in the browser.
The client sends the cookies along with its subsequent requests to the server.
The server inspects the session information presented and, if valid, authenticates the user and returns the requested information to the client.

While session-based authentication is mostly used for client-server connections, token-based authentication is often used with server-server connections (e.g., between two APIs).

One important difference to note, however, is that with session-based authentication, the authentication state is handled on the server — while tokens are managed on the client.

Why Use JWTs for Authentication?

Aside from being relatively simple to implement, there are a few other advantages of using JSON Web Tokens for authentication, such as:

They are stateless, meaning that a session store is not necessary. The token itself contains all of the user information, so there is no need to query a database or authentication server for information on each request.
JWTs are generally more performant than most traditional methods of authentication (as long as the server doesn't do any lookups against a database or store to authenticate a user), making them quite efficient.
They also offer solid security guarantees, in that signed JWTs provide safeguards so an attacker or client can't modify the tokens to gain access to protected data.

JWT Best Practices for Ruby Apps

It goes without saying that the secret keys used to sign JWTs should be long, random, and have complex character combinations. This ensures that the keys are adequately safe and it's hard for attackers to brute-force them.

The secret keys Rails generates are safe for the most part, but safety guarantees are nullified if you accidentally commit keys and reveal them.

It's also important to use Transport Layer Security (TLS) when transporting tokens between parties on a network. TLS can mitigate a man-in-the-middle attack (both token and session-based authentication methods are prone to such attacks).

Implementing JWT authentication in a Rails App

Let's take a look at a token-based authentication flow:

Unlike session-based authentication, a stateful authentication technique where we use sessions to keep track of an authenticated user, token-based authentication with JWTs is stateless; there's no need to store any information about a user's authentication state on the server. This simplifies application design.

In this post, we'll assume that our application is split into a frontend and a backend. Authentication occurs on the backend, so we will be building a Rails API backend with authentication.

The sample code in this post is based on Rails 7.0.5 and Ruby 3.2.2.

Using the `jwt` and `bcrypt` Ruby Gems

We'll need two gems for our application: jwt and bcrypt.

jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. bcrypt is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm.

You can follow along with the sample code in this code repo.

Note: jwt is not the only solution for working with JWTs; another well-known gem is devise-jwt, which provides JWT authentication for Devise and Rails. But we'll focus on jwt in this post.

Let's get started.

Building our Rails API

The first thing we need is an API application. We'll create one with:

rails new jwt_rails_api --api

The --api option here preconfigures a smaller stack of Rails for API applications only.

Inside the Gemfile, we can add our first dependency, jwt. Our second gem, bcrypt, is already in the Gemfile of a newly-generated Rails application — we only need to uncomment it.

We need bcrypt to securely hash user passwords in the database. It's important to note that we won't use bcrypt directly. We'll leverage Active Model's has_secure_password class method, which depends on bcrypt.

Ignoring the default gems that come with a new Rails application, our Gemfile should look something like:

gem 'jwt', '~> 2.7'
gem "bcrypt", "~> 3.1.7"

Now is a good time to install our gems with bundle install.

Generate `User` and `Product` Models

Next, we'll generate two models: User and Product. User will be the model to represent users and we'll authenticate it to allow access to products, represented by the Product model.

rails g model User username:string password_digest:string
rails g model Product name:string description:text

After running our migration with rails db:migrate, our setup with models is complete, and our schema, found in db/schema.rb, should now look similar to this:

ActiveRecord::Schema[7.0].define(version: 2023_05_28_224534) do
  create_table "products", force: :cascade do |t|
    t.string "name"
    t.text "description"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end

  create_table "users", force: :cascade do |t|
    t.string "username"
    t.string "password_digest"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end
end

It's important to point out at this stage that we're deliberately ignoring potential issues such as database constraints, validations, ensuring uniqueness, etc. For the sake of this post, we'll disregard handling errors, among others. Our purpose here is to demonstrate JWTs in action as a form of stateless authentication to secure our Ruby application. In a production application, you'd want to make sure all of these are covered.

Build a `jwt` Gem Wrapper

The next step is to build a wrapper around the jwt gem we installed earlier. We'll use this wrapper to encode and decode claims from the server to the client. For this, we'll create an app/lib folder.

The reason we're not using the lib folder that comes with Rails is that it's not autoloaded. Everything under app is autoloaded and eager-loaded by default, making for a simpler setup in our case.

Our wrapper class is found in app/lib/json_web_token.rb and looks like this:

class JsonWebToken
  JWT_SECRET = Rails.application.secrets.secret_key_base

  def self.encode(payload, exp = 12.hours.from_now)
    payload[:exp] = exp.to_i

    JWT.encode(payload, JWT_SECRET)
  end

  def self.decode(token)
    body = JWT.decode(token, JWT_SECRET)[0]

    HashWithIndifferentAccess.new(body)
  end
end

The main methods here are encode — to encode user information — and decode — to later decode user information in the server. Note how we're delegating the encoding and decoding tasks to the jwt gem through JWT.encode and JWT.decode.

At this point, you can already test this class in your Rails console:

data = {"name"=>"AppSignal"}

JsonWebToken.encode(data)
# => "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiQXBwU2lnbmFsIiwiZXhwIjoxNjg1NDI0MjI5fQ.zWJyFHH8Pa6phBOU99XgtRntyfZQSOTX4TdwOxFY9gY"

JsonWebToken.decode(JsonWebToken.encode(data))
# => {"name"=>"AppSignal", "exp"=>1685424262}

Notice how the result of JsonWebToken.encode(data) is split into three parts by a period, producing the header, payload, and signature. We have the signature bit because we signed our payload with a secret key that Rails provides through Rails.application.secrets.secret_key_base.

Back to the `User` Model

Now will be a good time to visit our User model at app/models/user.rb. All we need to do here is add the has_secure_password class method:

class User < ApplicationRecord
  has_secure_password
end

has_secure_password securely hashes our users' passwords in the database.

Create a Sample User and Product in Rails

Now we can hop into the Rails console to generate a sample user and product in our database and test the security of our application:

User.create(username: "emi", password: "password")
Product.create(name: "Rad Ruby", description: "A book collection of Ruby tips")

You can place the same piece of code in your seeds.rb file to save some typing in case you reset your database.

Using JWTs in Rails Controllers

In the next steps, we'll implement security using JWTs inside our controllers. A good place to start is the ApplicationController at app/controllers/application_controller.rb:

class ApplicationController < ActionController::API
  before_action :authenticate

  rescue_from JWT::VerificationError, with: :invalid_token
  rescue_from JWT::DecodeError, with: :decode_error

  private

  def authenticate
    authorization_header = request.headers['Authorization']
    token = authorization_header.split(" ").last if authorization_header
    decoded_token = JsonWebToken.decode(token)

    User.find(decoded_token[:user_id])
  end

  def invalid_token
    render json: { invalid_token: 'invalid token' }
  end

  def decode_error
    render json: { decode_error: 'decode error' }
  end
end

Here, we create an authenticate method to decode JSON Web tokens that users send us. If we can successfully verify the token, we return the User object that represents the user making the request. We're mostly interested in the happy path here and will bypass a lot of checks.

Defining the authenticate method in the ApplicationController and setting it up as a before_action secures every controller inheriting from it. A request to any other controller will need a valid JWT to access those controllers (because every other controller will inherit this main controller).

Next, we need an AuthenticationController to which users can send requests and get a signed JSON Web Token from our server. This controller should be placed at app/controllers/authentication_controller.rb and may look like this:

class AuthenticationController < ApplicationController
  skip_before_action :authenticate

  def login
    user = User.find_by(username: params[:username])
    authenticated_user = user&.authenticate(params[:password])

    if authenticated_user
      token = JsonWebToken.encode(user_id: user.id)
      expires_at = JsonWebToken.decode(token)[:exp]

      render json: { token:, expires_at: }, status: :ok
    else
      render json: { error: 'unauthorized' }, status: :unauthorized
    end
  end
end

When a request hits this controller, because it's a user asking for a token, we don't want to initially authenticate them. The purpose of this controller is to respond with a token the user can use to access the rest of the resources on our server. Hence the need for skip_before_action :authenticate on the second line.

In the login action (the one that users hit for a token), we grab the username and password from the parameters that come with the request to this controller. If we can authenticate the user — that is, verify if their username and password match what we have stored in our database — then we present them with a signed token and information about when that token expires.

In our case, we won't use the expiry period of the token. But in a production application, that could be used to revoke access to a resource.

We'll go through all these steps using curl later on.

Testing Our Ruby Application with a Protected Resource

We partly covered the flow in the earlier 'Implementing JWT authentication in a Rails App' section's flow diagram. To completely cover everything and test out all the steps in the flow diagram, we need a resource to protect.

We have a Product model already. We now need a controller for the product model and routes to access the product and tokens.

Let's create a controller with rails g controller Product index so we have something like:

class ProductsController < ApplicationController
  before_action :authenticate

  def index
    @products = Product.all

    render json: @products
  end
end

Of course, we need a route to access these controllers. Our config/routes.rb should look something like:

Rails.application.routes.draw do
  post 'login', to: "authentication#login"
  get 'products', to: "products#index"
end

Now we'll test with curl to see if everything works as expected. Note that we already have a user to authenticate and a product resource to access.

Let's try getting a JWT with a user that doesn't exist:

curl -H "Content-Type: application/json" -X POST -d '{"username":"manny","password":"password"}' http://localhost:3000/login

We should get the following response:

{"error":"unauthorized"}

Now try the same with a user that we created earlier:

curl -H "Content-Type: application/json" -X POST -d '{"username":"emi","password":"password"}' http://localhost:3000/login

This should give us a signed JSON web token that could look like this:

{"token":"eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE2ODU0NTEyMTR9.1UEYAbmFOSF93yp9pJqNEzkdHr3rVqutPNZWRIPDYkY","expires_at":1685432077}

Let's keep this token for a second and try accessing a product resource with a bad token (I changed a random character in the token):

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE2ODU0NTEyMTR9.1UEYAbmFOSF93yp9pJqNEzkdHr3rVqutPNZWRIPZYkY" http://localhost:3000/products

And we should get:

{"decode_error":"decode error"}

However, if we make the same request to access the product resource with the valid token we got from the server previously:

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE2ODU0NTEyMTR9.1UEYAbmFOSF93yp9pJqNEzkdHr3rVqutPNZWRIPDYkY" http://localhost:3000/products

We're granted access to the product resource:

[{"id":1,"name":"Rad Ruby","description":"A book collection of Ruby tips","created_at":"2023-05-29T19:33:30.826Z","updated_at":"2023-05-29T19:33:30.826Z"}]

That's it! We've successfully secured our Ruby application with a JSON web token!

Wrapping Up

In this post, we discussed JSON Web Tokens and how they work. We first covered the basics of JWTs, including their structure and some best practices. Then we implemented a simple JWT authentication using the jwt gem.

I hope you've found this post helpful. Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

What's New in Rails 7.1

Emmanuel Hayford — Tue, 28 Feb 2023 15:53:35 +0000

Rails 7 was a welcome release that brought a lot of significant features and changes. On the backend, Rails 7 introduced asynchronous query loading and Zeitwerk for autoloading. The frontend saw Hotwire becoming the default solution for new Rails apps.

Rails 7.1 will add to these notable features. In this post, we'll discuss some noteworthy additions that are likely to be shipped.

A New API for Async Queries in Rails

Building on an earlier feature from Rails 7, Rails 7.1 will make it possible to run some queries asynchronously. Rails 7 introduced ActiveRecord::Relation#load_async, which schedules a query in a background thread pool, allowing us to do stuff like Post.where(published: true).load_async.

In Rails 7.1, we'll be able to run a lot more queries in background threads. Aggregate methods will run concurrently. Assuming you run two or more independent queries on a job or controller, query results may return quicker if your application is set up accordingly.

For this to work as intended, there are two configuration options worth paying attention to:

config.active_record.async_query_executor
config.active_record.global_executor_concurrency

Among the methods you can run asynchrously in Rails 7.1 are async_sum, async_pluck, and async_count_by_sql.

Resetting Singular Associations

Rails 7.1 allows resetting the cache on singular associations. Currently, you can only clear the cache of has_many associations with a class like:

class Teacher < ActiveRecord::Base
  has_many :students
  has_one :classroom
end

teacher = Teacher.first

We can only do teacher.students.reset to clear the caches of the results returned by teacher.students. Subsequent requests need to hit the database again for a fresh results set in case some data goes stale.

With Rails 7.1, we'll get the reset method on a has_one association. Using our example class above, Rails 7.1 will allow us to do teacher.classroom.reset_teacher to clear the cache for the associations between teacher and classroom.

Disabling Methods Generated By `ActiveRecord#enum`

ActiveRecord#enum generates a bunch of methods if you create an enum Rails. Rails 7.1 will provide an option to opt out of these generated methods. Here's a simple example:

class Payment < ActiveRecord::Base
  enum :status, %i[succeeded failed], instance_methods: false
end

Rails won't generate auxiliary methods with instance_methods: false. Currently, we expect to have methods like:

payment = Payment.first

payment.succeeded?
payment.failed?

payment.succeeded!
payment.failed!

Support for Common Table Expressions

Rails 7.1 will have in-built support for Common Table Expressions (CTEs). This ensures that code will be more succinct but, more importantly, that we won't have to use Arel::Nodes for complex queries.

With Rails 7.1, we'll have a new .with method to write queries similar to the one below:

Post.with(
  posts_with_comments: Post.where("comments_count > ?", 0),
  posts_with_tags: Post.where("tags_count > ?", 0)
)

Support for Async Bulk Record Destruction

As mentioned, Rails 7.1 will introduce several ways to run code asynchronously. One such new addition to async code executions is the destroy_association_async_batch_size configuration.

With this new configuration, Rails applications can set a maximum number of records to be destroyed in a single background job by the dependent: :destroy_async association.

The default behavior, where all dependent records are destroyed in a single background job when the parent record is destroyed, will remain unchanged. However, if the number of dependent records exceeds the new configuration, they will be destroyed in multiple background jobs.

Other Rails 7.1 Updates

`ActiveRecord::Relation#explain` Accepts Options

Rails 7.1 will allow you to pass database systems that support EXPLAIN options to ActiveRecord::Relation#explain. An example query might look like this:

Customer.where(id: 1).joins(:orders).explain(:analyze, :verbose)

Active Record `regroup`

Active Record will allow for "regrouping" queries with a new regroup method that can be used like so: Post.group(:title).regroup(:author). This generates SQL equivalent to SELECT posts.* FROM posts GROUP BY posts.author.

The same can be achieved in current versions of Rails with more verbose code:

 Post.group(:title)..unscope(:group).group(:author)

New `stub_const method` for Testing

A new stub_const method for ActiveSupport::TestCase will be added that stubs a constant for a yield's duration.

For example:

# World::List::Import::LARGE_IMPORT_THRESHOLD = 5000

stub_const(World::List::Import, :LARGE_IMPORT_THRESHOLD, 1) do
  assert_equal 1, World::List::Import::LARGE_IMPORT_THRESHOLD
end

assert_equal 5000, World::List::Import::LARGE_IMPORT_THRESHOLD = 5000

Take note, however, that stubbing a constant will affect its value across all threads in a multi-threaded setup. This means that if multiple concurrent threads rely on the same constant, simultaneous and conflicting stubbing may occur.

Password Challenge via `has_secure_password`

Rails 7.1 has improved the functionality of has_secure_password by adding a password_challenge accessor and a corresponding validation. The validation will verify that a password_challenge matches the stored password_digest.

With this, implementing a password challenge becomes as straightforward as a password confirmation. This also enables reusing the same error-handling logic in both the view and the controller.

For instance, instead of writing separate code in the controller, you will simply use the existing logic for password confirmation.

password_params = params.require(:password).permit(
  :password_challenge,
  :password,
  :password_confirmation,
).with_defaults(password_challenge: "")

if current_user.update(password_params)
  # perform some work
end

Saving Attachments Returning the Blob

With Rails 7.1, when you save attachments to a record, the attach method will return the attached blob or blobs. This enables the direct use of blob methods on the attachment. However, if the record fails to save, attach will return false.

Here's an example demonstrating its use:

@user = User.create!(name: "Josh")
avatar = @user.avatar.attach(params[:avatar])

# You can now directly call blob methods as follows:
avatar.download
avatar.url
avatar.variant(:thumb)

Storage of CSRF Tokens Outside of Sessions

Rails has introduced a new configuration option to address the excessive creation and eviction of millions of sessions for just storing a CSRF token when sessions are not stored in cookies.

This option allows the use of a lambda function to store the CSRF token in a custom location, thus enabling the storage of CSRF tokens outside of sessions.

You can also create custom strategy classes for storing CSRF tokens.

class CustomStore
  def fetch(request)
    # Return the token from a custom location
  end

  def store(request, csrf_token)
    # Store the token in a custom location
  end

  def reset(request)
    # Delete the stored session token
  end
end

class ApplicationController < ActionController:x:Base
  protect_from_forgery store: CustomStore.new
end

Validity Checking for PostgreSQL Indexes

Creating indexes as shown below may lead to an invalid index:

add_index :account, :active, algorithm: :concurrently

With Rails 7.1, you can verify an index's validity as shown here:

connection.index_exists?(:users, :email, valid: true)
connection.indexes(:users).select(&:valid?)

`ActiveRecord::QueryMethods#select` Accepts a Hash

ActiveRecord::QueryMethods#select in Rails 7.1 now accepts a hash of options. This is best demonstrated with an example:

# You can now write selects like this:
Post.joins(:comments).select(
  posts: { id: :post_id, title: :post_title },
  comments: { id: :comment_id, body: :comment_body}
)

# In place of this:
Post.joins(:comments).select(
  "posts.id as post_id, posts.title as post_title,
  comments.id as comment_id, comments.body as comment_body"
)

Number of Processors Match the Puma Worker Count

By default, newly generated Rails applications will have Puma workers that are capped at the total number of physical processors on the host machine. This default setting can always be changed in the puma.rb file.

The puma.rb file for newly-generated Rails applications will now look like the following:

if ENV["RAILS_ENV"] == "production"
  worker_count = ENV.fetch("WEB_CONCURRENCY") { Concurrent.physical_processor_count }
  workers worker_count if worker_count > 1
end

`preload` and `eager_load` Associations to Be Unscoped

Rails 7.1 will add the ability to unscope preloaded and eager loaded associations in a manner similar to how Active Record's includes, select, and joins methods work.

This feature allows for the use of aggregate functions on has_many associations previously loaded through eager_load or preload in existing queries.

An example usage could look like:

query.unscope(:eager_load, :preload).group(:id).select(:id)

Default Dockerfiles for New Rails Applications

Docker files are to be added as a default option for new Rails applications. The files include:

Dockerfile
.dockerignore
bin/docker-entrypoint

These files serve as a starting point for deploying an application in a production environment and are not intended for use during development. However, if desired, you can skip these files by using the --skip-docker option.

Default Health Controller

Rails 7.1 introduces a new endpoint for load balancers and uptime monitors. The endpoint, named Rails::HealthController#show, is mapped to the "/up" path in newly generated Rails applications. This allows load balancers and uptime monitors to easily track an app's availability.

Note that monitoring the database, Redis, and internal network connections to microservices that an application relies on must be managed separately.

New `Rails.env.local?` for Environment Checks

In Rails 7.1, a new local? method can be used to simplify environment checks.

You'll be able to replace code like:

if Rails.env.development? || Rails.env.test?
end

With:

if Rails.env.local?
end

New `ActiveRecord::Persistence#update_attribute!` Method

Rails has added a new method, ActiveRecord::Persistence#update_attribute!, which functions similarly to update_attribute but uses save! instead of save.

Here's how you could use this new method:

class Apm < ActiveRecord::Base
  before_save :check_name

  def check_name = throw(:abort) if name == "abort"
end

monitor = Apm.create(name: "App Signal")
# => #<Apm name: "App Signal">

monitor.update_attribute!(:name, "AppSignal")
# => #<Apm name: "AppSignal">

monitor.update_attribute!(:name, "abort")
# raises ActiveRecord::RecordNotSaved

Templates Capable of Defining Accepted Locals

Templates will be enhanced with the option of required arguments that have default values.

Currently, templates accept any locals as keyword arguments. With 7.1, Rails templates will define specific accepted locals through a magic comment.

This improvement provides greater control and customization options for template behavior and functionality.

A partial in Rails could now look like:

<%# locals: (title: "Default title", comment_count: 0) %>

<h2><%= title %></h2>
<span class="comment-count"><%= comment_count %></span>

Instead of:

<% title = local_assigns[:title] || "Default title" %>
<% comment_count = local_assigns[:comment_count] || 0 %>

<h2><%= title %></h2>
<span class="comment-count"><%= comment_count %></span>

Wrapping Up

As you can see, Rails 7.1 promises a lot of further improvements on Rails 7.

For more information on features, updates, and bug fixes, check out the Rails 7.1 release notes.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

A Quick Way To Locally Ignore Files From Git.

Emmanuel Hayford — Fri, 17 May 2019 20:51:47 +0000

Often times, I've found myself having to git ignore some files that I shouldn't be pushing to a repository on GitHub, so I'd do something like git add file.rb another_file.rb selectively just so I can commit only the files that I want to make changes to. This is tedious, not to mention a huge waste of time.

If you're familiar with Rails, sometimes you'll need to make a change to your database.yml or even to your Gemfile. Changes you make to these files are only specific to you and you don't need to push this for everyone else, neither do you want to edit .gitignore.

Here's an easy way to locally ignore your changes so you don't have to keep tracking them mistakenly or spend time to selectively track some files.

I added these commands to my aliases so they're easy to access:

alias untrack='git update-index --assume-unchanged'

You can use this like so: untrack database.yml

To undo this you'd do track database.yml but only if you've added track='git update-index --no-assume-unchanged' and of course untrack and track can be anything you choose.

Happy coding!

DEV Community: Emmanuel Hayford

Secure Your Ruby App with JSON Web Tokens

What is a JSON Web Token?

The Basic Structure of JSON Web Tokens

JWTs Vs. Other Authentication Methods for Your Ruby App

Why Use JWTs for Authentication?

JWT Best Practices for Ruby Apps

Implementing JWT authentication in a Rails App

Using the jwt and bcrypt Ruby Gems

Building our Rails API

Generate User and Product Models

Build a jwt Gem Wrapper

Back to the User Model

Create a Sample User and Product in Rails

Using JWTs in Rails Controllers

Testing Our Ruby Application with a Protected Resource

Wrapping Up

What's New in Rails 7.1

A New API for Async Queries in Rails

Resetting Singular Associations

Disabling Methods Generated By ActiveRecord#enum

Support for Common Table Expressions

Support for Async Bulk Record Destruction

Other Rails 7.1 Updates

ActiveRecord::Relation#explain Accepts Options

Active Record regroup

New stub_const method for Testing

Password Challenge via has_secure_password

Saving Attachments Returning the Blob

Storage of CSRF Tokens Outside of Sessions

Validity Checking for PostgreSQL Indexes

ActiveRecord::QueryMethods#select Accepts a Hash

Number of Processors Match the Puma Worker Count

preload and eager_load Associations to Be Unscoped

Default Dockerfiles for New Rails Applications

Default Health Controller

New Rails.env.local? for Environment Checks

New ActiveRecord::Persistence#update_attribute! Method

Templates Capable of Defining Accepted Locals

Wrapping Up

A Quick Way To Locally Ignore Files From Git.

Using the `jwt` and `bcrypt` Ruby Gems

Generate `User` and `Product` Models

Build a `jwt` Gem Wrapper

Back to the `User` Model

Disabling Methods Generated By `ActiveRecord#enum`

`ActiveRecord::Relation#explain` Accepts Options

Active Record `regroup`

New `stub_const method` for Testing

Password Challenge via `has_secure_password`

`ActiveRecord::QueryMethods#select` Accepts a Hash

`preload` and `eager_load` Associations to Be Unscoped

New `Rails.env.local?` for Environment Checks

New `ActiveRecord::Persistence#update_attribute!` Method