How to implement Authorizer pattern in Ruby on Rails?

Overview

On this article, we’ll discover the Authorizer sample in Ruby on Rails purposes. We’ll present a definition of the Authorizer sample and focus on its use instances and examples. We can even delve into the necessity for this sample and the way it helps to resolve sure issues in Rails purposes.

Definition

In easy phrases, the Authorizer sample permits us to outline and encapsulate advanced enterprise rule in our Rails purposes. If the requirement specified by this rule isn’t met, an error shall be raised. You possibly can consider an Authorizer as a customized ActiveRecord Validator, however as a substitute of validating enter information, it’s used to implement enterprise necessities.

Why do we’d like it and what issues can this sample clear up? 🤷🏻‍♂️

Let’s check out the next instance.

def create
  consumer = Person.first
  elevate 'Person isn't energetic' if consumer.standing != 'energetic' || consumer.approved_at.clean?

  article = Aricle.create(consumer: consumer, title: 'title', physique: 'physique')
  render json: article
finish

Within the following instance, we need to be certain that sure necessities are totally met earlier than calling the enterprise logic.

Do now we have any issues with this method? 🤔

Sure, now we have.

• It’s not potential to check individually from the controller.
• It’s not reusable.
• We violate the Single Duty Precept as a result of the controller turns into liable for enterprise guidelines validation.
• The next code will increase ‘cognitive load’ and requires extra time to know.
• The next code isn’t scalable and it’s troublesome so as to add extra guidelines.

How can we clear up these issues? 🤔

• We will transfer this logic to the mannequin degree and use before_create callback.
• We will create Athorizer class and transfer the logic there.

Let’s check out these choices one after the other.

Mannequin with callback

That is the best possibility, we simply want to increase our mannequin within the following means:

# app/fashions/article.rb

class Aricle < ApplicationRecord

  before_save :check_user_status!

  def check_user_status!
    elevate 'Person isn't energetic' if consumer.standing != 'energetic' || consumer.approved_at.clean?
  finish

finish

consumer = Person.final
Aricle.create(consumer: consumer, article_params)

Are there any disadvantages to this method?

There’re 2 issues:

• We violate the Single duty SOLID precept. The mannequin turns into too FAT and liable for too many issues.
• Utilizing callbacks in Rails fashions could make the code extra obscure and preserve as a consequence of their tight coupling with the mannequin and lack of transparency. Subsequently, it’s usually thought of to be a nasty sample.

So it could be good to encapsulate this logic in a separate class. How can we try this?

Authorizer Sample

We’ll implement Athorizer Sample by way of plain Ruby object as a result of it is the clearest and probably the most simple answer.

Let’s check out the next instance.

# app/authorizers/has_active_user_authorizer.rb

class HasActiveUserAuthorizer

  def initialize(consumer)
    @consumer = consumer
  finish

  def authorize!
    elevate 'Person isn't energetic' except energetic?
  finish

  personal

  attr_reader :consumer

  def energetic?
    consumer.standing == 'energetic' && consumer.approved_at.current?
  finish

finish

HasActiveUserAuthorizer.new(consumer).authorize!

We simply encapsulated our guidelines inside a separate class, and that is it. This code adheres to the SOLID rules and is way simpler to know and preserve.

Naming conference

There are two frequent methods to call authorizers:

• Inside a namespace (for instance, Authorizers::HasActiveUser)
• With a postfix (for instance, HasActiveUserAuthorizer)

However they’ve one rule in frequent – the authorizer should clearly mirror in its title the rule it introduces. Let’s check out different potential names which are generally used for the Authorizer Sample to get a wider image:

• CompanyHasNoEmployeesAuthorizer

Raises an error if the corporate has no less than one worker

• ArticleNotApprovedAuthorizer

Raises an error if the article is accredited

• Authorizers::HasAtLeastOneComment

Raises an error if there are not any feedback

• Authorizers::NotPopulated

Raises an error if the desk is already populated with information

• UserHasActiveSubscriptionAuthorizer

Raises an error if the consumer doesn’t have an energetic subscription

• CustomerAgeApprovedAuthorizer

Raises an error if the shopper’s age isn’t accredited

and so on …

Evaluating the Authorizer Sample to Different Patterns

Much like Type Object

Type objects and Authorizers each carry out validation and lift errors earlier than working enterprise logic. So, what are the variations? The important thing variations are:

• Type objects validate information from the consumer enter
• Authorizers validate basic enterprise logic guidelines

P.S.. To be taught extra about utilizing Type object sample in Ruby on Rails, you possibly can take a look at this text.

Much like Coverage Object

Authorizers are additionally much like Coverage objects as a result of each encapsulate enterprise guidelines. The important thing variations are:

• Authorizers could include just one enterprise rule, however Coverage objects can include many.
• Authorizers are extra strict and demand {that a} enterprise rule be adopted, whereas a Coverage object will solely ask if the rule is true or false. This distinction is mirrored in using ! by Authorizers and ? by Coverage objects on the finish of their strategies.

P.S.. To be taught extra about utilizing Coverage object sample in Ruby on Rails, you possibly can take a look at this text.

Much like Customized Validators

• Authorizers are much like customized ActiveRecord validations by way of their duty, however customized validators validate one information area, whereas Authorizers validate basic guidelines for the entire mannequin.

Notice:

Do not confuse the Authorizer sample with authorization logic. Authorizers ask if the service is permitted to carry out the motion beneath the present situations, whereas authorization logic occurs at a better degree (often on the controller degree).

Bonus Chapter: Including Authorizers to Service Objects

Within the earlier chapter, we talked about that Authorizers are much like customized validators. Let’s check out the instance of customized validators:

# app/fashions/article.rb

class Article < ApplicationRecord
  # ...
  validate :name_presence
  # ...
  def name_presence
    errors.add :base, "Identify is empty" if title.clean?
  finish
finish

Or in a separate class:

# app/fashions/article.rb

class Article < ApplicationRecord
  # ...
  validates_with NamePresenceValidator
  # ...
finish

# app/validators/name_presence.rb

class NamePresenceValidator < ActiveModel::Validator
  def validate(file)
    file.errors.add :base, "Identify is empty" if file.title.clean?
  finish
finish

Basically, we need to have an identical interface for our Authorizers inside Service objects, one thing like this:

# app/providers/create_article_service.rb

class CreateArticleService
  # ...
  authorize 'has_active_user_authorizer'
  authorize 'another_authorizer'
  authorize 'one_more_authorizer'
  # ...
finish

How can we do that? Let’s contemplate what we’d like:

• Service (to maintain the authorize technique)
• A module with the authorize technique definition (to have the ability to embrace it in each service)
• Authorizer (to encapsulate advanced enterprise rule)
• A base Authorizer (to keep away from repeating the identical code for each new Authorizer)

Let’s add them one after the other.

Notice: We’ll solely present code snippets with out clarification to maintain it transient.

Service

# app/providers/create_article_service.rb

class CreateArticleService

  embrace Authorizable

  authorize 'has_active_user_authorizer'

  attr_reader :consumer, :params

  def initialize(consumer: , params:)
    @consumer = consumer
    @params = params
  finish

  def name
    authorize!
    # important logic
  finish

finish

Authorizable module

# lib/authorizable.rb

module Authorizable
  prolong ActiveSupport::Concern

  included do
    class_attribute :authorizers, default: []
  finish

  class_methods do
    def authorize(authorizer_name)
      self.authorizers += [authorizer_name]
    finish
  finish

  def authorize!
    authorizers.every do |authorizer|
      authorizer.to_s.classify.constantize.new(self).authorize
    finish
  finish
finish

Authorizer

# app/authorizers/has_active_user_authorizer.rb

class HasActiveUserAuthorizer < BaseAuthorizer

  def authorize!
    elevate 'Person isn't energetic' except energetic?
  finish

  personal

  def energetic?
    service_object.consumer.standing == 'energetic' && service_object.consumer.approved_at.current?
  finish

finish

BaseAuthorizer

# lib/base_authorizer.rb

class BaseAuthorizer

  def initialize(service_object)
    @service_object = service_object
  finish

  def authorize!
    elevate 'NotImplementedError'
  finish

  personal

  attr_reader :service_object

finish

That is it! Now you should use the Authorizer sample in your service objects to encapsulate advanced enterprise guidelines and be certain that they’re adopted earlier than the principle logic is executed. To be taught extra about utilizing the Service object sample in Ruby on Rails, you possibly can take a look at my different article.

So the ultimate answer could appear to be this:

def create
  consumer = Person.first
  UserIsActiveAuthorizer.new(consumer).authorize!

  article = Aricle.create(consumer: consumer, title: 'title', physique: 'physique')
  render json: article
finish

Or utilizing a service object:

def create
  consumer = Person.first

  article = CreateArticleService.new(consumer: consumer, params: { title: 'title', physique: 'physique' }).name
  render json: article
finish

Conclusion

• The Authorizer Sample helps us higher separate logic, making it simpler to check our code.
• It’s DRY and reusable.
• The Authorizer Sample permits us to keep away from having a “fats” mannequin and cling to SOLID rules.
• It reduces “cognitive overhead”, making the code simpler to know.
• It ensures that any mandatory necessities are met as quickly as potential by elevating an error earlier than working any kind validations or enterprise logic calculations.