Forem: Renzo Diaz

Build a Secure API with Rails 8 - Part-3: Auth Controllers

Renzo Diaz — Mon, 25 May 2026 00:48:30 +0000

Hey folks 👋

Welcome back. In Part 2 we laid the foundation: a Rails 8 API with a User model, password hashing through Devise, OAuth2 password grant via Doorkeeper, JWT access tokens, refresh tokens, and HttpOnly cookie storage. Solid base, but no actual endpoints yet.

Today we fix that. We are going to write the auth controllers (register, login, logout, refresh, and me), and while we do it we'll knock out four more vectors from the tracker: CSRF, User Enumeration, Mass Assignment, and Excessive Data Exposure. We'll also add rate limiting, encrypted DB fields, secure HTTP headers, and structured logging.

Heads up before we start: this part is longer than Part 2. I thought about splitting it again, but everything here belongs together. Controllers without rate limiting are half-protected, and rate limiting without controllers to protect is pointless. So grab a coffee and let's go.

What we are building in Part 3

Pundit for authorization, Rack-CORS to control who can talk to our API
A versioned API structure (/api/v1/...) so we don't paint ourselves into a corner later
Auth controllers: register, login, logout, refresh, and a me endpoint
Rate limiting with Rack-Attack to slow down brute force attempts
Encrypted DB fields with Lockbox for sensitive data
HTTP security headers with secure_headers
Structured logs with Lograge

If your Part 2 project is sitting on your disk, open it up and let's continue.

Step 1. Add Pundit and Rack-CORS

Pundit handles authorization (the "what is this user allowed to do" question, as opposed to "who is this user" which Devise already answered). Rack-CORS controls which domains are allowed to make requests to our API from a browser.

Open your Gemfile:

# Authentication & Authorization
# ...
gem 'pundit'

# Security
gem 'rack-cors'

Then:

bundle install
bin/rails g pundit:install

The generator creates app/policies/application_policy.rb, which we'll use later when we add real resources.

Step 2. Configure CORS

Open config/initializers/cors.rb and replace it with:

# frozen_string_literal: true

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    # In production, replace with your real frontend domain
    origins ENV.fetch("FRONTEND_URL", "http://localhost:5173")

    resource "*",
      headers: :any,
      methods: %i[get post put patch delete options head],
      credentials: true,
      expose: %w[X-CSRF-Token]
  end
end

A mistake I have personally made and seen a hundred times in code reviews: don't use origins '*' with credentials: true. Browsers will reject it outright, and even if they didn't, it would mean any website on the internet could make authenticated requests to your API. Always pin the origin to your real frontend domain (or domains, you can pass an array).

The credentials: true part is required because our auth lives in cookies. Without it, the browser won't attach the session cookie to cross-origin requests, and login will appear to "work" but every following request will look anonymous. I spent an embarrassing afternoon on that one.

🛡️ Mitigation in action: CSRF foundation (Part 1, vector 3)

Locking down origins is the first half of CSRF defense. Combined with SameSite=Lax from Part 2, a random attacker site can't trick a logged-in user's browser into hitting our API. We'll add explicit CSRF tokens later in this post for the parts that need them.

Step 3. Update ApplicationController

ApplicationController is the entry point for every request. Everything else inherits from it. We need it to do three things: include cookie support, plug in Pundit, and require a valid Doorkeeper token by default (so endpoints are private unless we explicitly say otherwise).

Edit app/controllers/application_controller.rb:

# frozen_string_literal: true

class ApplicationController < ActionController::API
  include ActionController::Cookies
  include Pundit::Authorization

  before_action :doorkeeper_authorize!, unless: :skip_authorization?

  private

  def current_user
    return @current_user if defined?(@current_user)
    @current_user = User.find_by(id: doorkeeper_token.resource_owner_id) if doorkeeper_token
  end

  def skip_authorization?
    false
  end
end

The skip_authorization? method defaults to false, meaning every endpoint requires a token. Individual controllers (like login and register, which obviously can't require you to already be logged in) will override it to return true for specific actions. I prefer this "deny by default" pattern because forgetting to add auth is a much more common bug than forgetting to mark something public.

One thing I want to call out: current_user looks up the user from doorkeeper_token.resource_owner_id. That resource_owner_id was set back in Part 2 when Doorkeeper issued the token. The JWT itself carries the user ID, so we are NOT hitting the database to verify the token, only to load the user record. That's the whole point of JWT.

Step 4. Create the versioned BaseController

Eventually you will want to release a v2 of your API without breaking the v1 clients that are already in the wild. There are several ways to version an API (custom headers, content negotiation, URL paths). I've used all three and I'll save you the suspense: URL path versioning (/api/v1/...) is the easiest to debug, the easiest to document, and the easiest for new teammates to understand. We're going with that.

Create the folder structure:

mkdir -p app/controllers/api/v1

Then create app/controllers/api/v1/base_controller.rb:

# frozen_string_literal: true

module Api
  module V1
    class BaseController < ApplicationController
      rescue_from ActiveRecord::RecordNotFound, with: :not_found
      rescue_from ActiveRecord::RecordInvalid,  with: :unprocessable_entity
      rescue_from Pundit::NotAuthorizedError,   with: :forbidden

      private

      def not_found
        render json: { error: "Not found" }, status: :not_found
      end

      def unprocessable_entity(exception)
        render json: { errors: exception.record.errors.full_messages },
               status: :unprocessable_entity
      end

      def forbidden
        render json: { error: "Access denied" }, status: :forbidden
      end
    end
  end
end

Every controller from now on inherits from BaseController, which means every controller gets these three error handlers for free.

🛡️ Mitigation in action: Verbose Error Messages (Part 1, vector 11)

Notice that forbidden returns a generic "Access denied" message. It does NOT say "you don't own this record" or "your role is missing the admin scope". That detail is gold for an attacker probing your API. Same idea for not_found: we just say "Not found", we don't leak whether the record exists but is private, or doesn't exist at all.

We'll fully button up production error handling in Part 4, but this is the start.

Step 5. SessionsController (login, logout, refresh)

Now the fun part. The sessions controller handles login, logout, and refresh. I'm going to paste the whole thing and then walk through the parts that matter.

Create app/controllers/api/v1/sessions_controller.rb:

# frozen_string_literal: true

module Api
  module V1
    class SessionsController < BaseController
      skip_before_action :doorkeeper_authorize!, only: %i[create refresh]

      # POST /api/v1/auth/login
      def create
        user = User.find_for_database_authentication(email: params[:email])

        if user&.valid_password?(params[:password])
          tokens = generate_tokens(user)
          set_auth_cookies(tokens)
          render json: { user: user_response(user), expires_at: tokens[:expires_at] }
        else
          render json: { error: "Invalid credentials" }, status: :unauthorized
        end
      end

      # DELETE /api/v1/auth/logout
      def destroy
        revoke_tokens
        clear_auth_cookies
        render json: { message: "Logged out successfully" }
      end

      # POST /api/v1/auth/refresh
      def refresh
        refresh_token = cookies.encrypted[:refresh_token]
        return render json: { error: "No refresh token" }, status: :unauthorized if refresh_token.blank?

        existing = Doorkeeper::AccessToken.by_refresh_token(refresh_token)

        if existing.nil? || existing.revoked? || refresh_expired?(existing)
          clear_auth_cookies
          return render json: { error: "Expired session" }, status: :unauthorized
        end

        user = User.find_by(id: existing.resource_owner_id)
        existing.revoke

        tokens = generate_tokens(user)
        set_auth_cookies(tokens)
        render json: { user: user_response(user), expires_at: tokens[:expires_at] }
      end

      private

      def skip_authorization?
        action_name.in?(%w[create refresh])
      end

      def generate_tokens(user)
        token = Doorkeeper::AccessToken.create!(
          resource_owner_id: user.id,
          expires_in: Doorkeeper.configuration.access_token_expires_in,
          scopes: "read write",
          use_refresh_token: true
        )
        {
          access_token: token.token,
          refresh_token: token.refresh_token,
          expires_at: token.expires_in.seconds.from_now.iso8601
        }
      end

      def set_auth_cookies(tokens)
        cookie_opts = { httponly: true, secure: Rails.env.production?, same_site: :lax }

        cookies.encrypted[:access_token] = cookie_opts.merge(
          value: tokens[:access_token],
          expires: 15.minutes.from_now
        )
        cookies.encrypted[:refresh_token] = cookie_opts.merge(
          value: tokens[:refresh_token],
          expires: 7.days.from_now
        )
      end

      def clear_auth_cookies
        cookies.delete(:access_token)
        cookies.delete(:refresh_token)
      end

      def revoke_tokens
        token = Doorkeeper::AccessToken.by_refresh_token(cookies.encrypted[:refresh_token])
        token&.revoke
      end

      def refresh_expired?(token)
        token.created_at + 7.days < Time.current
      end

      def user_response(user)
        { id: user.id, email: user.email }
      end
    end
  end
end

A few things worth pausing on.

The login response is intentionally vague. When credentials are wrong, we return "Invalid credentials". Not "no user with that email", not "wrong password". Both of those leak information. The first time I built an API I had a friendly "Email not found, would you like to sign up?" message. That message is also a free oracle for an attacker to verify whether victim@gmail.com has an account on your platform. Don't help them.

🛡️ Mitigation in action: User Enumeration (Part 1, vector 5)

Generic auth errors are the single cheapest mitigation in this whole series. Cost: zero. Benefit: attackers can't build a list of valid emails by hitting your login endpoint.

Refresh tokens are rotated. Look at the refresh action: when a refresh token is used, we immediately call existing.revoke on it before issuing a new one. This means a refresh token is single-use. If an attacker manages to steal a refresh token from your cookies and uses it, the legitimate user's next refresh will fail (because the attacker already burned it), and you can detect the anomaly. We're not implementing the detection part today, but the rotation alone already raises the cost of an attack significantly.

Logout actually revokes the token. A surprising number of "logout" endpoints I have reviewed in real production code just delete the cookie. That works for the honest user, but if anyone has copied the JWT before logout, it's still valid until it expires naturally. Calling token.revoke puts it on the revocation list so it can't be used again, no matter who has it.

🛡️ Mitigation in action: Token Theft (Part 1, vector 10)

Refresh rotation plus revocation on logout closes the last gap from Part 2. Now if a token leaks, we have a way to kill it.

Step 6. RegistrationsController

Create app/controllers/api/v1/registrations_controller.rb:

# frozen_string_literal: true

module Api
  module V1
    class RegistrationsController < BaseController
      skip_before_action :doorkeeper_authorize!

      def create
        user = User.new(user_params)

        if user.save
          render json: { message: "Account created successfully" }, status: :created
        else
          render json: { errors: user.errors.full_messages }, status: :unprocessable_entity
        end
      end

      private

      def skip_authorization?
        true
      end

      def user_params
        params.require(:user).permit(:email, :password, :password_confirmation)
      end
    end
  end
end

The interesting line is user_params. It explicitly lists which fields are allowed: email, password, password_confirmation. Nothing else. If a clever user POSTs { "user": { "email": "...", "password": "...", "admin": true, "role": "superuser" } }, those extra fields are silently dropped.

🛡️ Mitigation in action: Mass Assignment (Part 1, vector 7)

This is the OWASP "mass assignment" vector. Strong params is Rails' built-in fix. The rule I follow: every controller that takes user input has a *_params method, and that method whitelists only the fields it expects. Never use params[:user] directly to build a record. Ever.

Notice also that on success we don't echo back the user's data. Just a message. That keeps us from accidentally returning fields we never meant to expose.

🛡️ Mitigation in action: Excessive Data Exposure (Part 1, vector 8)

Same idea on the way out. We'll formalize this with serializers later (probably alba because it's fast and dependency-free), but for now the rule is: build the response hash by hand, listing exactly which fields go out.

Step 7. UsersController and the `me` endpoint

The frontend needs a way to ask "am I logged in, and if so, who am I?" on page load. That's the classic me endpoint.

Create app/controllers/api/v1/users_controller.rb:

# frozen_string_literal: true

module Api
  module V1
    class UsersController < BaseController
      # GET /api/v1/me
      def me
        render json: { user: user_response(current_user) }, status: :ok
      end

      private

      def user_response(user)
        {
          id: user.id,
          email: user.email,
          created_at: user.created_at.iso8601
        }
      end
    end
  end
end

Same pattern as before: hand-built response hash, only the fields we want to expose. encrypted_password, sign_in_count, reset_password_token, none of that should leak out, and with this pattern it can't.

Step 8. Wire up the routes

Open config/routes.rb:

Rails.application.routes.draw do
  use_doorkeeper do
    skip_controllers :authorizations, :applications,
                     :authorized_applications, :tokens
  end

  namespace :api do
    namespace :v1 do
      post   'auth/register', to: 'registrations#create'
      post   'auth/login',    to: 'sessions#create'
      delete 'auth/logout',   to: 'sessions#destroy'
      post   'auth/refresh',  to: 'sessions#refresh'

      get 'me', to: 'users#me'
    end
  end

  get "up" => "rails/health#show", as: :rails_health_check
end

The skip_controllers block on Doorkeeper is important. Out of the box, Doorkeeper mounts a bunch of OAuth2 endpoints (authorization page, application management, etc) that are designed for the browser-based OAuth flow. We don't need any of that, so we strip it out. Less code on the public internet means less attack surface.

Here's the API at a glance:

Method	Endpoint	Description	Auth required
POST	`/api/v1/auth/register`	Create new account	No
POST	`/api/v1/auth/login`	Login, sets cookies	No
DELETE	`/api/v1/auth/logout`	Revoke tokens, clear cookies	Yes
POST	`/api/v1/auth/refresh`	Refresh access token	Cookie only
GET	`/api/v1/me`	Current user data	Yes

Step 9. Test with curl

The trick when testing cookie-based auth with curl is the -c and -b flags. -c cookies.txt saves the cookies the server returns, -b cookies.txt sends them on the next request. It's basically what the browser does for you.

curl -X POST http://localhost:3000/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"user": {"email": "me@example.com", "password": "s3cr3tP@ss", "password_confirmation": "s3cr3tP@ss"}}'

curl -X POST http://localhost:3000/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -c cookies.txt \
  -d '{"email": "me@example.com", "password": "s3cr3tP@ss"}'

Me (protected, sends cookies):

curl http://localhost:3000/api/v1/me -b cookies.txt

Refresh:

curl -X POST http://localhost:3000/api/v1/auth/refresh \
  -b cookies.txt -c cookies.txt

Logout:

curl -X DELETE http://localhost:3000/api/v1/auth/logout -b cookies.txt

If all five of those work, your auth flow is alive. But we're not done. An attacker right now can hit /login ten thousand times per second with different passwords. Let's fix that.

Step 10. Rate limiting with Rack-Attack

Rack-Attack sits in the middleware stack and inspects every request before it reaches your controllers. It can throttle, block, or safelist IPs based on rules you define. It's stupidly simple to set up and saves you from a lot of pain.

Add it to your Gemfile:

# Security
# ...
gem 'rack-attack'

Then bundle install.

Create config/initializers/rack_attack.rb:

# frozen_string_literal: true

class Rack::Attack
  # Throttle login attempts by IP: max 5 per 20 seconds
  throttle('logins/ip', limit: 5, period: 20.seconds) do |req|
    req.ip if req.path == '/api/v1/auth/login' && req.post?
  end

  # Throttle login attempts by email: max 5 per 20 seconds
  throttle('logins/email', limit: 5, period: 20.seconds) do |req|
    if req.path == '/api/v1/auth/login' && req.post?
      req.params['email'].to_s.downcase.gsub(/\s+/, "")
    end
  end

  # General API limit: 300 requests per IP per 5 minutes
  throttle('api/ip', limit: 300, period: 5.minutes) do |req|
    req.ip if req.path.start_with?('/api')
  end

  # Custom response when throttled
  self.throttled_responder = lambda do |req|
    retry_after = (req.env["rack.attack.match_data"] || {})[:period]
    [
      429,
      {
        'Content-Type' => 'application/json',
        'Retry-After' => retry_after.to_s
      },
      [{ error: "Too many requests. Please slow down." }.to_json]
    ]
  end
end

Why throttle by both IP and email? An attacker with a botnet can rotate through thousands of IPs, and IP-only throttling won't catch them because each IP only sends a few requests. But all those requests are still targeting the same email, so the email-based throttle does catch them. The reverse is also true: a single attacker hammering many different accounts from one IP gets caught by the IP throttle. The two rules together cover both attack shapes.

🛡️ Mitigation in action: Brute Force (Part 1, vector 4)

Combined with bcrypt's slowness from Part 2, this makes online brute force impractical. Five attempts per 20 seconds means an attacker can try maybe 15 passwords per minute, per email. At that rate, even a weak password takes years to crack.

One gotcha I learned the hard way: in development, Rack-Attack defaults to using the memory store, which resets every time you restart the server. That's fine. But in production you almost certainly want to point it at Redis, otherwise each app server has its own counter and an attacker can bypass the limit by spreading requests across servers. I'll show that config when we deploy in a later part.

Step 11. HTTP security headers with secure_headers

The browser will enforce a bunch of security policies for you, but only if you tell it to. The secure_headers gem makes that easy.

Add it to the Gemfile:

gem 'secure_headers'

bundle install, then create config/initializers/secure_headers.rb:

SecureHeaders::Configuration.default do |config|
  # Force HTTPS for 1 year
  config.hsts = "max-age=31536000; includeSubDomains"

  # Restrict what resources can load
  config.csp = {
    default_src: %w['self'],
    script_src: %w['self'],
    connect_src: %w['self']
  }

  # Prevent your site from being framed (clickjacking)
  config.x_frame_options = "DENY"

  # Stop MIME type sniffing
  config.x_content_type_options = "nosniff"

  # Legacy XSS filter (still useful for older browsers)
  config.x_xss_protection = "1; mode=block"

  # Don't leak full URLs in the Referer header
  config.referrer_policy = "strict-origin-when-cross-origin"
end

Quick tour of what each header does:

HSTS tells browsers "for the next year, never talk to this domain over plain HTTP". This shuts down SSL stripping attacks, where an attacker on the same Wi-Fi downgrades your connection to HTTP.
X-Frame-Options: DENY stops other sites from loading yours in an iframe, which is the foundation of clickjacking attacks.
X-Content-Type-Options: nosniff stops browsers from guessing the content type of a response, which has historically been used to execute scripts that were uploaded as "images".
CSP is the big one. It tells the browser exactly which sources of scripts, styles, and connections are allowed. Our config here is very strict ("self" only), which is appropriate for a pure API. If you're serving HTML too, you'll need to relax it.

🛡️ Mitigation in action: MITM (Part 1, vector 9)

HSTS plus secure: true on cookies (set in Part 2) is the one-two punch against MITM attacks. Combined with force_ssl in production (coming in Part 4), there's no way for an attacker on your network to downgrade the connection.

Step 12. Encrypt sensitive fields with Lockbox

bcrypt protects passwords because it's a one-way hash, you never need to read the original. But what about fields you DO need to read, like phone numbers, addresses, or government IDs? You can't hash those. You need to encrypt them, so the database stores ciphertext and the app decrypts it in memory when needed.

That's what Lockbox does.

Add to the Gemfile:

# Encryption
gem 'lockbox'

bundle install. Then generate a master key:

bin/rails runner "puts Lockbox.generate_key"

Take the output and store it in your Rails credentials (bin/rails credentials:edit):

lockbox_master_key: <paste the generated key here>

Create config/initializers/lockbox.rb:

Lockbox.master_key = Rails.application.credentials.lockbox_master_key

Now in any model, you can mark fields as encrypted. For example, if we added a phone column to User:

class User < ApplicationRecord
  encrypts :phone

  # If you need to search by encrypted field, use blind_index
  blind_index :phone
end

The migration would look like:

bin/rails generate migration AddEncryptedPhoneToUsers

add_column :users, :phone_ciphertext, :text
add_column :users, :phone_bidx, :text  # for blind_index searching

Then bin/rails db:migrate.

encrypts :phone means the value is encrypted before INSERT and decrypted on read. The database column is literally named phone_ciphertext and contains base64 ciphertext. If someone dumps your database, they see nothing.

blind_index is a clever workaround for the obvious problem with encrypted fields: you can't search them, because two encryptions of the same value produce different ciphertext. The blind index is a deterministic hash of the value, stored separately, which you can search on. It's not as private as the encryption itself, but it lets User.where(phone: "...") actually find records.

I'm not adding a phone field in this tutorial because we don't need one yet, but I wanted to show the pattern so you can apply it when you do add sensitive fields. Personal rule of thumb: any field that would be embarrassing or harmful if it leaked, encrypt it.

Step 13. Structured logs with Lograge

Rails' default log format is fine for development but painful in production. You get six lines per request, none of them parseable as structured data, and no consistent fields. Lograge condenses each request to a single structured line that you can ship to Datadog, Loki, CloudWatch, or whatever you use.

Add to the Gemfile:

# Monitoring & Logging
gem 'lograge'

bundle install. Then create config/initializers/lograge.rb:

Rails.application.configure do
  config.lograge.enabled = true

  config.lograge.custom_options = lambda do |event|
    {
      time: Time.current.iso8601,
      host: event.payload[:host],
      user_id: event.payload[:user_id]
    }
  end
end

To get user_id into logs, you'll want to append it to the payload from ApplicationController:

def append_info_to_payload(payload)
  super
  payload[:host]    = request.host
  payload[:user_id] = current_user&.id if doorkeeper_token
end

This is small but huge when you're debugging at 2 AM and trying to figure out which user's session caused that 500 error.

Where we are right now

Five working auth endpoints, rate limiting, encrypted DB fields ready when you need them, hardened HTTP headers, and structured logs. The API is genuinely usable now, not just configured.

But we still have gaps. Most notably, we haven't done explicit CSRF tokens yet (the SameSite cookie helps but isn't enough on its own for state-changing endpoints), and we haven't tackled IDOR (insecure direct object references) which only becomes a problem once we have resources to reference. Both of those plus production error handling, force_ssl, and serializers are coming up.

Progress tracker: security vectors from Part 1

#	Attack vector	Status	Where
1	XSS	🟢 Mostly mitigated	HttpOnly cookies (Part 2) + strict CSP headers (Step 11)
2	SQL Injection	🟢 Mitigated by default	Active Record + strong params throughout controllers
3	CSRF	🟡 Partially mitigated	SameSite cookies + pinned CORS origins. Explicit CSRF tokens still pending. Part 4.
4	Brute Force	🟢 Mitigated	bcrypt + Rack-Attack IP and email throttles (Step 10)
5	User Enumeration	🟢 Mitigated	Generic "Invalid credentials" message (Step 5)
6	IDOR	🔴 Not yet	Will be addressed with Pundit policies + Sqids. Part 5.
7	Mass Assignment	🟢 Mitigated	Strong params in every controller (Step 6)
8	Excessive Data Exposure	🟡 Partially mitigated	Hand-built response hashes. Formal serializers in Part 4.
9	MITM	🟢 Mostly mitigated	HSTS (Step 11) + secure cookies. `force_ssl` in Part 4.
10	Token Theft	🟢 Mitigated	HttpOnly + encrypted cookies + short tokens + rotation + revocation on logout
11	Verbose Error Messages	🟡 Partially mitigated	Generic 403/404 responses (Step 4). Production rescue handler in Part 4.

Legend: 🟢 Covered, 🟡 Partial, 🔴 Pending

Coming up in Part 4

We finish the security checklist. CSRF tokens for the endpoints that need them, force_ssl and the production error handler, and we'll introduce a serializer library so we stop hand-rolling response hashes in every action. After that we'll be ready to start adding actual resources (and the IDOR mitigation that comes with them) in Part 5.

If this helped, follow along so you catch the next one. And if anything broke or didn't make sense, drop a comment, I read all of them.

Build a Secure API with Rails 8 - Part-2: Authentication Foundations

Renzo Diaz — Wed, 13 May 2026 16:44:18 +0000

Hey folks 👋

Welcome back. In Part 1 we walked through the 11 attack vectors that shape every decision in this series. If you skipped it, please go read it first, because everything we do from now on is a direct response to one of those threats. Without that context, the code below is just another tutorial.

In this part we are going to start writing the API. By the end you will have a Rails 8 project with user registration, login, and token-based authentication using OAuth2 + JWT, with tokens stored safely in HttpOnly cookies instead of localStorage.

I want to be honest about something. When I first built this, I tried to do "everything at once". I added authentication, authorization, rate limiting, and serializers in the same commit, and I got lost. So in this series we are going slow on purpose. Part 2 is only about laying the foundation correctly. We will not finish every mitigation today, and that's fine.

To help us stay oriented, I'll keep a small progress tracker at the end of each post.

What we are building in Part 2

A small Rails 8 API with:

A User model with hashed passwords (no plain text, ever)
OAuth2 password grant flow so the client can exchange email + password for a token
JWT access tokens that the server can verify without hitting the database
Refresh tokens with short-lived access tokens
Tokens delivered through encrypted HttpOnly cookies, not JSON bodies the frontend has to store manually

If you've never touched Devise or Doorkeeper before, don't worry. I'll explain why we use each piece, not just how.

Prerequisites

Ruby on Rails 8
PostgreSQL 14+
Postman, Insomnia, or curl for testing

Step 1. Create the project in API mode

Rails has a built-in flag to skip all the browser-only middleware (cookies are gone by default, ERB views are gone, asset pipeline is gone). That's what we want for an API.

rails new secure_api_auth -T -d postgresql --api

Breaking that down:

-T skips the default test suite (we'll set up testing later in the series)
-d postgresql uses Postgres instead of SQLite
--api strips out browser-oriented middleware

Then:

cd secure_api_auth

Tip from experience: commit right here as "Initial commit" before you change anything. When something breaks two hours from now, having a clean baseline to git diff against will save you.

Step 2. Add the gems we need

Open your Gemfile and add:

# Database
gem 'pg'

# Password hashing
gem 'bcrypt', '~> 3.1.7'

# Authentication & Authorization
gem 'devise'
gem 'doorkeeper'
gem 'doorkeeper-jwt'

Then:

bundle install

A quick mental model before we go further, because these three gems confused me for a long time:

Devise owns the user identity. It knows how to store a user, hash a password, and verify "is this the right password for this email?"
Doorkeeper owns the access decision. After Devise confirms who you are, Doorkeeper issues the token that proves you are allowed to call the API.
doorkeeper-jwt changes the format of that token from a random string to a JWT, so the server can verify it without a database lookup.

In other words: Devise checks the ID at the door, Doorkeeper hands you the wristband, and JWT is what the wristband is made of.

Step 3. Install Devise

bin/rails generate devise:install

Devise will print a few setup instructions. Since we're API-only, we only care about one of them: setting the default URL options for development.

Open config/environments/development.rb and add:

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }

We won't be sending real emails in this tutorial, but Devise complains if this isn't set.

Generate the User model

bin/rails generate devise User
bin/rails db:migrate

This creates a users table with an encrypted_password column (and a few others for tracking sign-in counts and lockouts).

🛡️ Mitigation in action: Token Theft and Password Breaches (Part 1, vectors 4 and 10)

Devise hashes passwords with bcrypt, which is intentionally slow. Even if an attacker dumps your database, they can't reverse the hashes. Each password also gets a unique salt, so two users who pick the same password end up with completely different hashes. This is why we never, ever store passwords in plain text.

Switch Devise to API mode

By default Devise wants to redirect users to HTML pages after login. We need to turn that off.

Open config/initializers/devise.rb and add (or modify) these two lines:

Devise.setup do |config|
  # ... keep everything else as generated ...

  # Don't use session storage for API authentication
  config.skip_session_storage = [:http_auth, :params_auth]

  # No HTML redirects, we return JSON
  config.navigational_formats = []
end

Step 4. Install Doorkeeper

bin/rails generate doorkeeper:install
bin/rails generate doorkeeper:migration

Before we run that migration, we need to edit it. Doorkeeper is built for the full OAuth2 flow (the one where you click "Log in with GitHub" and get redirected). We don't need that. We need the simpler password grant flow, where the client sends email + password directly and gets a token back. That requires loosening two null: false constraints.

Open the generated migration file (something like db/migrate/XXXXX_create_doorkeeper_tables.rb):

# In the oauth_applications table: allow null redirect_uri
t.text :redirect_uri  # remove the `null: false`

# In the oauth_access_tokens table: allow null application reference
t.references :application  # remove the `null: false`

# At the bottom of the file, link tokens back to users
add_foreign_key :oauth_access_grants, :users, column: :resource_owner_id
add_foreign_key :oauth_access_tokens, :users, column: :resource_owner_id

Then migrate:

bin/rails db:migrate

A word on the password grant flow. The OAuth2 spec actually discourages this flow for third-party clients, because it requires the client to handle the user's raw password. But for first-party clients (your own mobile app, your own SPA), it's perfectly reasonable, and it's what most "log in with email and password" APIs do under the hood. The key word is first-party: you control both ends.

Step 5. Re-enable cookies in API mode

This is the part that surprised me the first time. When you pass --api to rails new, Rails removes the cookie middleware. That makes sense, an API doesn't usually need cookies. But we do want them, because we want to store the access token in an HttpOnly cookie instead of letting JavaScript handle it.

Open config/application.rb:

module SecureApiAuth
  class Application < Rails::Application
    config.load_defaults 8.0
    config.api_only = true

    # Re-add cookie middleware so we can use HttpOnly cookie auth
    config.middleware.use ActionDispatch::Cookies
    config.middleware.use ActionDispatch::Session::CookieStore,
                          key: '_secure_api_session',
                          same_site: :lax,
                          secure: Rails.env.production?
  end
end

🛡️ Mitigation in action: XSS and Token Theft (Part 1, vectors 1 and 10)

This is the single most important decision in this whole post. If you store a JWT in localStorage, any piece of JavaScript that runs on your page can read it. One XSS bug, one compromised npm dependency, one browser extension, and the token is gone.

HttpOnly cookies are invisible to JavaScript. The browser sends them automatically with every request, but document.cookie will not show them. Secure ensures the cookie is only sent over HTTPS. SameSite=Lax is our first line of defense against CSRF (which we'll fully address in a later part).

Step 6. Teach Doorkeeper to read tokens from the cookie

Out of the box, Doorkeeper looks for tokens in the Authorization: Bearer ... header. We need to add a new place for it to look: our encrypted cookie.

Create lib/doorkeeper/from_cookie.rb:

module Doorkeeper
  module FromCookie
    module_function

    def call(request)
      # Read the encrypted access token from the HttpOnly cookie
      request.cookie_jar.encrypted[:access_token]
    end
  end
end

Why encrypted and not just signed?

Rails offers two protected cookie jars: signed (tamper-proof but readable) and encrypted (tamper-proof AND unreadable). If someone opens DevTools and copies the raw cookie value, with signed they'd see the JWT in plain text. With encrypted they see AES-256 garbage. The JWT is already protected by its own signature, but defense in depth is cheap here, so we use encrypted.

Step 7. Configure Doorkeeper

Open config/initializers/doorkeeper.rb and replace the generated content with:

# frozen_string_literal: true

require_relative '../../lib/doorkeeper/from_cookie'

Doorkeeper.configure do
  orm :active_record
  api_only

  # Resource Owner Password Credentials grant.
  # Lets users log in with email + password directly.
  grant_flows %w[password]
  allow_blank_redirect_uri true

  # How to find the user when they log in.
  resource_owner_from_credentials do |_routes|
    user = User.find_for_database_authentication(email: params[:email])
    user if user&.valid_password?(params[:password])
  end

  skip_client_authentication_for_password_grant true

  # Short-lived access tokens.
  access_token_expires_in 15.minutes

  # Enable refresh tokens.
  use_refresh_token

  # Use JWT format for access tokens.
  access_token_generator 'Doorkeeper::JWT'

  # Scopes. We'll use these later for authorization.
  default_scopes :read
  optional_scopes :write, :admin

  base_controller 'ApplicationController'

  # Token lookup order: 1) our cookie, 2) Bearer header, 3) query param.
  access_token_methods Doorkeeper::FromCookie,
                       :from_bearer_authorization,
                       :from_access_token_param
end

A few of these settings deserve a closer look:

access_token_expires_in 15.minutes is intentional. If a token leaks, the attacker only has 15 minutes before it stops working. The refresh token (which lives longer) covers the user experience side, so they don't have to log in every 15 minutes.

use_refresh_token enables the rotation pattern: when an access token expires, the client uses a refresh token to get a new one without prompting the user. We'll wire up rotation more carefully in a later part.

access_token_methods order matters here. Doorkeeper checks the cookie first, then the Authorization header, then a query parameter. In production I'd actually remove from_access_token_param because tokens in URLs end up in server logs and browser history (Part 1, vector 10). For now I'm leaving it in so you can test easily with curl, but treat it as a TODO.

🛡️ Mitigation in action: Token Theft (Part 1, vector 10)

Short access token lifetime plus refresh token rotation is the standard pattern for limiting blast radius when a token leaks. We'll harden this further by adding revocation when we build the /logout endpoint.

Step 8. Configure the JWT payload

Create config/initializers/doorkeeper_jwt.rb:

Doorkeeper::JWT.configure do
  # Sign tokens with HS256 using the app's secret key.
  secret_key Rails.application.credentials.secret_key_base
  signing_method :hs256

  token_payload do |opts|
    user = User.find(opts[:resource_owner_id])

    {
      iat: Time.current.to_i,                        # Issued at
      exp: (Time.current + opts[:expires_in]).to_i,  # Expires at
      jti: SecureRandom.uuid,                        # Unique token ID
      sub: user.id,                                  # Subject (user ID)
      email: user.email,
      scopes: opts[:scopes]
    }
  end

  secret_key_path nil
  use_application_secret false
end

If you've never seen a JWT before, here's the short version. A JWT is three base64-encoded parts joined by dots:

header.payload.signature

The header says how the token is signed. The payload is the JSON we just defined above (user ID, email, expiry, etc). The signature is a hash of header.payload combined with our secret key. If an attacker changes anything in the payload, the signature won't match anymore and the token is rejected.

The jti (JWT ID) is worth flagging. It's a unique ID per token, which we'll use later when we implement token revocation. You "blacklist" the jti instead of trying to delete the JWT itself (you can't, the client has it).

Where we are right now

We have a Rails 8 API with a User model, password hashing, OAuth2 password grant, JWT access tokens, refresh tokens, and HttpOnly cookie storage. That's a solid foundation.

But we have not written the controllers yet (register, login, logout, refresh, "who am I"). That's coming in Part 3, along with the first set of mitigations that depend on having endpoints to protect.

Progress tracker: security vectors from Part 1

I'll keep this table updated in every part so you can see exactly what's covered and what's still pending.

#	Attack vector	Status	Where
1	XSS	🟡 Partially mitigated	`HttpOnly` cookie storage (Step 5). Full content sanitization is a frontend concern.
2	SQL Injection	🟢 Mitigated by default	Active Record's `find_by`, `where`, etc. We'll still review controllers in Part 3.
3	CSRF	🔴 Not yet	`SameSite=Lax` is set, but we need explicit CSRF tokens for cookie auth. Part 3.
4	Brute Force	🟡 Partially mitigated	bcrypt slows password cracking. Rate limiting with `Rack::Attack` comes in Part 4.
5	User Enumeration	🔴 Not yet	We need to design login/reset responses to be uniform. Part 3.
6	IDOR	🔴 Not yet	Will be addressed when we add resources + Pundit/Sqids. Part 5.
7	Mass Assignment	🔴 Not yet	Strong params, controller by controller. Part 3.
8	Excessive Data Exposure	🔴 Not yet	Serializers (JSON:API or `alba`). Part 3.
9	MITM	🟡 Partially mitigated	`secure: true` on cookies in production. `force_ssl` and HSTS come in Part 4.
10	Token Theft	🟢 Mostly mitigated	`HttpOnly` + encrypted cookies + short-lived tokens + refresh tokens. Revocation in Part 3.
11	Verbose Error Messages	🔴 Not yet	Production error handling. Part 4.

Legend: 🟢 Covered, 🟡 Partial, 🔴 Pending

Coming up in Part 3

We'll build the actual auth controllers (register, login, logout, refresh, and me), and while we do it we'll knock out four more vectors from the tracker: CSRF, User Enumeration, Mass Assignment, and Excessive Data Exposure.

If this helped you, follow along so you don't miss it. And if anything is unclear, drop a comment, I read all of them.

Build a Secure API with Rails 8 - Part-1

Renzo Diaz — Wed, 06 May 2026 23:14:19 +0000

Hi folks👋!

In this post I want to share something I wish I had when I started building APIs with Ruby on Rails: a practical guide that takes security seriously from the beginning.

When I built my first REST API, most tutorials I found were focused on getting something running quickly. They were great for learning the basics, but they usually skipped important topics like API versioning, authentication strategy, authorization, and security.

Even when using AI tools to generate a “secure API”, the result is often still insecure unless you already understand the threats you are trying to protect against. Security is not something you get automatically. You need to know what problems you are solving and why the protections matter.

I ended up reading API design books, OWASP documentation, and real-world breach reports before I finally felt like I understood what I was building, I've put all in practice. This post is the guide I wish I had back then.

In this series we are going to build a production-ready Rails 8 API with authentication, authorization, rate limiting, secure cookies, security headers, and other important protections. I also want to explain the reasoning behind each decision, not just copy-paste code without context.

Before writing any code, let’s first understand the main attack vectors we need to defend against.

The attack vectors we are defending against

1. XSS (Cross-Site Scripting)

🚨 Threat:
XSS happens when an attacker injects malicious JavaScript into content that later gets rendered in another user’s browser. In API-driven applications, one of the biggest risks is token theft. If JWTs are stored in localStorage, a malicious script can read and steal them immediately.

🛡️ Mitigation:
Avoid storing authentication tokens in localStorage or other browser-accessible storage. Instead, store them in secure HttpOnly cookies so JavaScript cannot access them. Cookies should also use the Secure and SameSite attributes. Any user-generated content rendered in the frontend should be properly escaped or sanitized.

2. SQL Injection

🚨 Threat:
SQL Injection happens when user input is inserted directly into a SQL query without proper sanitization. An attacker can manipulate the query to bypass authentication, read sensitive data, or modify the database.

🛡️ Mitigation:
Avoid interpolating user input directly into SQL queries. In Rails, prefer Active Record methods like where, find_by, and parameterized queries, which automatically sanitize input. If raw SQL is unavoidable, use bound parameters instead of string interpolation. You should also validate input, use strong parameters, and follow the principle of least privilege for database accounts.

3. CSRF (Cross-Site Request Forgery)

🚨 Threat:
CSRF happens when a malicious website tricks a logged-in user’s browser into sending authenticated requests to your application using automatically attached cookies.

This is especially important in Rails APIs using session cookies or JWTs stored in HttpOnly cookies. Even though JavaScript cannot read those cookies, the browser still sends them automatically with requests.

An attacker could potentially trigger actions like changing account settings, creating resources, or deleting data without the user realizing it.

🛡️ Mitigation:
Enable CSRF protection for any cookie-based authentication flow. In Rails, use protect_from_forgery and require valid CSRF tokens for state-changing requests like POST, PUT, PATCH, and DELETE.

Authentication cookies should also use:

HttpOnly
Secure
SameSite=Lax or SameSite=Strict

You should also validate Origin and Referer headers and keep CORS restricted to trusted frontend domains.

If the browser automatically sends authentication, CSRF protection still matters, even if the API itself is technically stateless.

4. Brute Force

🚨 Threat:
Brute force attacks happen when an attacker repeatedly tries large numbers of username and password combinations against your login endpoint.

This commonly targets login forms, password reset endpoints, and authentication APIs. Successful attacks can lead to account compromise, credential stuffing, and unnecessary server load.

🛡️ Mitigation:
Use rate limiting on authentication-related endpoints. In Rails, tools like Rack::Attack can throttle repeated requests by IP address, email, or both.

You should also:

temporarily lock accounts after repeated failures
require strong passwords
detect suspicious login activity
avoid revealing whether an account exists
consider CAPTCHA or step-up verification after suspicious behavior

5. User Enumeration

🚨 Threat:
User enumeration happens when an application reveals whether an account exists through different error messages.

For example:

“Email not found”
“Incorrect password”

An attacker can use these differences to discover valid accounts and later target them with brute force attacks, phishing, or credential stuffing.

🛡️ Mitigation:
Return consistent responses during login, password reset, and account recovery flows.

Instead of exposing whether the email exists, use generic responses such as:

“Invalid credentials”
“If an account exists, instructions have been sent”

You should also rate limit these endpoints and monitor repeated probing attempts.

6. IDOR (Insecure Direct Object Reference)

🚨 Threat:
IDOR happens when users can access resources they do not own by changing identifiers in URLs or request parameters.

For example:


User.find(params[:id])

If ownership checks are missing, changing /users/42 to /users/43 could expose another user’s data.

🛡️ Mitigation:
Always scope records through the authenticated user or an authorization policy.

Instead of:


Post.find(params[:id])

Prefer:


current_user.posts.find(params[:id])

Authorization libraries like Pundit or CanCanCan also help enforce access rules consistently across the application. I also avoid exposing raw database IDs directly to the frontend. Instead, I use Sqidsto generate less predictable public IDs, which helps reduce simple enumeration attacks.

7. Mass Assignment

🚨 Threat:
Mass assignment happens when the application accepts user input and blindly assigns it to model attributes.

An attacker could submit unexpected fields such as:


{

  "admin": true

}

If those fields are not filtered properly, the attacker may gain elevated privileges or modify protected data.

🛡️ Mitigation:
Use strong parameters in every controller.

In Rails, always whitelist allowed attributes using:


params.require(:user).permit(:email, :password)

Never pass raw params directly into create or update.

Sensitive fields like roles, permissions, ownership fields, or account status flags should never be user-assignable.

8. Excessive Data Exposure

🚨 Threat:
Excessive data exposure happens when an API returns more information than the client actually needs.

This often happens when entire Active Record objects are rendered directly into JSON responses.

Sensitive data such as password digests, internal IDs, permissions, API keys, or private metadata may accidentally leak through the API.

🛡️ Mitigation:
Only return the fields the client actually needs.

Instead of blindly rendering full objects:


render json: @user

Use serializers or custom JSON responses that explicitly define safe attributes.

Sensitive fields should never appear in API responses.

You should also regularly review serialized responses to make sure no internal data is leaking unintentionally.

9. MITM (Man-in-the-Middle)

🚨 Threat:
A Man-in-the-Middle attack happens when an attacker intercepts traffic between the client and server.

Without HTTPS, credentials, tokens, cookies, and other sensitive data can travel in plain text and be stolen or modified.

Attackers on the same network, malicious proxies, or compromised routers can hijack sessions or impersonate users.

🛡️ Mitigation:
Always enforce HTTPS.

In Rails, enable:


config.force_ssl = true

This redirects insecure requests and ensures cookies are only sent over encrypted connections.

Authentication cookies should also use the Secure and HttpOnly flags.

You should additionally enable HSTS headers and avoid loading insecure mixed-content resources.

10. Token Theft

🚨 Threat:
Token theft happens when an attacker gains access to a valid authentication token and uses it to impersonate a user.

Stolen JWTs can come from XSS attacks, insecure storage, leaked logs, browser extensions, compromised devices, or intercepted traffic.

If tokens remain valid for a long time, the attacker may keep access even after the user notices something is wrong.

🛡️ Mitigation:
Reduce token exposure and keep token lifetimes short.

Prefer storing tokens in secure HttpOnly cookies instead of localStorage.

Use:

short-lived access tokens
refresh token rotation
token revocation mechanisms

You should also avoid exposing tokens in logs or URLs and protect the application against XSS vulnerabilities.

11. Verbose Error Messages

🚨 Threat:
Verbose error messages expose internal application details to attackers.

Stack traces, database errors, framework versions, SQL queries, and file paths can all help attackers understand how the system works and make exploitation easier.

🛡️ Mitigation:
Production applications should return generic and safe error responses.

Instead of exposing internal exceptions, return messages such as:

Internal Server Error
Invalid request

Detailed errors should only be logged internally for debugging.

In Rails, make sure debug pages and detailed exceptions are disabled in production.

Final Thoughts

These are some of the most important security risks to think about when building APIs, and we will revisit them throughout this series as we implement each feature step by step.

In Part 2 we will start building the Rails 8 API from scratch and set up the project foundation correctly from the beginning, including authentication, secure configuration, and API structure.

Follow along if you want to get notified when the next part is published.

What are my day-to-day tools as a full-stack developer?

Renzo Diaz — Sat, 20 Jun 2020 00:26:50 +0000

I've divided a list of tools that I use every day working as a full-stack developer by category.

Design

Graphic link:

I can't afford Illustrator monthly so I found this alternative, I paid once and it worth all. I can edit vectors, AI files, export everything that you can do with Illustrator.

SketchApp link:

When it comes to design mockups I use Sketch, it has a friendly interface that makes it easy to design.

Zeplin link:

If you are developing an application you should have quick access to the mockup assets like images, colors, icons, etc. Zeplin is a design collaboration tool that allows uploading your mockups to the cloud you all the development team can access them quickly and easily.

Development

Iterm2 link

An alternative to default terminal on macOS

Vim link

I use Vim as the code editor, I've customized shortcuts and plugins for fast development.

Docker link

Docker to containerize my apps

Xcodelink

When I need to develop an IOS app I use Xcode with Swift.

TMUX link

When I'm developing a web application I need quick access to different terminals, for example, to run a server, to use my Vim editor all in just one terminal in a single session.

Homebrew link

A package manager for macOS.

Repl link

Sometimes I need to write quick methods to see what returns on the console.

Services

Gitlab link

I'm a fan of Gitlab, private repositories, CI/CD and you can also use the community edition to install in your own server.

HEROKU link

Where I deploy my personal projects.

AWS S3 link

When I'm working on a big application I store the resources in a bucket in AWS S3, and when I need to create a CDN as well.

PivotalTracker link

Every developer should use a tool to track progress on the development or specific task, I use PivotalTracker for big projects and Gitlab board for small.

Utilities

1Password: My generate and store passwords.
Boostnote: Save my snippets or documentation.
Workspace: I organize my apps in workspaces, so I can access them in one click.
Toggle Alfred: Enhanced spotlight in mac.
ExpressVPN: A VPN to navigate safely.

I'm not a Rich guy that can afford a Mac, I use a Mac because I feel more comfortable work design, develop Web and iOS applications. I work for years to get a MacBook 2017 before I used to go to my university to use design tools.

I would appreciate it if you can share the tools you use in your day-to-day.

Have a nice day!

How to use ULID as primary key Rails

Renzo Diaz — Thu, 21 May 2020 19:54:29 +0000

A short story

Ruby on Rails is a powerful framework it is easy to create APIs and fast website development, one thing that came when I was developing an API was how to change the Integer auto-increment primary key because having a predictable Id can be risky in terms of security if you share it for a client-size application, the user can guess ids and modify the database in the worst of the case, at that moment I had to research some alternatives and I found UUID a non-sequential data type that can be easily be implemented in Rails, so I've tried it and everything was ok until I had to sort ASC and DESC, I realize that the methods Model.first and Model.last doesn't work as expected because Rails by default uses them with the integer sequential id type, so as UUID is non-sequential it generates a random Hash like this 123e4567-e89b-12d3-a456-426614174000 as it doesn't have a sequence Rails can't figure out how to sort the data, then I researched a little bit more to see if there is any other solution and I found that we can use self.implicit_order_column = "created_at" in the Model, with this, those methods work ok it sorts depending on the DateTime created and I was happy. Not for a long time, when another problem came up! When I used seeds to fill a bulk of fake data into the database, all the data had the same DateTime and the sorting failed again, it was the same issue as the initial one. I've decided to look for another alternative and I found ULID, using this I had everything I've needed the sorting works as expected, it isn't predictable and the store in memory is pretty good. I'm still using it and I don't have any issues.

How to implement ULID in Rails?

There is already a gem for ruby add it to your Gemfile

#Gemfile
...
  gem 'ulid'
end

Then run bundle install to install it. Then update your migration or if you are creating a new one should look like this.

# migration
class CreateUsers < ActiveRecord::Migration[6.0]
  def change
   # id: false, to not use id int as default
   create_table :users, id: false do |t|
     # here we create our id
     t.binary :id, limit: 16, primary_key: true

     t.string :given_name
     t.string :family_name
     t.string :email, unique: true, index: true
     t.string :username, unique: true, index: true
     t.string :password_digest
     ...
     t.timestamps
   end
  end
end

First, we disable the autogenerated id by putting id: false and create our own id t.binary :id, limit: 16, primary_key: true what we need to do is fill the id before create, we can do it on each Model but my approach was to create a concern to just include it in the application_record.rb file so it will apply for all the models.

# app/models/concenrs/ulid_pk.rb
require 'ulid'

module UlidPk
  extend ActiveSupport::Concern

  included do
    before_create :set_ulid
  end

  def set_ulid
    self.id = ULID.generate
  end
end

Then in the application_record.rb include it.

# app/models/concenrs/ulid_pk.rb
class ApplicationRecord < ActiveRecord::Base
  include UlidPk
  self.abstract_class = true
end

That's it, now it will autogenerate the id before create.

Note

if you need to create an association you should put the type on it.

# migration
class CreateEvents < ActiveRecord::Migration[6.0]
  def change
   # id: false, to not use id int as default
   create_table :users, id: false do |t|
     # here we create our id
     t.binary :id, limit: 16, primary_key: true

     t.string :name
     t.string :description
     ...
     # Specify the type: binary
     t.references :user, type: :binary, foreign_key: true, index: true

     t.timestamps
   end
  end
end

Hope this can help you, I'll try to make it more autogenerated when I get the chance to avoid put type: :binary or id: false manually. If you have any question feel free to reach me out. Cheers!

How to Architect Rails Project - Part 2

Renzo Diaz — Sun, 08 Dec 2019 21:15:59 +0000

In the previous article, we've done setting up our Surface module
How to Architect Rails Project - Part 1

In this article, we'll cover the following features:

Module Admin
Layouts
Front-End Scaffolding

So, let's kick off...

For our Admin module, we want to get these routes

'domain.com/admins' # Overview, basic reports, charts
'domain.com/admins/blog' # Articles CRUD
'domain.com/admins/work' # Work CRUD

Let's add them to our routes.

# config/routes.rb
Rails.application.routes.draw do
  ...
  namespace :admins do
    resources :blogs
    resources :works
  end
end

Why admins and not admin in singular? Because this module was thought to have multiple user types, users that only can publish articles and won't have permissions to publish works.

Moving on, we need to create the views for our Admin module according to our routes.

Create these files inside app/views folder

app/views
  ├── admins/blogs
  │   └── index.html.erb
  │   └── show.html.erb
  ├── admins/works
  │   └── index.html.erb
  │   └── show.html.erb
  └── layouts 
      └── admin.html.erb

Let's add our markup to admin.html.erb layout, for now, let's copy the content from application.html.erb. Our layout would look like this...

<!DOCTYPE html>
<html>
  <head>
    <title>Portfolio</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>
  <body>
    <%= render "partials/header" %>
    <%= yield %>
  </body>
</html>

Cool right? We have our Admin layout.

Hold on your horses... We are still using the assets from our Surface module (application), we want to isolate Admin/Surface and make them to not depend on each other, so, let's isolate our Admin assets out of the Surface module.

Create these files under app/assets/stylesheets...

app/assets/stylesheets
  ├── admin/base
  │   └── _base.scss
  │   └── _variables.scss
  ├── admin/components
  │   └── _header.scss
  │   └── _sidebar.scss
  └── admin.scss

So our admin.scss would look like this...

// Base theming
@import "admin/base/variables";
@import "admin/base/base";

// Components
@import "admin/components/header";
@import "admin/components/sidebar";

Next, add this line to our base_controller.rb under controller/admins folder

class Admins::BaseController < ApplicationController
  layout 'admin'
end

We need also to tell rails that we want to use admin.css|admin.js in our initializer, so add the following line to config/initializers/assets.rb

Rails.application.config.assets.precompile += %w( admin.js admin.css )

Now let's change our admin.html.erb layout to use admin.css and remove the current header stylesheet which comes from the Surface module.

<!DOCTYPE html>
<html>
  <head>
    <title>Portfolio</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'admin', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>
  <body>
    <%= yield %>
  </body>
</html>

Well done! now if we run rails s and navigate to http://localhost:3000/admins/blogs we should see a blank page. If we inspect elements in the browser we'll see that our styles are coming from admin and not application anymore.

Alright, Renzo, this is cool but I don't see any component and styles on the page yet. Besides the javascript still comes from the Surface module.

Before deep into the components and styles, let's add an Admin module for our javascript files, this is pretty much the same as what we did with styles.

So, let's create an admin.js file under app/javascript/packs folder and add the following lines...

// app/javascript/packs/admin.js
require("@rails/ujs").start()
require("turbolinks").start()
require("@rails/activestorage").start()

Change <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %> to <%= javascript_pack_tag 'admin', 'data-turbolinks-track': 'reload' %> in our admin.html.erb layout

<!DOCTYPE html>
<html>
  <head>
    <title>Portfolio</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'admin', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'admin', 'data-turbolinks-track': 'reload' %>
  </head>
  <body>
    <%= yield %>
  </body>
</html>

Let's restart our server and see what we got, we should see the same blank page if we navigate to http://localhost:3000/admins/blogs. If we inspect the page we'll see that now our javascript comes from admin.

Now we have our js/css isolated from the Surface module, let's add Bulma to our project and start building our components.

Add Bulma gem to our Gemfile at the bottom

gem "bulma-rails", "~> 0.8.0"

Then run bundle install in the terminal.

In this article we are going to use Bulma in both modules Surface/Admin, just to not make this article too long. Remember that we can also isolate to use Bulma for the Admin and any other framework for our Surface.

Now let's build our layout markup correctly for the Admin module.

<!Doctype html>
<html>
...
  <body>
    <%= render "patials/admin/header" %>
    <div class="columns is-fullheight">
      <div class="column is-2 is-sidebar-menu is-hidden-mobile">
        <%= render "partials/admin/sidebar" %>
      </div>
      <div class="column is-main-content">
        <%= yield %>
      </div>
    </div>
  </body>
</html>

Create a admin folder under app/views/partials add these files...

app/views/partials/admin/_header.html.erb

<nav class="navbar">
  <div class="navbar-brand">
    <a class="navbar-item" href="#">
      Logo
    </a> 
    <div class="navbar-burger burger" data-target="navMenubd-example">
      <span></span>
      <span></span>
      <span></span>
    </div>
  </div>

  <div id="navMenubd-example" class="navbar-menu">
    <div class="navbar-start">
    </div>

    <div class="navbar-end">
      <div class="navbar-item has-dropdown is-hoverable">
        <a class="navbar-link">
          <figure class="avatar image is-32x32">
            <img class="is-rounded" src="https://bulma.io/images/placeholders/32x32.png" alt=""/>
          </figure>
          username
        </a>

        <div class="navbar-dropdown is-right">
          <a class="navbar-item">
            Logout
          </a>
        </div>
      </div>
    </div>
  </div>
</nav>

app/views/partials/admin/_sidebar.html.erb

<aside class="menu">
  <p class="menu-label">
    General
  </p>
  <ul class="menu-list">
    <li><%= link_to 'Overview', admins_blogs_path %></li>
  </ul>
  <p class="menu-label">
    Administration
  </p>
  <ul class="menu-list">
    <li>
      <%= link_to 'My Work', admins_works_path %>
    </li>
    <li><%= link_to 'My Work', admins_blogs_path %></li>
    <li><a>Users</a></li>
  </ul>
</aside>

Add some styles

app/assets/stylesheets/admin/base/_variables.scss

$body-size: 16px !default;

// Responsiveness
// 960, 1152, and 1344 have been chosen because they are divisible by both 12 and 16
$tablet: 769px !default;
// 960px container + 40px;
$desktop: 1000px !default;
// 1152px container + 40;
$widescreen: 1192px !default;
// 1344px container + 40;
$fullhd: 1384px !default;

$white: #fff !default;
$orange: hsl(17, 83%, 57%);
$primary: $orange !default;
$primary-invert: $white !default;

// Link colors
$link: $primary !default;
$link-invert: $white !default;
$navbar-height: 3.25rem;

app/assets/stylesheets/admin/base/_base.scss

body {
    overflow-x: hidden;
}
.columns {
    &.is-fullheight {
        min-height: calc(100vh - ( #{$navbar-height} - .75rem ) );
        max-height: calc(100vh - ( #{$navbar-height} - .75rem ) );
        height: calc(100vh - ( #{$navbar-height} - .75rem ) );
        display: flex;
        flex-direction: row;
        justify-content: stretch;

        .column {
            overflow-y: auto;
        }
    }
}    
.is-main-content {
    background: $grey-lighter;
    padding: 1rem  2.5rem 1rem 2rem;
}

app/assets/stylesheets/admin/components/_sidebar.scss

.is-sidebar-menu {
    padding: 2.5rem;
    background: $grey-dark;
    li {
        a {
            color: $white;
        }
    }
}

app/assets/stylesheets/admin/components/_header.scss

.navbar {
    .navbar-item {
        .avatar {
            margin-right: .65rem;
            .is-rounded {
                max-height: 100%;
            }
        }
    }
}

Alright, if we restart our browser at this point and navigate to http://localhost:3000/admins/blogs our dashboard should look like this.

If you got any error through this setup, feel free to drop me a line dev.renzo.diaz@gmail.com I’ll try to answer all your doubts asap.

In part 1 of this article, I mentioned this part 2 will cover CRUDS and Authentication, and React as well.

We'll, we will cover those points in part3, I don't want to make this article too long and don't mix with Rails back-end stuff.

How to Architect Rails Project - Part 1

Renzo Diaz — Wed, 04 Dec 2019 16:31:57 +0000

When I started to build web applications with ruby on rails, I had a lot of questions that I figured out through the years of using the framework. Now in this article, I’m going to share the base structure to start building a web application.

Depending on the requirements our structure could slightly change, in this scenario, I’m going to build a simple portfolio app with a blog of articles.

Before start building our project, let’s imagine two layers one to administrate the site and the other for public access (front pages). Here is how it should look.

Admin (Dashboard):
Only admin users have access and permissions to post articles, add portfolio jobs, see reports, etc.
There are many ways to build modules, for example using ActiveAdmin gem we can crate the admin module, another way is creating engines, but we are going to set up our dashboard module from scratch.

Surface (front pages):
In this module, we’ll put all the public pages like home, about, portfolio, blog, and contact.
Once we have clear this concept, let’s kick-off creating or project…

rails new portfolio -d postgresql -T

-T = skip testing modules. We’ll focus on test and design in other article

Move under the Portfolio directory and run the following commands to create the database and migrations…

rails db:create
rails db:migrate

Until here, we have a clean project with no custom pages or modules. So, let’s start creating our project architecture.
First, under controllers create 2 folders called (admins, surface). Our tree would look like this.

app/controllers
  ├── admins
  └── surface
  └── application_controller.rb

Create these controllers under admins and surface folders base_controller.rb, blogs_controller.rb, works_controller.rb and pages_controller.rb

app/controllers
  ├── admins # Portfolio blog and work management
  │   └── base_controller.rb
  |   └── blogs_controller.rb
  |   └── works_controller.rb
  └── surface # Public pages
  │   └── pages_controller.rb
  └── application.rb

Let’s add some code to our admin controllers…

# admins/base_controller.rb
class Admins::BaseController < ApplicationController
  # Define what users can access to this module
  # Define what view layout to use 
end

#admins/works_controller.rb
# here we are extending from our Admins::BaseControler
class Admins::WorksController < Admins::BaseController
end

# admins/blogs_controllers
# Inherits from Admins::BaseController
class Admins::BlogsController < Admins::BaseController
end

Let’s add some code to our surface controller…

# surface/pages_controller.rb
class Surface::PagesController < ApplicationController
  #define our pages
  def home
  end

  def about
  end
  def work
  end

  def blog
  end

  def contact
  end
end

Next, we are going to add some routes to our app un config/routes.rb.

Rails.application.draw do
  # Define our root page
  root to: 'surface/pages#home'

  # Frontend pages

  # scope module 'surface' to get this format url `domain.com/about, domain.com/work...` 
  # and not `domain.com/surface/about...`
  scope module: 'surface' do
    get '/about', to: 'pages#about', as: 'surface_about'
    get '/work', to: 'pages#work', as: 'surface_work'
    get '/blog', to: 'pages#blog', as: 'surface_blog'
    get '/contact', to: 'pages#contact', as: 'surface_contact'
  end
end

These routes also can be isolated in files, we’ll isolate these routes in the next article.

Now, we should create our views according to our modules, let’s focus first in our Surface module, so let’s create the following folders and views.

app/views
  ├── surface/pages # Write in each file <h1>Page Name</h1> 
  │   └── home.html.erb     # I.e <h1>Home</h1>
  │   └── about.html.erb    # I.e <h1>About</h1>
  |   └── work.html.erb     # I.e <h1>Work</h1>
  |   └── blog.html.erb     # I.e <h1>Blog</h1>
  |   └── contact.html.erb  # I.e <h1>Contact</h1>
  └── partials   
  │   └── _header.html.erb
  |   └── _footer.html.erb
  └── layouts 
  |   └── application.html.erb

Now let’s edit application.html.erb under the layout folder and add the header and footer partials.

Partials are the components that will be used across the site.

Let’s add some Html links to our _header.html.erb under the partials folder...

<header>
  <h1>Logo</h1>
  <nav>
    <ul>
      <li><%= link_to 'Home', root_path %></li>
      <li><%= link_to 'About', surface_about_path %></li>
      <li><%= link_to 'Work', surface_work_path %></li>
      <li><%= link_to 'Blog', surface_blog_path %></li>
      <li><%= link_to 'Contact', surface_contact_path %></li>
    </ul>
  </nav>
</header>

Next, add the header partial to our layout applicaton.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title>Portfolio</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>
  <body>
    <%= render "partials/header" %>
    <%= yield %>
  </body>
</html>

Alright! we have our surface module working perfectly 💯 if you go tho http://localhost:3000 you will be able to navigate between the pages.

If you got any error through this setup, feel free to drop me a line dev.renzo.diaz@gmail.com I’ll try to answer all your doubts asap.

In the next Part 2, will cover the admin module, authentication users, dashboard layout, CRUDS, and some of the front-end stuff.

Forem: Renzo Diaz

Build a Secure API with Rails 8 - Part-3: Auth Controllers

What we are building in Part 3

Step 1. Add Pundit and Rack-CORS

Step 2. Configure CORS

Step 3. Update ApplicationController

Step 4. Create the versioned BaseController

Step 5. SessionsController (login, logout, refresh)

Step 6. RegistrationsController

Step 7. UsersController and the me endpoint

Step 8. Wire up the routes

Step 9. Test with curl

Step 10. Rate limiting with Rack-Attack

Step 11. HTTP security headers with secure_headers

Step 12. Encrypt sensitive fields with Lockbox

Step 13. Structured logs with Lograge

Where we are right now

Progress tracker: security vectors from Part 1

Coming up in Part 4

Build a Secure API with Rails 8 - Part-2: Authentication Foundations

What we are building in Part 2

Prerequisites

Step 1. Create the project in API mode

Step 2. Add the gems we need

Step 3. Install Devise

Generate the User model

Switch Devise to API mode

Step 4. Install Doorkeeper

Step 5. Re-enable cookies in API mode

Step 6. Teach Doorkeeper to read tokens from the cookie

Step 7. Configure Doorkeeper

Step 8. Configure the JWT payload

Where we are right now

Progress tracker: security vectors from Part 1

Coming up in Part 3

Build a Secure API with Rails 8 - Part-1

The attack vectors we are defending against

1. XSS (Cross-Site Scripting)

2. SQL Injection

3. CSRF (Cross-Site Request Forgery)

4. Brute Force

5. User Enumeration

6. IDOR (Insecure Direct Object Reference)

7. Mass Assignment

8. Excessive Data Exposure

9. MITM (Man-in-the-Middle)

10. Token Theft

11. Verbose Error Messages

Final Thoughts

What are my day-to-day tools as a full-stack developer?

Design

Graphic link:

SketchApp link:

Zeplin link:

Development

Iterm2 link

Vim link

Docker link

Xcodelink

TMUX link

Homebrew link

Repl link

Services

Gitlab link

HEROKU link

AWS S3 link

PivotalTracker link

Utilities

How to use ULID as primary key Rails

A short story

How to implement ULID in Rails?

Note

How to Architect Rails Project - Part 2

How to Architect Rails Project - Part 1

Step 7. UsersController and the `me` endpoint