Ruby Yagi 🐐

Simplify loop using any?, all? and none?

2021-09-23T11:01:00+00:00

Ruby has some useful methods for enumerable (Array, Hash, etc), this post will talk about usage of any?, all?, and none?.

For examples used on this post, an Order model might have many Payment model (customer can pay order using split payments).

any?

To check if an order has any paid payments, a loop-based implementation might look like this :

has_paid_payment = false

order.payments.each do |payment|
  if payment.status == "paid"
    # one of the payment is paid
    has_paid_payment = true
    break
  end
end

if has_paid_payment
  # ...
end

We can simplify the code above using any? like this :

if order.payments.any?{ |payment| payment.status == 'paid'}
  # this will be executed if there is at least one paid payment
end

any? method can take in a block, and it will return true if the block ever returns a value that is not false or nil. (ie. true, or 123, or “abc”)

If no block is supplied, it will perform a self check for the elements:

order.payments.any?

# is equivalent to
order.payments.any? { |payment| payment }

all?

To check if all payments has been paid for an order, a loop-based implementation might look like this:

fully_paid = true

order.payments.each do |payment|
  if payment.status != "paid"
    # one of the payment is not paid, hence not fully paid
    fully_paid = false
    break
  end
end

if fully_paid
  # ...
end

We can simplify the code above using all? like this :

if order.payments.all?{ |payment| payment.status == 'paid'}
  # this will be executed if all payments are paid
end

all? method can take in a block, and it will return true if the block never returns a value that is false or nil for all of the elements.

If no block is supplied, it will perform a self check for the elements:

order.payments.all?

# is equivalent to
order.payments.all? { |payment| payment }

none?

This is the opposite of all?.

none? method accepts a block, and only returns true if the block never returns true for all elements.

if order.payments.none? { |payment| payment.status == 'paid' }
  # this will be executed if there is no paid payment for the order
end

If no block is supplied, it will perform a self check for the elements:

order.payments.none?

# is equivalent to
order.payments.none? { |payment| payment }

By utilizing any?, all? and none?, we can remove the usage of loop and make it more readable.

Reference

Ruby doc on enumeration

How to truncate long text and show read more / less button

2021-08-26T10:43:00+00:00

If you are working on an app that has user generated content (like blog posts, comments etc), there might be scenario where it is too long to display and it would make sense to truncate them and put a “read more” button below it.

This post will solely focus on the front end, which the web browser will detect if the text needs to be truncated, and only show read more / read less as needed. (dont show “read more” if the text is short enough)

TL;DR? Check out the Demo at CodePen.

Truncate text using CSS

Referenced from TailwindCSS/line-clamp plugin.

Using the combination of these CSS properties, we can truncate the text (eg: <p>...</p>) to the number of lines we want :

.line-clamp-4 {
  overflow: hidden;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  /* truncate to 4 lines */
  -webkit-line-clamp: 4;
}

If the text is longer than 4 lines, it will be truncated and will have ending of “…”. If the text is shorter than 4 lines, no changes is made.

Now that we managed to truncate the text, the next step is to check whether a text is truncated or not, as you can see, the short text above (second paragraph) is not truncated even if we have set webkit-line-clamp for it.

We want to check if the text is actually truncated so that we can show “read more” button for it (we dont need to show read more for short text that is not truncated).

Check if a text is truncated using offsetHeight and scrollHeight

There’s two attributes for HTML elements which we can use to check if the text is truncated, offsetHeight and scrollHeight. From Mozilla Dev Documentation,

offsetHeight :

is a measurement in pixels of the element’s CSS height, including any borders, padding, and horizontal scrollbars (if rendered).

scrollHeight :

is equal to the minimum height the element would require in order to fit all the content in the viewport without using a vertical scrollbar.

Here’s a good answer from StackOverflow on what is offsetHeight and scrollHeight. Here’s the visualized summary :

scrollHeight is the total scrollable content height, and offsetHeight is the visible height on the screen. For an overflow view, the scrollHeight is larger than offsetHeight.

We can deduce that if the scrollHeight is larger than the offsetHeight, then the element is truncated.

Here’s the javascript code to check if an element is truncated :

var element = document.querySelector('p');

if (element.offsetHeight < element.scrollHeight ||
    element.offsetWidth < element.scrollWidth) {
    // your element has overflow and truncated
    // show read more / read less button
} else {
    // your element doesn't overflow (not truncated)
}

This code should be run after the paragraph element is rendered on the screen, you can put this in a <script> tag right before the body closing tag </body>.

Toggle truncation

Assuming you already have the .line-clamp-4 CSS class ready, we can toggle truncation by adding / removing this class on the paragraph element, the code for this can be put into onclick action of the read more / read less button:

<button onclick="document.querySelector('p').classList.remove('line-clamp-4')">Read more...</button>

<button onclick="document.querySelector('p').classList.add('line-clamp-4')">Read less...</button>

Demo

I have made a demo for this using Alpine.js and TailwindCSS, you can check the demo at CodePen here : https://codepen.io/cupnoodle/pen/powvObw. Feel free to use this in your project.

Rails tip: use #presence to get params value, or default to a preset value

2021-08-21T08:55:00+00:00

Here’s a method I encountered recently at my work and I found it might be useful to you as well.

There might be some attribute which you want to set to a default parameter if the user didn’t supply any, eg:

# if the parameters is nil or blank, we will default to french fries
sides = params[:sides].present? ? params[:sides] : "french fries"

This one liner looks concise, but we can make it even shorter like this :

sides = params[:sides].presence || "french fries"

The presence method will return nil if the string is a blank string / empty array or nil , then the || (double pipe) will use the value on the right side (“french fries”).

''.presence
# => nil

If the string is not blank, .presence will return the string itself.

When params[:sides] == “” :

sides = params[:sides].presence || "french fries"
# => "french fries"

When params[:sides] == “corn” ,

sides = params[:sides].presence || "french fries"
# => "corn"

Documentation : http://api.rubyonrails.org/classes/Object.html#method-i-presence

How to get started with TailwindCSS

2021-06-24T14:44:00+00:00

How to get started with TailwindCSS

This article assumes you have heard of TailwindCSS, and interested to try it out but have no idea where to start.

Try it out online on Tailwind Play

If you just want to try out TailwindCSS and don’t want to install anything on your computer yet, the official Tailwind Play online playground is a good place to start!

Try it on your HTML file without fiddling with the nodeJS stuff

This section is for when you want to use TailwindCSS on a static website, but you don’t want to deal with the nodeJS NPM stuff.

Thankfully, Beyond Code has released TailwindCSS JIT via CDN. You can read more on how it works on the linked article here : https://beyondco.de/blog/tailwind-jit-compiler-via-cdn

To use TailwindCSS classes on your HTML file, simply include this script in between the <head>...</head> tag :

<!-- Include CDN JavaScript -->
<script src="https://unpkg.com/tailwindcss-jit-cdn"></script>

Then you can use TailwindCSS class names on your HTML file and it will work!

Keep in mind that this JIT javascript file is > 375 KB , which is quite sizeable if you want to use it for production.

The bundle size is pretty big (375kb gzipped) when compared to a production built CSS that is usually ~10kb. But some people don’t mind this.

If you would like to compile a production TailwindCSS, you would have to deal with NPM / nodeJS (I promise it would be painless) , which will go into in the next section.

Compile and purge TailwindCSS into a .css file for production use

Say you already have the HTML ready with TailwindCSS classes, and now you want to build a production ready CSS file, this is where we need to npm install some stuff and run some npm build script.

If you haven’t already, open terminal, and navigate to your project folder root, and initiate npm :

npm init -y

This will create a package.json file in your project folder root.

Next, we are going to install TailwindCSS, PostCSS and AutoPrefixer package :

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

Next, create a PostCSS config file on the project folder root, the file name should be postcss.config.js , and add TailwindCSS and Autoprefixer plugin into this config file.

// postcss.config.js

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}

If you have custom configuration for TailwindCSS (eg: extension or replacement of default class/font), you can create a Tailwind config file using this command :

npx tailwindcss init

This will create a tailwind.config.js file at the root of your project folder.

You can customize this file to extend / replace existing settings, let’s open it and change the purge dictionary to include all html files :

// tailwind.config.js
module.exports = {
  purge: [
    './**/*.html'
  ],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

This will tell TailwindCSS to search for all .html and .js files in the project folder for TailwindCSS classes (eg: mx-4 , text-xl etc), and remove classes that did not appear in the .html and .js files, this can cut down the generated production css file later.

Next, create a .css file if you don’t have one already, and insert these tailwind directive into it :

/* style.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* your custom css class/ids here */
.custom-class {
  
}

These directives (eg: @tailwind base) will be replaced with tailwind styles later on.

Now you can run the following line in terminal to generate the production purged Tailwind CSS file :

NODE_ENV=production npx tailwindcss -i ./style.css  -c ./tailwind.config.js -o ./dist.css

This will read the original CSS file (style.css), use the config located in the tailwind.config.js file, and save the production CSS file into dist.css file (on the project folder root).

Then you can use this production css file in the HTML <head> part like this :

<head>
  <!-- production compiled CSS -->
  <link href="dist.css" rel="stylesheet">
</head>

It might be tedious to type out the long command above to generate production css, especially if you need to generate it more than one time.

To save some typing, you can move the command above into the “scripts” section of the package.json file :

// package.json
{
  "name": "your-project-name",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "css": "NODE_ENV=production npx tailwindcss -i ./style.css  -c ./tailwind.config.js -o ./dist.css"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "autoprefixer": "^10.2.6",
    "postcss": "^8.3.5",
    "tailwindcss": "^2.2.2"
  }
}

Notice that I have added “css” and the command to generate production css into the “scripts” section.

Now you can simply type npm run css on your terminal to generate the production css! 🙌

I have also created a repo here : https://github.com/rubyyagi/tailwindcss-generator , which you can simply clone it, replace the repo with your own HTML files, and run npm run css to generate production CSS!

Using TailwindCSS on Ruby on Rails

If you are interested to use TailwindCSS on a Rails app, you can refer this article on how to install and use TailwindCSS on a Rails project.

Getting started with automated testing workflow and CI on Ruby

2021-06-15T11:06:00+00:00

If you have been writing Ruby / Rails code for a while, but still can’t grasp on the ‘why’ to write automated test, (eg. why do so many Ruby dev job posting requires automated test skill like Rspec, minitest etc? How does writing automated test makes me a better developer or help the company I work with? )

or if you are not sure on how the CI (continuous integration) stuff works, this article is written to address these questions!

This article won’t go into how to write unit test, but it will let you experience what is it like working on a codebase that has automated testing in place, and how it can speed up the development flow and assure quality (ie. confirm the code works). This article assume you have basic knowledge on how to use Git and Github.

I have written a small Ruby Sinatra app (with automated test written using Rspec, you dont have to worry about Rspec for now), you can fork it to your Github account: https://github.com/rubyyagi/cart , then follow along this article to add a feature for it.

After forking the repo, you can download the repo as zip or clone it to your computer. The repo is a simple shopping cart web app, which user can add items to cart and checkout, you can also try the completed online demo here : https://alpine-cart.herokuapp.com

I recommend creating a new git branch before start working on it, to make creating pull request easier in the next step. (create a new branch instead of working on master branch directly.)

Remember to run bundle install after downloading the repo, to install the required gem (Sinatra and Rspec for testing).

To run the web app, open terminal, navigate to that repo, and run ruby app.rb , it should spin up a Sinatra web app, which you can access in your web browser at “localhost:4567”

You can add items to the cart, then click ‘Checkout’ , which it then will show the total (you will implement the discount part later).

Open the repo with your favorite code editor, you will notice a folder named “spec” :

This folder contains the test script I have pre written, there are two test files inside (bulk_discount_spec.rb and cart_spec.rb) , they are used to verify if the bulk_discount logic and cart logic is implemented correctly, you don’t have to make changes on these files.

To run these test, open terminal, navigate to this repo, and run rspec (type ‘rspec’ and press enter).

You should see some test cases fail like this :

This is expected, as the bulk_discount.rb file (it contains logic for bulk discount, located in models/bulk_discount.rb) has not been implemented yet, hence the total returned from the cart on those test are incorrect.

For this exercise, you will need to implement the bulk discount logic in models/bulk_discount.rb , specifically inside the def apply method.

The BulkDiscount class has three properties, amount (in cents), quantity_required (integer), and product_name (string).

For example in the app.rb, we have two bulk discounts :

discounts = [
  BulkDiscount.new(amount: 100, quantity_required: 3, product_name: 'apple'),
  BulkDiscount.new(amount: 200, quantity_required: 2, product_name: 'banana')
]

cart = Cart.new(discounts: discounts, products: products)

We want to give $1 (100 cents in amount) discount off the cart for every 3 Apple (product_name: ‘apple’) purchased. For example if the customer buys 7 Apple, the cart will be discounted $2 ($1 discount for every 3 apple, 6 apple = discount $2).

For the code in app.rb , we want to give bulk discount for apple and banana. Say if the cart has 7 apple and 5 banana, it will be discounted with $6 ($1 x 2 + $2 x 2 = $6, discount of $1 x 2 for apple, $2 x 2 for banana).

Back to bulk_discount.rb, the apply method accepts two parameter, first parameter total , which is the total of the carts, in cents (eg: $4 is 400 cents), before the current bulk discount is applied.

The second parameter products in an array of product (you can check models/product.rb) that is currently in the cart.

The apply method should go through all of the product in the products array, and check if there is product matching the product_name of the BulkDiscount, and then check if the quantity of the product is larger than the quantity_required , and calculate the amount to be deducted and save it to amount_to_deduct.

Then the apply method will return the discounted total (total - amount_to_deduct).

Each time you finish writing the code, you can run rspec to check if the test cases pass. If all of them pass, it means your implementation is correct.

This feedback loop process should be a lot faster than opening the web browser and navigate to the web app, add a few products in cart, click ‘checkout’ and see if the discount is displayed and if the displayed discount amount is correct.

Compared to opening web browser and press ‘add to cart’ and click ‘checkout’ every time you want to test if your code is correct :

With automated test, you can check if an implementation is correct a lot faster than testing it manually.

And with automated test in place, you can be confident that you didn’t break existing feature when you add new feature or make changes in the future, which makes refactoring safe.

(Please work on the exercise yourself first before checking the answer 🙈)

You can compare your implementation with my implementation here (https://github.com/rubyyagi/cart/blob/answer/models/bulk_discount.rb) for the bulk discount.

Continuous Integration (CI)

Once you have finished implementing the bulk discount code part and ensure the test passes, you can push the commit to your forked repo.

And then you can create a new pull request from your branch to the original repo (the rubyyagi/cart) like this :

After creating the pull request, you will notice that Github (Github Actions) automatically runs the test (same like when you run rspec) :

Once the test has passed, it will show this :

Or if there is failing test, it will show “fail”.

The idea is that when you submit a new pull request (containing new feature or fixes), an automated test suite will be run on some external service (Github Actions for this example, but there’s also other CI service provider like CircleCI, SemaphoreCI etc). And you can configure the repository such that only pull request with passing test can be merged.

You can take a look at pull requests in the official Rails repository, each pull request will trigger an automated test run, to ensure they don’t break existing Rails feature, this inspires confidence on the overall code quality.

In my understanding, Continuous Integration (CI) is the process of

Create new branch to work on new feature or fixes
Create pull request from the new branch to the main / master branch
Running automated test suite (and also linting, security checks) on the branch to ensure everything works
A senior dev / team lead/ repository owner will code review the new branch, and request changes if required, else they can approve the new branch and merge it to master/ main branch
The new branch is merged to master/ main branch
The master / main branch is deployed (to Heroku or AWS or some other service) manually or automatically, or if it is a library , push to RubyGems.org

If you are using Heroku, you can configure to automatic deploy new merge to master / main branch only if the CI (automated test suite) passes :

I have already setup the automated test suite to run on Github actions for this repository, you can check the workflow file here if you are interested : https://github.com/rubyyagi/cart/blob/master/.github/workflows/test.yml .

Different CI usually requires different configuration file on the repository, eg: for CircleCI, you need to write the configuration file in /.circleci/config.yml in your repository, these config are vendor specific.

Hope this article has made you understand the importance of automated testing, and how it can speed up development process and inspire confidence in code quality!

How to call methods dynamically using string of method name

2021-02-15T14:40:00+00:00

I was working on a feature for my Rails app, which allows merchant to set fulfillment times on each day like this :

The main feature is that once an order is placed, the customer can’t cancel the placed order after the fulfillment time starts on that day (or on tomorrow).

The fulfillment start times are saved in different columns like this :

create_table "fulfillments", force: :cascade do |t|
  t.time "monday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "tuesday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "wednesday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "thursday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "friday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "saturday_start_time", default: "2000-01-01 00:00:00", null: false
  t.time "sunday_start_time", default: "2000-01-01 00:00:00", null: false
end

To check if the fulfillment time has started, my app will get the current day of week using DateTime.current.strftime('%A').downcase . If today is wednesday, then it will return wednesday .

The question now is that how do I access value of different column based on different day of week? Say I want to get the value of thursday_start_time if today is thursday ; or the value of sunday_start_time is today is sunday .

Fortunately, Ruby’s metaprogramming feature allows us to call methods dynamically by just passing the method name into public_send(method_name) or send(method_name) .

Say we have a class like this :

class Duck
  def make_noise
    puts "quack"
  end
  
  private

  def jump
    puts "can't jump"
  end
end

We can call the make_noise method by calling Duck.new.public_send("make_noise"), this is equivalent to calling Duck.new.make_noise .

For the jump method, we would need to use send instead, as it is a private method, Duck.new.send("jump")

For the fulfillment start time, we can then pass in the day dynamically like this :

# this will return 'monday' if today is monday, or 'tuesday' if today is tuesday etc..
day_of_week = DateTime.current.strftime('%A').downcase

# if today is monday, it will call 'monday_start_time', etc..
start_time = fulfillment.public_send("#{day_of_week}_start_time")

Sweet!

Alternatively, you can also pass in symbol instead of string : public_send(:make_noise) .

Passing parameters to public_send / send

If you would like to send parameters to the method, you can pass them after the method name :

class Animal
  def make_noise(noise, times)
    1..times.each do 
      puts noise
    end
  end
end

Animal.new.public_send('make_noise', 'quack', 3)
# quack
# quack
# quack

Reference

Ruby Doc’s public_send documentation

Ruby Doc’s send documentation

How to run tests in parallel in Github Actions

2021-01-25T17:22:00+00:00

How to run tests in parallel in Github Actions

The company I work for has recently switched to Github Actions for CI, as they offer 2000 minutes per month which is quite adequate for our volume. We have been running tests in parallel (2 instances) on the previous CI to save time, and we wanted to do the same on Github Actions.

Github Actions provides strategy matrix which lets you run tests in parallel, with different configuration for each matrix.

For example with a matrix strategy below :

jobs:
  test:
    name: Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        ruby:
          - '2.5.x'
          - '2.6.x'
          - '2.7.x'
        activerecord:
          - '5.0'
          - '6.0'
          - '6.1'

It will run 9 tests in parallel, 3 versions of Ruby x 3 versions of ActiveRecord = 9 tests

One downside of Github Actions is that they don’t have built-in split tests function to split test files across different CI instances, which many other CI have. For example CircleCI provides split testing command like this :

# Run rspec in parallel, and split the tests by timings
- run:
    command: |
      TESTFILES=$(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)
      bundle exec rspec $TESTFILES

With split testing, we can run different test files on different CI instances to reduce the test execution time on each instance.

Fortunately, we can write our own script to split the test files in Ruby.

Before we proceed to writing split test script, lets configure the Github Actions workflow to run our tests in parallel.

Configuring Github Actions workflow to run test in parallel

Let’s configure our Github Actions workflow to run test in parallel :

# .github/workflows/test.yml
name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        # Set N number of parallel jobs you want to run tests on.
        # Use higher number if you have slow tests to split them on more parallel jobs.
        # Remember to update ci_node_index below to 0..N-1
        ci_node_total: [2]
        # set N-1 indexes for parallel jobs
        # When you run 2 parallel jobs then first job will have index 0, the second job will have index 1 etc
        ci_node_index: [0, 1]
    env:
      BUNDLE_JOBS: 2
      BUNDLE_RETRY: 3
      BUNDLE_PATH: vendor/bundle
      PGHOST: 127.0.0.1
      PGUSER: postgres
      PGPASSWORD: postgres
      RAILS_ENV: test
    services:
      postgres:
        image: postgres:9.6-alpine
        ports: ["5432:5432"]
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        env: 
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: bookmarker_test

    steps:
    # ...

The ci_node_total means the total number of parallel instances you want to spin up during the CI process. We are using 2 instances here so the value is [2]. If you would like to use more instances, say 4 instances, then you can change the value to [4] :

ci_node_total: [4]

The ci_node_index means the index of the parallel instances you spin up during the CI process, this should match the ci_node_total you have defined earlier.

For example, if you have 2 total nodes, your ci_node_index should be [0, 1]. If you have 4 total nodes, your ci_node_index should be [0, 1, 2, 3]. This is useful for when we write the script to split the tests later.

The fail-fast: false means that we want to continue running the test on other instances even if there is failing test on one of the instance. The default value for fail-fast is true if we didn’t set it, which will stop all instances if there is even one failing test on one instance. Setting fail-fast: false would allow all instances to finish run their tests, and we can see which test has failed later on.

Next, we add the testing steps in the workflow :

steps:
  # ... Ruby / Database setup...
  # ...
  - name: Make bin/ci executable
    run: chmod +x ./bin/ci
  - name: Run Rspec test
    id: rspec-test
    env:
      # Specifies how many jobs you would like to run in parallel,
      # used for partitioning
      CI_NODE_TOTAL: ${{ matrix.ci_node_total }}
      # Use the index from matrix as an environment variable
      CI_NODE_INDEX: ${{ matrix.ci_node_index }}
    continue-on-error: true
    run : |
      ./bin/ci

We pass the ci_node_total and ci_node_index variables into the environment variables (env: ) for the test step.

The continue-on-error: true will instruct the workflow to continue to the next step even if there is error on the test step (ie. when any of the test fails).

And lastly we want to run the custom test script that split the test files and run them ./bin/ci , remember to make this file executable in the previous step.

We will look into how to write the bin/ci in the next section.

Preparing the ruby script to split test files and run them

In this section, we will write the bin/ci file.

First, create a file named “ci” (without file extension), and place it in the “bin” folder inside your Rails app like this :

Here’s the code for the ci file :

#!/usr/bin/env ruby

tests = Dir["spec/**/*_spec.rb"].
  sort.
  # Add randomization seed based on SHA of each commit
  shuffle(random: Random.new(ENV['GITHUB_SHA'].to_i(16))).
  select.
  with_index do |el, i|
    i % ENV["CI_NODE_TOTAL"].to_i == ENV["CI_NODE_INDEX"].to_i
  end

exec "bundle exec rspec #{tests.join(" ")}"

Dir["spec/**/*_spec.rb"] will return an array of path of test files, which are located inside the spec folder , and filename ends with _spec.rb . (eg: [“spec/system/bookmarks/create_spec.rb”, “spec/system/bookmarks/update_spec.rb”]) .

You can change this to Dir["test/**/*_test.rb"] if you are using minitest instead of Rspec.

sort will sort the array of path of test files in alphabetical order.

shuffle will then randomize the order of the array, using the seed provided in the random parameter, so that the randomized order will differ based on the random parameter we passed in.

ENV[‘GITHUB_SHA’] is the SHA hash of the commit that triggered the Github Actions workflow, which available as environment variables in Github Actions.

As Random.new only accept integer for the seed parameter, we have to convert the SHA hash (in hexadecimal string, eg: fe5300b3733d69f0a187a5f3237eb05bb134e341 ) into integer using hexadecimal as base (.to_i(16)).

Then we select the test files that will be run using select.with_index. For each CI instance, we will select the test files from the array, which the remainder of the index divided by total number of nodes equals to the CI instance index.

For example, say CI_NODE_TOTAL = 2, CI_NODE_INDEX = 1, and we have four test files :

The test files will be split as shown above.

The downside of this split is that the tests will not be splitted based on the duration of the test, which might make some instance running longer than the others. CircleCI does store historical data of each tests duration and can split the test files based on timing, hopefully Github Actions will implement this feature in the future.

Example repository

I have created an example Rails repository with parallel tests for Github Actions here : https://github.com/rubyyagi/bookmarker

You can check out the full workflow .yml file here , the bin/ci file here , and an example test run here.

Devise only allow one session per user at the same time

2021-01-16T15:42:00+00:00

Sometimes for security purpose, or you just dont want users to share their accounts, it is useful to implement a check to ensure that only one login (session) is allowed per user at the same time.

To check if there is only one login, we will need a column to store information of the current login information. We can use a string column to store a token, and this token will be randomly generated each time the user is logged in, and then we compare if the current session’s login token is equal to this token.

Assuming your users info are stored in the users table (you can change to other name for the command below), create a “current_login_token” column for the table :

rails g migration AddCurrentLoginTokenToUsers current_login_token:string

This would generate migration file below :

class AddCurrentLoginTokenToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :current_login_token, :string
  end
end

Now run rails db:migrate to run this migration.

rails db:migrate

Next, we would need to override the create method of SessionsController from Devise, so that we can generate a random string for the current_login_token column each time the user signs in.

If you don’t already have a custom SessionsController created already, you can generate one using this command :

rails g devise:controllers users -c=sessions

(Assuming the model name is user)

The -c flag means the controller to generate, as we only need to generate SessionsController here. (You can read more about the devise generator command here)

This will generate a controller in app/controllers/users/sessions_controller.rb , and this will override the default Devise’s SessionsController.

Next, we are going to override the “create” method (the method that will be called when user sign in successfully) inside app/controllers/users/sessions_controller.rb :

class Users::SessionsController < Devise::SessionsController
  skip_before_action :check_concurrent_session

  # POST /resource/sign_in
  def create
    super
    # after the user signs in successfully, set the current login token
    set_login_token
  end

  private
  def set_login_token
    token = Devise.friendly_token
    session[:login_token] = token
    current_user.current_login_token = token
    current_user.save
  end
end

We use Devise.friendly_token to generate a random string for the token, then store it into the current session (session[:login_token]) and also save to the current user’s current_login_token column.

The skip_before_action :check_concurrent_session will be explained later, put it there for now.

Next, we will edit the application_controller.rb file (or whichever controller where most of the controllers that require authorization are inherited from).

class ApplicationController < ActionController::Base
  # perform the check before each controller action are executed
  before_action :check_concurrent_session

  private

  def check_concurrent_session
    if already_logged_in?
      # sign out the previously logged in user, only left the newly login user
      sign_out_and_redirect(current_user)
    end
  end

  def already_logged_in?
    # if current user is logged in, but the user login token in session 
    # doesn't match the login token in database,
    # which means that there is a new login for this user
    current_user && !(session[:login_token] == current_user.current_login_token)
  end
end

As we have wrote before_action :check_concurrent_session in the application_controller.rb , all controllers inherited from this will run the check_concurrent_session method before the controller action method are executed, this will check if there is any new login session initiated for the same user.

We want to exempt this check when user is on the login part, ie. sessions#create , hence we put a skip_before_action :check_concurrent_session to skip this check for the Users::SessionController class earlier.

Here’s a demo video of this code :

Notice that after the second login attempt, the previously logged in user gets logged out after clicking a link (executing a controller action).

How to install TailwindCSS 2 on Rails 6

2020-12-10T00:00:00+00:00

TailwindCSS v2.0 was released on 19 November 2020 🎉, but it had a few changes that requires some tweak to install and use it on Rails 6, such as the requirement of PostCSS 8 and Webpack 5. As of current (10 December 2020), Rails 6 comes with webpack 4 and PostCSS 7, which doesn’t match the requirement of TailwindCSS v2.

If we install TailwindCSS v2 directly on a Rails 6 app using yarn add tailwindcss , we might get a error (PostCSS plugin tailwindcss requires PostCSS 8) like this when running the server :

This tutorial will guide you on how to install and use TailwindCSS 2 on Rails 6 using new Webpacker version(v5+). If webpack / webpacker v5+ breaks your current Rails app javascript stuff, I recommend using the compability build of Tailwind following this tutorial.

Update webpacker gem and npm package

Currently the latest Webpacker NPM package is not up to date to the master branch of Webpacker repository, we need to use the Github master version until Rails team decide to push the new version of webpacker into NPM registry.

To do this, we need to uninstall the current webpacker in our Rails app :

yarn remove @rails/webpacker

And install the latest webpacker directly from Github (notice without the “@”) :

yarn add rails/webpacker

Here’s the difference in package.json :

Next, we need to do the same for the Webpacker gem as well, as they haven’t push the latest webpacker code in Github to RubyGems registry.

In your Gemfile, change the webpacker gem from :

gem 'webpacker', '~> 4.0'

to:

gem "webpacker", github: "rails/webpacker"

then run bundle install to install the gem from its Github repository. You should see the webpacker gem is version 5+ now :

Install Tailwind CSS 2

After updating the webpacker gem, we can install TailwindCSS (and its peer dependency) using yarn :

yarn add tailwindcss postcss autoprefixer

We can use webpacker for handling Tailwind CSS in our Rails app, create a folder named stylesheets inside app/javascript (the full path would be app/javascript/stylesheets).

Inside the app/javascript/stylesheets folder, create a file and name it “application.scss”, then import Tailwind related CSS inside this file :

/* application.scss */
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

The file structure looks like this :

Then in app/javascript/packs/application.js , require the application.scss :

// app/javascript/packs/application.js

require("@rails/ujs").start()
require("turbolinks").start()

require("stylesheets/application.scss")

Next, we have to add stylesheet_pack_tag that reference the app/javascript/stylesheets/application.scss file in the layout file (app/views/layouts/application.html.erb). So the layout can import the stylesheet there.

<!-- app/views/layouts/application.html.erb-->

<!DOCTYPE html>
<html>
  <head>
    <title>Bootstraper</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    
    <!-- This refers to app/javascript/stylesheets/application.scss-->
    <%= stylesheet_pack_tag 'application', 'data-turbolinks-track': 'reload' %>

    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>
....

Add TailwindCSS to PostCSS config

Next, we will add TailwindCSS into the postcss.config.js file (located in your Rails app root) :

// postcss.config.js

module.exports = {
  plugins: [
    require("tailwindcss"),
    require('postcss-import'),
    require('postcss-flexbugs-fixes'),
    require('postcss-preset-env')({
      autoprefixer: {
        flexbox: 'no-2009'
      },
      stage: 3
    })
  ]
}

If you are not using the default file name for TailwindCSS configuration file (tailwind.config.js) , you need to specify it after the tailwindcss require :

// postcss.config.js

module.exports = {
  plugins: [
    // if you are using non default config filename
    require("tailwindcss")("tailwind.config.js"),
    require('postcss-import'),
    require('postcss-flexbugs-fixes'),
    require('postcss-preset-env')({
      autoprefixer: {
        flexbox: 'no-2009'
      },
      stage: 3
    })
  ]
}

Now we can use the Tailwind CSS classes on our HTML elements!

<h1>This is static#index</h1>
<div class="bg-red-500 w-3/4 mx-auto p-4">
  <p class="text-white text-2xl">Test test test</p>
</div>

You can refer to Tailwind CSS documentation for the list of classes you can use.

For further Tailwind CSS customization and configuring PurgeCSS, you can refer this post.

References

Thanks Kieran for writing the Tailwind CSS 2 upgrade guide.

How to implement Rails API authentication with Devise and Doorkeeper

2020-12-06T00:00:00+00:00

Most of the time when we implement API endpoints on our Rails app, we want to limit access of these API to authorized users only, there’s a few strategy for authenticating user through API, ranging from a simple token authentication to a fullblown OAuth provider with JWT.

In this tutorial, we will implement an OAuth provider for API authentication on the same Rails app we serve the user, using Devise and Doorkeeper gem.

After this tutorial, you would be able to implement Devise sign in/sign up on Rails frontend, and Doorkeeper OAuth (login, register) on the API side for mobile app client, or a separate frontend client like React etc.

This tutorial assume that you have some experience using Devise and your Rails app will both have a frontend UI and API for users to register and sign in. We can also use Doorkeeper to allow third party to create their own OAuth application on our own Rails app platform, but that is out of the scope of this article, as this article will focus on creating our own OAuth application for self consumption only.

Table of contents

Scaffold a model
Setup Devise gem
Setup Doorkeeper gem
Customize Doorkeeper configuration
Create your own OAuth application
How to login , logout and refresh token using API
Create API controllers that require authentication
Create an endpoint for user registration
Revoke user token manually
References

Scaffold a model

Let’s start with some scaffolding so we can have a model, controller and view for CRUD, you can skip this section if you already have an existing Rails app.

rails g scaffold bookmarks title:string url:string

then in routes.rb , set the root path to ‘bookmarks#index’. Devise requires us to set a root path in routes to work.

# config/routes.rb

root 'bookmarks#index'

Now we have a sample CRUD Rails app, we can move on to the next step.

Setup Devise gem

Add devise gem in the Gemfile :

# Gemfile
# ...
gem 'devise', '~> 4.7.3'

and run bundle install to install it.

Next, run the Devise installation generator :

rails g devise:install

Then we create the user model (or any other model name you are using like admin, staff etc) using Devise :

rails g devise User

You can customize the devise features you want in the generated migration file, and also in the User model file.

Then run rake db:migrate to create the users table.

Now we have the Devise user set up, we can add authenticate_user! to bookmarks_controller.rb so only logged in users can view the controller now.

# app/controllers/bookmarks_controller.rb

class BookmarksController < ApplicationController
  before_action :authenticate_user!
  
  # ....
end

Next we will move to the main part, which is setting up authentication for the API using Doorkeeper gem.

Setup Doorkeeper gem

Add doorkeeper gem in the Gemfile :

# Gemfile
# ...
gem 'doorkeeper', '~> 5.4.0'

and run bundle install to install it.

Next, run the Doorkeeper installation generator :

rails g doorkeeper:install

This will generate the configuration file for Doorkeeper in config/initializers/doorkeeper.rb, which we will customize later.

Next, run the Doorkeeper migration generator :

rails g doorkeeper:migration

This will generate a migration file for Doorkeeper in db/migrate/…_create_doorkeeper_tables.rb .

We will customize the migration file as we won’t need all the tables / attributes generated.

Open the …._create_doorkeeper_tables.rb migration file, then edit to make it look like below :

# frozen_string_literal: true

class CreateDoorkeeperTables < ActiveRecord::Migration[6.0]
  def change
    create_table :oauth_applications do |t|
      t.string  :name,    null: false
      t.string  :uid,     null: false
      t.string  :secret,  null: false

      # Remove `null: false` if you are planning to use grant flows
      # that doesn't require redirect URI to be used during authorization
      # like Client Credentials flow or Resource Owner Password.
      t.text    :redirect_uri
      t.string  :scopes,       null: false, default: ''
      t.boolean :confidential, null: false, default: true
      t.timestamps             null: false
    end

    add_index :oauth_applications, :uid, unique: true

    create_table :oauth_access_tokens do |t|
      t.references :resource_owner, index: true

      # Remove `null: false` if you are planning to use Password
      # Credentials Grant flow that doesn't require an application.
      t.references :application,    null: false

      t.string :token, null: false

      t.string   :refresh_token
      t.integer  :expires_in
      t.datetime :revoked_at
      t.datetime :created_at, null: false
      t.string   :scopes

      # The authorization server MAY issue a new refresh token, in which case
      # *the client MUST discard the old refresh token* and replace it with the
      # new refresh token. The authorization server MAY revoke the old
      # refresh token after issuing a new refresh token to the client.
      # @see https://tools.ietf.org/html/rfc6749#section-6
      #
      # Doorkeeper implementation: if there is a `previous_refresh_token` column,
      # refresh tokens will be revoked after a related access token is used.
      # If there is no `previous_refresh_token` column, previous tokens are
      # revoked as soon as a new access token is created.
      #
      # Comment out this line if you want refresh tokens to be instantly
      # revoked after use.
      t.string   :previous_refresh_token, null: false, default: ""
    end

    add_index :oauth_access_tokens, :token, unique: true
    add_index :oauth_access_tokens, :refresh_token, unique: true
    add_foreign_key(
      :oauth_access_tokens,
      :oauth_applications,
      column: :application_id
    )
  end
end

The modification I did on the migration file :

Remove null: false on the redirect_uri for oauth_applications table. As we are using the OAuth for API authentication, we won’t need to redirect the user to a callback page (like after you sign in with Google / Apple / Facebook on an app, they will redirect to a page usually).
Remove the creation of table oauth_access_grants , along with its related index and foreign key.

The OAuth application table is used to keep track of the application we created to use for authentication. For example, we can create three application, one for Android app client, one for iOS app client and one for React frontend, this way we can know which clients the users are using. If you only need one client (eg: web frontend), it is fine too.

Here’s an example of Github OAuth applications :

Next, run rake db:migrate to add these tables into database.

Next, we will customize the Doorkeeper configuration.

Customize Doorkeeper configuration

Open config/initializers/doorkeeper.rb , and edit the following.

Comment out or remove the block for resource_owner_authenticator at the top of the file.

#config/initializers/doorkeeper.rb

Doorkeeper.configure do
  # Change the ORM that doorkeeper will use (requires ORM extensions installed).
  # Check the list of supported ORMs here: https://github.com/doorkeeper-gem/doorkeeper#orms
  orm :active_record

  # This block will be called to check whether the resource owner is authenticated or not.
  # resource_owner_authenticator do
    # raise "Please configure doorkeeper resource_owner_authenticator block located in #{__FILE__}"
    # Put your resource owner authentication logic here.
    # Example implementation:
    #   User.find_by(id: session[:user_id]) || redirect_to(new_user_session_url)
  # end

The resouce_owner_authenticator block is used to get the authenticated user information or redirect the user to login page from OAuth, for example like this Twitter OAuth page :

As we are going to exchange OAuth token by using user login credentials (email + password) on the API, we don’t need to implement this block, so we can comment it out.

To tell Doorkeeper we are using user credentials to login, we need to implement the resource_owner_from_credentials block like this :

#config/initializers/doorkeeper.rb

Doorkeeper.configure do
  # Change the ORM that doorkeeper will use (requires ORM extensions installed).
  # Check the list of supported ORMs here: https://github.com/doorkeeper-gem/doorkeeper#orms
  orm :active_record

  # This block will be called to check whether the resource owner is authenticated or not.
  # resource_owner_authenticator do
    # raise "Please configure doorkeeper resource_owner_authenticator block located in #{__FILE__}"
    # Put your resource owner authentication logic here.
    # Example implementation:
    #   User.find_by(id: session[:user_id]) || redirect_to(new_user_session_url)
  # end

  resource_owner_from_credentials do |_routes|
    User.authenticate(params[:email], params[:password])
  end
  
  # ...

This will allow us to send the user email and password to the /oauth/token endpoint to authenticate user.

Then we need to implement the authenticate class method on the app/models/user.rb model file.

# app/models/user.rb
class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable

  validates :email, format: URI::MailTo::EMAIL_REGEXP
  
  # the authenticate method from devise documentation
  def self.authenticate(email, password)
    user = User.find_for_authentication(email: email)
    user&.valid_password?(password) ? user : nil
  end
end

You can read more on the authenticate method on Devise’s github Wiki page.

Next, enable password grant flow in config/initializers/doorkeeper.rb , this will allow us to send the user email and password to the /oauth/token endpoint and get OAuth token in return.

Doorkeeper.configure do
  orm :active_record

  resource_owner_from_credentials do |_routes|
    User.authenticate(params[:email], params[:password])
  end
  
  # enable password grant
  grant_flows %w[password]
  
  # ....

You can search for “grant_flows” in this file, and uncomment and edit it.

Next, insert allow_blank_redirect_uri true into the configuration, so that we can create OAuth application with blank redirect URL (user won’t get redirected after login, as we are using API).

Doorkeeper.configure do
  orm :active_record

  resource_owner_from_credentials do |_routes|
    User.authenticate(params[:email], params[:password])
  end
  
  grant_flows %w[password]
  
  allow_blank_redirect_uri true
  # ....

As the OAuth application we create is for our own use (not third part), we can skip authorization.

Insert skip_authorization into the configuration like this :

Doorkeeper.configure do
  orm :active_record

  resource_owner_from_credentials do |_routes|
    User.authenticate(params[:email], params[:password])
  end
  
  grant_flows %w[password]
  
  allow_blank_redirect_uri true
  
  skip_authorization do
    true
  end
  # ....

The authorization we skipped is something like this :

As we skipped authorization, user won’t need to click the “authorize” button to interact with our API.

Optionally, if you want to enable refresh token mechanism in OAuth, you can insert the use_refresh_token into the configuration. This would allow the client app to request a new access token using the refresh token when the current access token is expired.

Doorkeeper.configure do
  orm :active_record

  resource_owner_from_credentials do |_routes|
    User.authenticate(params[:email], params[:password])
  end
  
  grant_flows %w[password]
  
  allow_blank_redirect_uri true
  
  skip_authorization do
    true
  end
  
  use_refresh_token
  # ...

With this, we have finished configuring Doorkeeper authentication for our API.

Next, we will add the doorkeeper route in routes.rb , this will add the /oauth/* routes.

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

As we don’t need the app authorization, we can skip the authorizations and authorized_applications controller. We can also skip the applications controller, as users won’t be able to create or delete OAuth application.

Next, we need to create our own OAuth application manually in the console so we can use it for authentication.

Create your own OAuth application

Open up rails console, rails console

Then create an OAuth application using this command :

Doorkeeper::Application.create(name: "Android client", redirect_uri: "", scopes: "")

You can change the name to any name you want, and leave redirect_uri and scopes blank.

This will create a record in the oauth_applications table. Keep note that the uid attribute and secret attribute, these are used for authentication on API later, uid = client_id and secret = client_secret.

For production use, you can create a database seed for initial creation of the OAuth applications in db/seeds.rb :

# db/seeds.rb

# if there is no OAuth application created, create them
if Doorkeeper::Application.count.zero?
  Doorkeeper::Application.create(name: "iOS client", redirect_uri: "", scopes: "")
  Doorkeeper::Application.create(name: "Android client", redirect_uri: "", scopes: "")
  Doorkeeper::Application.create(name: "React", redirect_uri: "", scopes: "")
end

Then run rake db:seed to create these applications.

Doorkeeper::Application is just a namespaced model name for the oauth_applications table, you can perform ActiveRecord query as usual :

# client_id of the application
Doorkeeper::Application.find_by(name: "Android client").uid

# client_secret of the application
Doorkeeper::Application.find_by(name: "Android client").secret

Now we have Doorkeeper application set up, we can try to login user in the next section.

We will need a user created to be able to login / logout them using the OAuth endpoints, you can register a dummy user on the devise web UI if you haven’t already (eg: localhost:3000/users/sign_up) or create one via the rails console.

The HTTP requests below can either send attributes using JSON format or URL-Encoded form.

To login the user on the OAuth endpoint, we need to send a HTTP POST request to /oauth/token, with grant_type, email, password, client_id and client_secret attributes.

As we are using password in exchange for OAuth access and refresh token, the grant_type value should be password.

email and password is the login credential of the user.

client_id is the uid of the Doorkeeper::Application (OAuth application) we created earlier, with this we can identify which client the user has used to log in.

client_secret is the secret of the Doorkeeper::Application (OAuth application) we created earlier.

On successful login attempt, the API will return access_token, refresh_token, token_type, expires_in and created_at attributes.

We can then use access_token to call protected API that requires user authentication.

refresh_token can be used to generate and retrieve a new access token after the current access_token has expired.

expires_in is the time until expiry for the access_token, starting from the UNIX timestamp of created_at, the default value is 7200 (seconds), which is around 2 hours.

Logout

To log out a user, we can revoke the access token, so that the same access token cannot be used anymore.

To revoke an access token, we need to send a HTTP POST request to /oauth/revoke, with token, client_id and client_secret attributes.

Other than these attributes, we also need to set Authorization header for the HTTP request to use Basic Auth, using client_id value for the username and client_password value for the password. (According to this reply in Doorkeeper gem repository)

After revoking a token, the token record will have a revoked_at column filled :

Refresh token

To retrieve a new access token when the current access token is (almost) expired, we can send a HTTP POST to /oauth/token , it is the same endpoint as login, but this time we are using “refresh_token” as the value for grant_type, and is sending the value of refresh token instead of login credentials.

To refresh a token, we need to send grant_type, refresh_token, client_id and client_secret attributes.

grant_type needs to be equal to “refresh_token” here as we are using refresh token to authenticate.

refresh_token should be the refresh token value you have retrieved during login.

client_id is the uid of the Doorkeeper::Application (OAuth application) we created earlier.

client_secret is the secret of the Doorkeeper::Application (OAuth application) we created earlier.

On successful refresh attempt, the API return a new access_token and refresh_token, which we can use to call protected API that requires user authentication.

Create API controllers that require authentication

Now that we have user authentication set up, we can now create API controllers that require authentication.

For this, I recommend creating a base API application controller, then subclass this controller for controllers that require authentication.

Create a base API application controller (application_controller.rb) and place it in app/controllers/api/application_controller.rb .

# app/controllers/api/application_controller.rb
module Api
  class ApplicationController < ActionController::API
    # equivalent of authenticate_user! on devise, but this one will check the oauth token
    before_action :doorkeeper_authorize!

    private

    # helper method to access the current user from the token
    def current_user
      @current_user ||= User.find_by(id: doorkeeper_token[:resource_owner_id])
    end
  end
end

The API application subclasses from ActionController::API, which is a lightweight version of ActionController::Base, and does not contain HTML layout and templating functionality (we dont need it for API anyway), and it doesn’t have CORS protection.

We add the doorkeeper_authorize! method in the before_action callback, as this will check if the user is authenticated with a valid token before calling methods in the controller, this is similar to the authenticate_user! method on devise.

We also add a current_user method to get the current user object, then we can attach the current user on some model’s CRUD action.

As example of a protected API controller, let’s create a bookmarks controller to retrieve all bookmarks.

app/controllers/api/bookmarks_controller.rb

# app/controllers/api/bookmarks_controller.rb
module Api
  class BookmarksController < Api::ApplicationController
    def index
      @bookmarks = Bookmark.all
      render json: { bookmarks: @bookmarks }
    end
  end
end

The bookmarks controller will inherit from the base API application controller we created earlier, and it will return all the bookmarks in JSON format.

Don’t forget to add the route for it in routes.rb :

Rails.application.routes.draw do
  # ....
  namespace :api do
    resources :bookmarks, only: %i[index]
  end
end

Then we can retrieve the bookmarks by sending a HTTP GET request to /api/bookmarks, with the user’s access token in the Authorization Header (Authorization: Bearer [User Access Token])

To access protected API controllers, we will need to include the Authorization HTTP header, with the values of “Bearer [User Access Token]”.

Create an endpoint for user registration

It would be weird if we only allow user registration through website, we would also need to add an API endpoint for user to register an account .

For this, let’s create a users controller and place it in app/controllers/api/users_controller.rb.

The create action will create an user account from the supplied email and password.

module Api
  class UsersController < Api::ApplicationController
    skip_before_action :doorkeeper_authorize!, only: %i[create]

    def create
      user = User.new(email: user_params[:email], password: user_params[:password])

      client_app = Doorkeeper::Application.find_by(uid: params[:client_id])

      return render(json: { error: 'Invalid client ID'}, status: 403) unless client_app

      if user.save
        # create access token for the user, so the user won't need to login again after registration
        access_token = Doorkeeper::AccessToken.create(
          resource_owner_id: user.id,
          application_id: client_app.id,
          refresh_token: generate_refresh_token,
          expires_in: Doorkeeper.configuration.access_token_expires_in.to_i,
          scopes: ''
        )
        
        # return json containing access token and refresh token
        # so that user won't need to call login API right after registration
        render(json: {
          user: {
            id: user.id,
            email: user.email,
            access_token: access_token.token,
            token_type: 'bearer',
            expires_in: access_token.expires_in,
            refresh_token: access_token.refresh_token,
            created_at: access_token.created_at.to_time.to_i
          }
        })
      else
        render(json: { error: user.errors.full_messages }, status: 422)
      end
    end

    private

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

    def generate_refresh_token
      loop do
        # generate a random token string and return it, 
        # unless there is already another token with the same string
        token = SecureRandom.hex(32)
        break token unless Doorkeeper::AccessToken.exists?(refresh_token: token)
      end
    end 
  end
end

As the user doesn’t have an account at this point, we want to exempt this action from requiring authentication information, so we added the line skip_before_action :doorkeeper_authorize!, only: %i[create] at the top. This will make the create method to skip running the doorkeeper_authorize! before_action method we defined in the base API controller, and the client app can call the user account creation API endpoint without authentication information.

We then create an AccessToken on successful user registration using Doorkeeper::AccessToken.create() and return it in the HTTP response, so the user won’t need to login right after registration.

Remember to add a route for ths user registration action in routes.rb :

Rails.application.routes.draw do
  # ....
  namespace :api do
    resources :users, only: %i[create]
    resources :bookmarks, only: %i[index]
  end
end

Then we can call create user API by sending a HTTP POST request containing the user’s email, password and client_id to /api/users like this :

The client_id is used to identify which client app the user is using for registration.

Revoke user token manually

Say if you suspect a user’s access token has been misused or abused, you can revoke them manually using this function :

Doorkeeper::AccessToken.revoke_all_for(application_id, resource_owner)

application_id is the id of the Doorkeeper::Application (OAuth application) we want to revoke the user from.

resource_owner is the user object.

Example usage:

client_app = Doorkeeper::Application.find_by(name: 'Android client')
user = User.find(7)

Doorkeeper::AccessToken.revoke_all_for(client_app.id , user)

References

Devise wiki - How To: Find a user when you have their credentials

Doorkeeper wiki - Using Resource Owner Password Credentials flow

Ruby Yagi 🐐

Simplify loop using any?, all? and none?

any?

all?

none?

Reference

How to truncate long text and show read more / less button

Truncate text using CSS

Check if a text is truncated using offsetHeight and scrollHeight

Toggle truncation

Demo

Rails tip: use #presence to get params value, or default to a preset value

How to get started with TailwindCSS

How to get started with TailwindCSS

Try it out online on Tailwind Play

Try it on your HTML file without fiddling with the nodeJS stuff

Compile and purge TailwindCSS into a .css file for production use

Using TailwindCSS on Ruby on Rails

Getting started with automated testing workflow and CI on Ruby

Continuous Integration (CI)

Further Reading

How to call methods dynamically using string of method name

Passing parameters to public_send / send

Reference

How to run tests in parallel in Github Actions

How to run tests in parallel in Github Actions

Configuring Github Actions workflow to run test in parallel

Preparing the ruby script to split test files and run them

Example repository

Devise only allow one session per user at the same time

How to install TailwindCSS 2 on Rails 6

Update webpacker gem and npm package

Install Tailwind CSS 2

Add TailwindCSS to PostCSS config

References

How to implement Rails API authentication with Devise and Doorkeeper

Scaffold a model

Setup Devise gem

Setup Doorkeeper gem

Customize Doorkeeper configuration

Create your own OAuth application

How to login , logout and refresh token using API

Login

Logout

Refresh token

Create API controllers that require authentication

Create an endpoint for user registration

Revoke user token manually

References